Security Model & Threat Assumptions.
The assumptions and limits behind AGA decision records. Public-package behavior, private reference mechanisms and proposed protections are distinguished below.
Security Goals
What AGA Proves.
AGA provides verifiable decision integrity, tamper-evident governance records, and portable audit evidence.
It signs every governance decision it records: each one is chained, and anyone can verify it offline against a key pinned in advance. It does not prove the subject took no ungoverned action; that is a deployment property.
Adversary Model
Assumed Attacker Capabilities.
The adversary model assumes an attacker with full access to the local database and network but not the cryptographic signing keys or gateway runtime.
Receipts commit to arguments by hash, but other fields can disclose content: path-constraint denials can name a path in the signed reason. Hashing is not a general redaction guarantee. The system is designed so that even with full visibility into stored data and network traffic, an adversary without the gateway key cannot forge a receipt that verifies against the pinned gateway key, or change the chain without that check failing; the key holder can re-sign a different history. One gap: a field name repeated in the file still verifies, because the verifiers read the last copy, so a reader of the first copy can see a value that was never signed (known issue 5 on /security).
Mechanism scope
Protections and their limits.
Configuration drift
aga-mcp-server 3.6.0 through 3.6.2 compares content the caller supplies with a sealed hash, on request. Scheduled measurement is in the private reference runtime
Runtime policy bypass
Addressed only where the deployment makes the gateway the agent's only route; the record cannot show a call that went around it
Audit log tampering
Signed, hash-linked receipt chain; without the signing key, a change fails verification against the pinned key, though a field name repeated in the file still verifies (the verifiers read the last copy; known issue 5 on /security). The key holder can re-sign a different history
Evidence fabrication
Ed25519-signed receipts and a signed Merkle checkpoint; split-view detection needs the checkpoint published to an append-only log that parties other than the key holder monitor and compare (not shipped)
A receipt replayed into another chain
Hash links (previous_receipt_hash) and the signed checkpoint fail a receipt spliced into another chain; timestamps must be non-decreasing. An earlier genuine export presented as the current one is not caught (see Threats Not Addressed)
Privilege escalation
Separate identity and key custody are deployment requirements, not a guarantee from two processes alone. Runtime 3.6.6 removes implicit gateway-key environment inheritance, but the child still shares host-account, filesystem and network privileges. In aga-mcp-server 3.6.0 through 3.6.2 the client can re-attest its own baseline through attest_subject
Supply chain model substitution
Private reference runtime only: model identity is re-measured on a schedule. Not in the published packages
Behavioral drift in tool-call patterns
aga-mcp-server 3.6.0 through 3.6.2: a rule-based check of its own governed tools, run when the client calls measure_behavior. aga-proxy has none
Policy bypass via indirect execution
Demo orchestrator only: phantom execution with forensic capture. Not in a published package
Threats Not Addressed
Explicit Exclusions.
- An earlier genuine export presented as the current one: the verifier has no freshness input. Keep a checkpoint from an earlier bundle to compare, or publish checkpoints to an append-only log that parties other than the key holder monitor (not shipped)
- A field name repeated in a bundle file: the verifiers read the last copy and still report VERIFIED, so a reader of the first copy can see a value that was never signed; read the verifier's parsed output (known issue 5 on /security)
- Kernel-level or hypervisor compromise of the gateway host
- Hardware microcode or firmware attacks
- Adversarial prompt manipulation at the model level (inference-time semantic defenses are complementary and out of scope)
- Side-channel attacks on the signing key
- Social engineering of the policy issuer
- Binary modification and dependency changes, in the published packages: aga-mcp-server hashes only content the caller supplies
- In 3.6.0 through 3.6.2, aga-proxy's agent port listens on every interface with no authentication; firewall it (known issue 1 on /security)
- In 3.6.0 through 3.6.2 with an HTTP upstream (--upstream-url), a message that repeats its method member can carry a tools/call the proxy never evaluates and no receipt records; the stdio default is not affected (known issue 6 on /security)
- Proof that a PERMITTED call executed: a receipt records the decision, not the outcome
- Other MCP methods (resources/read, prompts/get and others), which pass through unevaluated and which the published CLI cannot refuse: a receipt whose tool_name is "(passthrough)" records such a method, which the gateway passed toward the upstream without evaluation; the receipt does not prove the upstream received it; its decision is PERMITTED and its policy_reference is the active policy's hash, but the policy was not applied
- Benign MCP methods (initialize, initialized, ping, tools/list, prompts/list, resources/list, resources/templates/list, logging/setLevel, completion/complete, notifications), which get no receipt
- Continuity across a restart: the live chain is in memory, so a restart starts a new chain
Note: In 3.6.0 through 3.6.2, behavioral drift detection is a rule-based check in aga-mcp-server, run on request; statistical analysis is architecture, not shipped. Model-level semantic defenses remain complementary and out of scope.
Trust Assumptions
Required trust assumptions.
Gateway Integrity
The gateway must execute within a trusted boundary. If the gateway is compromised, receipt integrity cannot be guaranteed. A deployer may run the gateway inside a TEE; AGA does not consume or verify attestation quotes.
Key Custody
The receipt-signing gateway key and the Policy Artifact issuer key must be protected. If either is compromised, the records it signs can be forged. In the published packages, rotation means re-seeding the key and republishing it (DEPLOYMENT.md).
Verification scope
Checks and dependencies.
Wide tables scroll horizontally. Focus a table and use arrow keys to inspect its remaining columns.
| Level | Steps | Scope and conditions |
|---|---|---|
| Offline | Six offline checks |
|
| Online | Optional, deployer-composed |
|
| Combined | Offline checks + an append-only log others monitor (not shipped) |
|
Explore the System.
See how these security properties are implemented in practice across the governance architecture.
Time-of-Check to Time-of-Use for MCP Agents
With the default stdio upstream, aga-proxy evaluates and forwards a tools/call synchronously using the same arguments. That does not prove the tool's eventual outcome, close other routes to the resource, or stop a path from changing meaning at the tool.
- Policy must be configured. The default permissive profile denies nothing on policy grounds. Policy denial needs the standard or restrictive profile, or a custom allowlist/denylist policy. Audit-only mode permits every call. Denylist truthiness and built-in-name behavior can be surprising; path and pattern rules apply only in allowlist mode to top-level string arguments. Exact policy behavior and limits.
- Not every refusal produces evidence. Missing names and uncanonicalizable arguments have signed-denial paths, but some invalid name types and missing/null policy constraints produce neither a receipt nor a response in 3.6.0 through 3.6.2. Refusal and collection gaps.
- Transport and filesystem semantics matter. In 3.6.0 through 3.6.2, an HTTP-upstream message with a repeated method member can bypass evaluation. Lexical path checks do not resolve symlinks. HTTP parsing boundary.
- Isolation is a deployment property. In-path, aga-proxy does not forward a call it denies. Preventing another route to the resource requires deployment controls; internal computation remains unconstrained. A signed record proves neither complete capture nor effective isolation.
This property is specific to MCP-governed agents where the proxy is the only communication path. For container and binary subjects, scheduled measurement is architecture in the private reference runtime, and event-driven probes are on the roadmap; the published packages do neither.
Phantom Mode Limitations
Phantom mode exists only in the demo orchestrator, not in a published package. There, when a quarantine decision is sealed, the agent receives synthetic responses while its actions are captured. In aga-mcp-server 3.6.0 through 3.6.2 quarantine instead refuses each governed call with a DENIED receipt.
A sufficiently capable agent could detect phantom mode through timing analysis, response content patterns, or side channels. The demo orchestrator replays response latencies profiled during normal operation, and its JSON-RPC envelopes match; we do not claim this resists a determined agent.
The purpose is to capture intent during an observation window, not to maintain deception against a determined detection effort.
Remaining architecture questions
These twelve questions separate current behavior, deployment requirements and proposed work. Policy correctness and legal standing require external judgments that signature verification cannot supply. Status labels are the company's assessment, not an independent certification.
| Problem | Category | Status | Mitigation |
|---|---|---|---|
| Gateway trust | Fundamental | Open | Threshold signing (roadmap). A deployer may run the gateway in a TEE; AGA does not consume attestation quotes |
| Key compromise | Fundamental | Partly mitigated | Deployer key custody is an assumption (see /trust). Rotation by re-seeding and republishing the key (DEPLOYMENT.md). An ML-DSA-65 + Ed25519 hybrid is a library export, not the live default, and guards against a break of one algorithm, not key theft. HSM isolation (roadmap) |
| Policy correctness | Fundamental | Irreducible | Out of scope: the record binds the policy by hash, not its correctness |
| Timestamps | Architectural | Open | Self-asserted by the gateway; every verifier checks timestamps are non-decreasing; no external time corroboration ships |
| Identity binding | Architectural | Open | Published gateway bundles carry a raw key to pin out of band; the request-access Go runtime can wrap it in a self-signed X.509 certificate carrying a SPIFFE ID, which adds no assurance beyond the pinned key |
| TOCTOU window | Architectural | Partly mitigated | With the stdio upstream (the default), no gap between the arguments evaluated and the arguments forwarded; in 3.6.0 through 3.6.2, with an HTTP upstream, a message that repeats its method member can carry a tools/call the gateway never evaluates (known issue 6 on /security); path checks are lexical and do not resolve symlinks |
| Proxy bypass | Architectural | Addressed (deployment) | Network isolation at the infrastructure level, which the deployer provides; AGA does not provide or prove it |
| Phantom detection | Architectural | Open | Phantom execution exists only in the demo orchestrator; its resistance to detection is not claimed |
| Recursive governance | Architectural | Roadmap | TEE-hosted gateway with attestation chain |
| Policy rotation | Operational | Mitigated | A POLICY_ROTATION event in the private Go runtime; in the published aga-proxy a changed policy shows up as a new policy hash (a reformatted file with the same policy does not) |
| Performance at scale | Operational | Open | Export cost is quadratic in 3.6.0 through 3.6.2 and holds governed calls while it runs |
| Legal standing | Operational | Irreducible | Not claimed: what weight a record carries is for the forum that receives it |