AI Governance Evidence Infrastructure (AGEI) & Agent Governance Reference Architecture

Abstract

AI governance has matured rapidly in policy and documentation, yet it remains fundamentally weak in verifiable evidence. Traditional systems rely on scattered logs, static model cards, and siloed ticketing systems, which fail to provide a tamper-evident, lifecycle-wide chain of accountability.

AI Governance Evidence Infrastructure (AGEI) is a distinct category of enterprise software designed to capture, evaluate, seal, link, store, retrieve, and verify governance evidence across the entire AI lifecycle.

This page serves as the canonical technical architecture guide for cognitiveinsight.ai. It synthesizes the AGEI Operating Model, the Eight Reference Layers, the Five Planes of Agentic AI Governance, and the Pre-Action Proof-Carrying Tool Execution framework. This model shifts the paradigm from simple telemetry to proof-carrying, policy-grounded accountability.

1. System Boundary and Adjacent Integrations

AGEI is not a replacement for existing operational platforms. Instead, it serves as the evidence-grade layer that binds governance-relevant facts across these adjacent systems.

2. The Eight Operating Layers of AGEI

The core AGEI architecture is structured around eight logical operating layers, each backed by dedicated tables within a 60-table relational schema.

Deep-Dive Layer Responsibilities

• Layer 1: Policy Intent
  Purpose: Declares which governance rules are in force.
  Mechanics: Policies are treated as immutable, versioned database objects (policy_sets, policy_versions, policy_rules). This ensures that a past evaluation can always be checked against the exact version of the policy that was active at that millisecond.
• Layer 2: Rule Evaluation
  Purpose: Evaluates individual machine-evaluable rules.
  Mechanics: Individual conditions (e.g., validation accuracy thresholds, license clearances, data bias benchmarks) are evaluated, producing a policy_evaluation record that stores the rule status (pass, fail, warn, error) and its supporting criteria hash.
• Layer 3: Gate Enforcement
  Purpose: Enforces control outcomes based on aggregated rules.
  Mechanics: Gates are the active enforcement checkpoints (gate_definitions, gate_evaluations) that output one of four primary outcomes: Approve, Deny, Escalate, or Inspect. AGEI mandates a deny-by-default stance for high-risk actions.
• Layer 4: Lifecycle Registry
  Purpose: Provides a registry of governed assets.
  Mechanics: Models, datasets, training runs, code snapshots, and software bills of materials (SBOMs) are registered as ai_lifecycle_objects. Hierarchical relationships are mapped using ai_lifecycle_object_links to preserve lineage (e.g., model M was trained on dataset D via run R).
• Layer 5: Receipts
  Purpose: Emits atomic, portable proof of governance events.
  Mechanics: The receipts table captures the core evidence of an event. Every receipt is canonically serialized and cryptographically bound via content hashes and signatures (Ed25519 key signatures).
• Layer 6: Evidence Payloads
  Purpose: Stores rich supporting documentation.
  Mechanics: To keep receipts lightweight, massive files (e.g., training logs, extensive validation sheets, evaluation matrices) are stored as external evidence_objects. These are linked to receipts via content hashes to ensure zero tampering.
• Layer 7: Vault Custody
  Purpose: Assures durable custody, WORM (Write Once, Read Many) retention, and batching.
  Mechanics: Receipts are grouped into Merkle trees via receipt_batches and receipt_batch_items. This generates an immutable Merkle root, allowing efficient, third-party verification of receipt membership without exposing other sensitive receipts in the batch.
• Layer 8: Audit Export
  Purpose: Deterministically materializes and exports review packages.
  Mechanics: When an audit occurs, an audit_pack is compiled to capture a snapshot of receipts, evidence, and rules within a specific scope (e.g., "Q2 Claims Model Releases"). External verifiers can execute verification_jobs to cryptographically prove compliance without direct database access.

3. Lazy Capsule Materialization (LCM)

The fundamental technical challenge of AI governance is that maximal evidence collection crushes runtime performance and balloons storage costs, while weak logging creates unresolvable compliance gaps.

AGEI resolves this using Lazy Capsule Materialization (LCM).

