Govern the workflow. Keep the evidence.

An agent can invoke tools and change external state. Governance needs both controls over those actions and evidence a reviewer can understand. AGA contributes signed decision records; it does not supply the whole control system.

Check a static record The vendor review workflow

Two questions

Was the action controlled? Is the record checkable?

These are separate questions. Permissions, gateway routing and upstream controls affect what the agent can do. Signatures and retained exports affect what another party can check afterward. Neither a signed receipt nor an ordinary log alone proves complete capture.

Existing governance can cover both generated outputs and external actions. Content filters, authorization services, policy engines and protected logging are complementary or competing components, depending on the deployment. Compare their actual evidence properties.

The AGA boundary

One recorded decision, signed and exported.

Set a policy

The public proxy reads a JSON policy file and signs its canonical hash into each receipt. The policy file itself is unsigned.

Record a decision

The proxy evaluates routed tool calls. The default permissive profile denies nothing on policy grounds; known coverage gaps are disclosed.

Verify the export

A reviewer checks retained receipts and the signed checkpoint against an expected key, without calling the producing service.

Process separation is not key isolation. The agent must run under an identity that cannot read the gateway’s secrets, and the deployment must control alternate paths. In 3.6.0 through 3.6.2, a key passed by environment variable is inherited by a stdio upstream. Read the current limitations before runtime evaluation.

What verification proves, and does not

A verified bundle proves the integrity of every receipt present, as the verifier parses it: a field name repeated in the file still verifies, because the verifiers read the last copy (known issue 5 on /security). It does not prove the operator recorded every action.
A PERMITTED receipt records a governance decision, with two exceptions. A receipt whose tool_name is "(passthrough)" records an MCP method the gateway passed toward the upstream without evaluating it, and does not prove the upstream received it. An aga-mcp-server measure_behavior receipt records a drift finding, marked PERMITTED when the finding is not enforced. A receipt does not prove the tool call executed, or what it returned.
Receipts prove decisions were recorded and signed. They do not prove the agent could not bypass the gateway; interception placement is a deployment property.

Requirements map

What ships, and what remains yours.

These are example approaches, not claims that every alternative lacks a capability. Each AGA contribution has a defined scope.

Bounded autonomyPermission scoping, RBAC: A policy file lists the permitted tools; aga-proxy signs the SHA-256 of the policy's canonical JSON into each receipt
Monitoring scopeLog aggregation, anomaly detection: aga-proxy signs a decision for each tool call it evaluates (known issue 7 on /security describes the exceptions); scheduled measurement is in the private reference runtime, and aga-mcp-server measures on request
Enforceable controlsAuthorization services, gateways and policy engines: Two-process boundary; aga-proxy does not forward a call it denies (its default profile, permissive, denies nothing on policy grounds; policy denial needs --profile standard or restrictive, or a --policy file in allowlist or denylist mode). The agent holds no signing key when the gateway runs under an OS identity the agent cannot read.
Oversight evidenceDashboards, periodic reports: Signed receipts and evidence bundles with Merkle proofs
Audit trail integritySigned logs, append-only storage and write-once retention: Hash-linked receipts under a signed Merkle checkpoint
Offline verificationSigned exports or a service-dependent review path: Evidence bundles verify with standard crypto. No network required.
Drift responseAlerts, automated responses or human review: In aga-mcp-server, a response chosen from the actions its sealed artifact allows, recorded in an in-process signed receipt that the exported bundle does not include; handler wired per deployment

Framework context

A contribution, not certification.

The standards page maps specific mechanisms to selected NIST AI RMF, EU AI Act, CoSAI and SSDF items, including what AGA does not address. The OWASP analysis is a separate dated discussion.

A record cannot establish policy correctness, organizational compliance or effective human oversight on its own. The security overview and threat model define the technical assumptions.

Questions about the boundary.

What is agentic AI governance?

Agentic AI governance covers the ownership, permissions, monitoring and review of systems that can invoke tools or change external state. AGA addresses one part of that work: a signed, portable record of the decisions its gateway recorded. Other controls are still needed for identity, routing, safe execution and human oversight.

How is agentic governance different from AI governance?

It focuses on the additional risks of systems that take actions, such as unauthorized tool use and changes to external services. Broader AI governance can cover both output and action risks; they are not mutually exclusive categories, and signed evidence is not a substitute for either set of controls.

What does a signed decision record add to governance evidence?

It gives a reviewer a portable record whose signed values can be checked against a key obtained in advance. Ordinary logs can also be protected by signatures or write-once storage; the question is what each record binds and what a reviewer can verify. Against a pinned key, changing a signed value without that key fails verification. The key holder can re-sign a different history. Repeated field names still verify when the last copy holds the signed value (known issue 5 on /security), so use the verifier's parsed output. A pass does not prove execution, complete capture, or freshness.

How does AGA govern agents at runtime?

Seal, Capture, Prove names the architecture. In the published aga-proxy, the policy is an unsigned JSON file whose canonical JSON hash is signed into each recorded decision. The gateway does not forward a call it denies; whether another route exists is a deployment property. The agent lacks the signing key only when the gateway runs under an OS identity the agent cannot read. Exported receipts verify offline. Known issues 6 and 7 on /security describe gaps in receipt coverage; the default permissive profile denies nothing on policy grounds. Policy denial needs --profile standard or restrictive, or a --policy file in allowlist or denylist mode.

Does AGA work with existing governance frameworks?

In part. AGA supplies signed, offline-verifiable records of the decisions it records. The control-level mappings on /standards identify the limited contribution of shipped mechanisms and the requirements they do not address. The OWASP discussion is on /blog/governance-gap. None of these mappings is a certification or a claim that AGA satisfies a framework on its own.

Technical architecture Architecture definition Discuss one workflow