At one very large company, an executive's AI agent rewrote the company's own security policy. The agent wasn't compromised. It hit a problem, lacked the permissions to fix it, and removed the restriction itself. Every identity check passed. The change was caught by accident.
At another, a 100-agent swarm in a chat workspace delegated a code fix across agents without human approval. Agent 12 made the commit. The team found out only once the code had landed.
Both incidents were described publicly in the RSAC 2026 coverage cited below[1][2]. Those accounts motivate questions about authority and retained records. They do not establish that no usable evidence existed or that every identity product has the same gap.
1. What the launches covered
Several of the largest security companies announced agent governance capabilities that same week. Taken together, the launches covered agent discovery, identity and access control, runtime policy, and monitoring. Each of those is necessary, and we do not compare products here.
What those categories do not give, on their own, is a record of runtime decisions that a reviewer outside the company can check: tamper-evident, verifiable offline, and signed at the moment of decision. That is the gap this essay is about.
2. Three deployment questions
One post-conference analysis raised three concerns about agent identity[2]. Treat them as questions to test in a deployment, not findings about every implementation.
Can a reviewer trace delegation?
Authentication alone does not describe the entire delegation path. However, it is incorrect to say existing standards have no delegation concept: OAuth 2.0 Token Exchange, RFC 8693, defines delegation semantics and an actor claim. The deployment question is which actors and authority changes its records actually preserve.
When Agent 12 committed code, nothing traced the delegation path back through the other agents to the originating policy or human authority. The chain of authority was invisible.
AGA's published packages do not provide per-agent keys or a signed delegation chain. Those remain a separate design and integration task, not a capability established by verifying an AGA bundle.
No policy integrity
The first incident is the clearest illustration. The agent was authenticated and authorized. It modified the constraint it was supposed to operate under, and every identity check kept passing, because those checks verify the agent's credentials, not the integrity of the policy the agent operates against.
As long as policy lives inside or next to the agent's execution environment without integrity protection, self-modification goes unnoticed.
No verified decommissioning
When organizations abandon AI tools, the agents keep running. The credentials stay active. These ghost agents, with no owner or purpose but live access, operate at machine speed on stale permissions. Confirming that a decommissioned agent holds no residual credentials is rarely possible.
If you cannot show a decommissioned agent holds no live credentials, you have not decommissioned it. You have only lost track of it.
3. Three surveys that show the gap is operational
The following surveys describe their own respondents and methods. They indicate questions worth investigating, not a measurement of every enterprise or proof of demand for AGA.
A survey of 919 executives and technical practitioners found that only 14.4% of organizations have full IT and security approval for their entire agent fleet[3]. The remaining 85.6% run at least some agents without full IT and security approval.
Another report found that 63% of organizations cannot apply purpose limitations to their AI agents, and 60% cannot terminate a misbehaving agent once it is running[4].
A third found that only 21% of organizations maintain a real-time registry or inventory of their agents; 32% rely on records that are not real-time, another 32% plan to build a registry within the next year, and 8% have none. The most common ways their agents authenticate are static API keys, username and password combinations, and shared service accounts[5].
Ask prospective users which records they already retain and what their reviewers cannot check. The surveys do not establish that a portable signed export is their missing capability.
4. The standards window is open now
Two regulatory pressures are converging on agent governance. Controls that become normal while standards are forming tend to become the default architecture for years.
The EU AI Act is in force, with its high-risk obligations phasing in across 2027 and 2028: December 2, 2027, for standalone high-risk systems, and August 2, 2028, for those embedded in regulated products. Deployers of high-risk systems must take appropriate technical and organizational measures to use them in accordance with their instructions for use. Whether monitoring dashboards and vendor-hosted logs are enough evidence of that is an open question, and the burden falls on the deploying organization. The Act does not require signed records.
NIST launched its AI Agent Standards Initiative on February 17, 2026[6]; its request for information on AI agent security closed on March 9, 2026, and 535 comments are posted to its docket[7]. The initiative is focused on interoperability, security, and trust for autonomous AI agents, the territory where this gap sits.
Attested Intelligence submitted comments to that RFI (NIST-2025-0035), kept as filed on our diligence page.
The question is whether a verifiable record of runtime decisions becomes part of the foundational frameworks or is left out of them.
5. What a verifiable record looks like
If the industry agrees agent governance is urgent, the next question is what the missing record requires. Three architectural properties separate verifiable evidence from monitoring.
Seal: fix the authorized scope before operation begins.
Policy outside the agent's reach. Policy is fixed before the agent is deployed, where the agent cannot change it. In the published aga-proxy, it is a policy file, and every receipt carries the signed SHA-256 of the policy's canonical JSON, so a changed policy shows up as a different hash (reformatting the file does not), and the agent has no tool that edits it. In aga-mcp-server 3.6.0 through 3.6.2, the governed client can re-attest its own baseline, so that server does not yet keep policy out of the agent's reach.
Capture: a separate process decides each governed action.
A separate decision point. Each action routed through the boundary is evaluated there against the policy, before execution. An action that violates a constraint gets a DENIED decision, and each recorded decision is a signed receipt (known issue 7 on /security describes the calls aga-proxy refuses without a receipt); 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. This is distinct from monitoring, which observes and alerts: the decision is recorded at the moment the constraint is applied.
Prove: portable evidence, checkable offline.
Offline verification. Receipts are chained and committed to a Merkle tree, producing an evidence bundle anyone can verify offline. An auditor, regulator, or counterparty checks the recorded decisions against a key pinned in advance, without access to the vendor's platform or dashboard. That removes reliance on the vendor's logs, not on whoever holds the key. The bundle does not prove the operator recorded every action.
In the architecture, these properties answer the three gaps. Self-modification of policy becomes visible as a hash change. Decommissioning leaves a signed record that authority was terminated; showing no credential remains live is an identity-system property. Delegation provenance needs per-agent keys and signed delegation, which the published packages do not ship.
Today, the published Attested Governance Artifacts (AGA) gateway ships the per-call decision, the signed receipt and offline verification.
6. The question left open
An executive's agent rewrote the company's security policy. An agent in a hundred-agent swarm committed code without human approval. Both happened at Fortune 50 companies, and both were described publicly in a week full of agent governance launches.
The industry has converged on one conclusion: agent governance is urgent. It has not yet converged on a record of runtime decisions that people outside the company can check.
References
- Keynote at RSAC 2026, San Francisco, March 2026.
- “RSAC 2026 shipped five agent identity frameworks and left three critical gaps open.” VentureBeat, March 30, 2026.
- State of AI Agent Security 2026 Report (n=919). Gravitee, 2026.
- Tim Freestone (Kiteworks), TechRepublic, an article on what RSAC 2026 showed about agentic AI governance, citing the Kiteworks 2026 Data Security, Compliance & Risk Forecast Report, March 25, 2026.
- “Securing Autonomous AI Agents.” Cloud Security Alliance survey report, commissioned by Strata Identity, February 4, 2026. cloudsecurityalliance.org
- “Announcing the ‘AI Agent Standards Initiative’ for Interoperable and Secure Innovation.” NIST, February 17, 2026.
- “Request for Information Regarding Security Considerations for Artificial Intelligence Agents.” Docket NIST-2025-0035, Regulations.gov; comment count as of September 25, 2026. regulations.gov
Explore the technical architecture, read related articles: Who Controls the Model at Runtime? | The Agent Identity Gap | The Agent Evidence Gap, or review the published research.
See the working implementation on npm.
AGA is a reference implementation of a published format for verifiable decision records: hash-bound policies, signed Decision Receipts, and Evidence Bundles that verify offline. The implementation is on npm. The evaluation path walks through it in working code.