• Continuous Footprints: The system continuously captures lightweight, signed metadata records (footprints) at runtime.
• Lazy Expansion: Fuller, heavier evidence capsules (such as validation packages, raw prompt logs, or manual override chains) are only compiled when explicitly triggered by key events: gate denials, high-risk overrides, human escalations, incidents, or random audit checks.

4. The Five Planes of Agentic AI Governance

As AI systems transition from static text generation to autonomous agents executing multi-step tasks and calling external APIs, output guardrails and prompt filtering are no longer sufficient.

The Agent Governance and Evidence Infrastructure (AGEI) divides runtime control into Five Interconnected Governance Planes.

Technical Detail of the Planes

• Identity Plane (principals, agent_sessions): Establishes exactly who or what is acting. It binds the agent process to a human delegating principal, an assigned role (e.g., "Claims Handler Agent"), and a unique session context.
• Policy Plane (policy_rules, gate_definitions): Evaluates candidate actions against active rules at runtime. It inspects parameters, destinations, risk categories, and data boundaries to determine if the agent's intent is compliant.
• Privilege Plane (agent_delegations, elevation keys): Enforces least privilege. The agent operates with a restricted execution token; any action crossing a risk threshold requires scoped, time-bound, and explicitly authorized privilege elevation (often triggering human review).
• Execution Plane (agent_tool_definitions, wrappers): The runtime enforcement wrapper. Tool calls are blocked or authorized by the execution engine, parameter schemas are validated, and the tool is executed inside an isolated, secure environment.
• Evidence Plane (receipts, agent_tool_invocations): Generates signed pre-action and post-action receipts. It captures what tool was requested, which policy authorized it, what parameters were passed, and what execution state resulted.

5. Proof-Carrying Dynamic Authority Model

An agent must never possess ambient, unconstrained system authority. Instead, it carries its authority through Pre-Action Proof-Carrying Tool Execution.

The Pre-Action Proof Bundle

Before a sensitive tool can be called (e.g., transferring funds, modifying records, accessing confidential tables), the agent must present a pre_action_proof_bundle to the tool wrapper. The tool wrapper will instantly block execution if any component of this bundle is invalid or missing:

• context_hash: Binds the request to the exact session state evaluated by the policy engine.
• policy_check_receipt_id: A reference proving that a valid policy evaluation ran and succeeded.
• authorization_token_hash: Cryptographically references the elevated, scoped authority token without exposing raw secrets.
• delegation_id: Connects the session back to the parent agent or human delegator.
• gate_evaluation_id: Verifies the gate's approved outcome.
• proof_hash: Cryptographically secures the integrity of the entire proof bundle.

6. The Agent Classification Framework

Consistent governance does not mean identical controls. Control intensity must rise in proportion to an agent's authority, autonomy, context access, memory scope, and potential operational consequence.

Organizations classify agents into nine functional categories to determine their required governance tier:

The Governance Tier Equation

To determine the required controls, approvals, monitoring, and evidence, AGEI evaluates the following relationship:

• Authority: What actions can the agent perform on its own?
• Context Access: What sensitive data resources can it touch?
• Memory Scope: Is it Stateless, Session-bound, Persistent, or Organizational?
• Autonomy: Human-in-the-loop (HITL), Human-on-the-loop (HOTL), or Human-out-of-the-loop (HOOTL).
• Impact: What are the worst-case financial, legal, safety, or regulatory consequences of a failure?

7. Denial Receipts as Successful Control Metrics

In traditional logging, a blocked action is recorded as a system warning or error. In AGEI, a denied action is a successful control outcome, and must be preserved as a first-class evidence receipt.

• Proving Active Constraint: Without denial receipts, an organization cannot prove under audit that its policies actively constrained the system in practice.
• Denial Anatomy: A signed denial receipt captures the attempted resource, acting principal, failed rule evaluations, timestamp, decision reason code, and available next-step escalation routes.
• Override Transparency: If a human override occurs, it is never erased. It is written as a distinct, linked, and signed evidence record (gate_evaluations fields: is_overridden, override_reason, override_by, override_at) to ensure total administrative transparency.

8. Stakeholder Value Crosswalk

The AGEI architecture converts abstract commitments to "Responsible AI" into verifiable, measurable security and compliance posture.