Comparison and tradeoffs
Compare the evidence, not the label.
Start with the record your customer needs to review. Existing logs, retention controls and gateways may already do the job. AGA is a narrow signed-record component, not a replacement for that stack.
AGA is before its first external pilot. A published format and conformance corpus are inspectable engineering work, not evidence of independent adoption or customer acceptance.
What each approach provides
Keep the controls that already work.
For a vendor review, compare capture coverage, signing-key trust, independent retention, verification effort and the reviewer's required format. A signature alone does not settle those questions.
- Agent traces and evaluation recordsProvides: observability, debugging and evaluation inputs
- Agent-framework traces can record model generations, tool calls, handoffs and guardrails, and processors can route traces to other destinations. That context is useful for debugging and evaluation. AGA receipts are narrower signed policy-decision records that can be checked offline against a key obtained separately. They do not carry the full run context in an observability trace. Retain the tracing and approved data-export controls you already use; evaluate a separate receipt format only when the reviewer needs that handoff.
- A signed JSON export you maintainProvides: a signature over a defined record
- A small signed export may be sufficient when the producer and reviewer agree on its schema, key distribution and interpretation. AGA provides a specified receipt/checkpoint construction, verifier and conformance materials to inspect. The choice is whether those semantics fit your review and justify the integration and maintenance cost. Signing alone is not unique to AGA, and neither approach establishes complete capture or truthful inputs by itself.
- Your own logs, in write-once storageProvides: retention you can prove
- This is a common existing control. S3 Object Lock stores objects under a write-once-read-many model and can prevent deletion or overwriting; an Azure immutability policy does the same for blob data. These controls address retention. Storage retention alone does not sign a policy decision or establish that an entry was truthful when written. Signed exports and separate collection can be added to a logging system; compare those actual controls rather than assuming all logs are unsigned. AGA composes with write-once storage: retain the storage control and add a record a reviewer can check offline against a specified format.
- Agent gateways with policy logsProvides: deciding on each tool call
- Amazon Bedrock AgentCore documents Cedar policy enforcement for MCP tool calls through its gateway, with identity and input-aware rules, plus CloudWatch policy logs and traces. If that gateway and its evidence meet the review requirement, an additional AGA gateway may add no value. The linked documentation describes the policy and observability features; compare the actual export, reviewer access, key trust, retention and offline verification before deciding how it fits your environment. AGA supplies a separate signed receipt format. It does not replace gateway policy enforcement, CloudWatch or the deployment controls that determine which calls are recorded.
AWS AgentCore policy and observability documentation · AWS observability details
- An agent firewall or SDK that already signs receiptsProvides: signed, offline-checkable decision receipts
- Some tools already sign each decision, chain the receipts, and let a reviewer check them offline with a key they hold. On that property AGA is at parity, not ahead. A signed receipt, from any tool, proves what the key holder signed, not that everything was recorded. If you already run one, keep it. What differs is scope: AGA is one narrow component, the decision record for MCP tool calls, in a published format with a cross-stack conformance corpus in its public repository. Choose on which format your customer's reviewer will accept and which verifier they will run.
- OPA / RegoProvides: general-purpose policy decisions (for example, admission control)
- OPA evaluates policy and supports decision logs, including custom logging integrations. A policy decision by itself is not an AGA-format signed receipt. An integration must specify what is collected, signed, and exported; no drop-in OPA integration is claimed here. AGA's gateway signs each recorded decision into its receipt chain. In-path, 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); effecting a decision beyond that is wired per deployment.
- Artifact signing and software provenanceProvides: artifact signatures and attestations; separate provenance requirements
- Sigstore can sign artifacts and package verification material for offline checks. SLSA addresses software supply-chain provenance. AGA defines a particular policy-decision receipt and checkpoint format. Compare record semantics, identity and key distribution, retained verification material and integration cost. Offline verification alone is not a distinguishing claim. These mechanisms can compose; no drop-in interoperability or completed comparative benchmark is claimed here.
- Blockchain audit trailsProvides: append-only ordering via consensus
- Consensus buys append-only ordering at the cost of latency, expense, and an external infrastructure dependency. AGA gets tamper evidence from signed, hash-linked receipts and Merkle proofs that verify offline, with no network and no consensus. It does not give what consensus gives: protection against the key holder re-signing a different history.
- TEE / confidential computingProvides: hardware-isolated execution
- A TEE isolates execution under a hardware trust model. Attestation can provide evidence about that environment, but it does not by itself establish correct policy or truthful inputs. AGA evidence verifies anywhere with standard Ed25519 and SHA-256. A TEE can harden the gateway without replacing it.
The no-integration option
Do you need another component?
If the reviewer accepts your current evidence, keep it. Adding a gateway brings routing, key custody, monitoring and operational work. A bounded evaluation makes sense when the reviewer needs a portable record they can check outside your environment, and the existing stack cannot provide that handoff.
Some agent firewalls already offer signed, hash-chained receipts and offline verification. AGA is at parity on that property. Compare actual formats and deployment requirements, not a claim that all other logs are unsigned.
One signing key is also one trust boundary.
AGA's published bundle carries recorded policy decisions and their order within a chain. It does not carry build provenance, prove that a tool ran, establish complete capture or prevent the key holder from signing a different history. Independent witnessing and deployment containment remain separate controls.
Architecture reference: four properties and their current coverage
This matrix compares architectural categories, not product rankings. A filled dot describes the narrow property named in its column; it is not a security or compliance certification. Scroll the table horizontally on a small screen.
| Category | Provenancewhere software came from | Policywhat is permitted | Attestationwhat ran | Orderingin what sequence |
|---|---|---|---|---|
Sigstore / SLSA build provenance | ||||
Open Policy Agent (OPA) general-purpose policy decisions | ||||
RATS Attestation platform integrity | ||||
Certificate Transparency append-only ordering | ||||
Attested Governance Artifacts decision records under one signing key |
Filled dot: full coverage. Open ring: partial. Dash: none.
Composing rows 1 through 4 produces four separate trust roots and four verifier procedures. AGA’s bundle carries the recorded decision for each governed call, a hash of its arguments, and their order, under one signing key: full on policy decisions, and partial on ordering, which holds within one gateway’s chain and restarts with a new chain when the gateway restarts. A receipt records a decision, not that the tool ran. aga-proxy records every tools/call it evaluates, except the calls known issue 7 on /security describes as refused without a receipt; its default profile, permissive, denies nothing on policy grounds, and policy denial needs --profile standard or restrictive, or a --policy file in allowlist or denylist mode. Finally, the bundle carries no build provenance, so AGA composes with, rather than replaces, a dedicated build-provenance or platform-attestation system. What it does not deliver is split-view detection, which a transparency log gives only when independent monitors compare the checkpoints they see: the checkpoint is signed inside the operator’s boundary, so a self-contained bundle cannot show that no second history was published to someone else. Where that matters, publish the checkpoint to an append-only log that parties other than the key holder monitor; AGA composes with one rather than replacing it.