The three gaps no framework closes

I'll be honest about what is easy here and what is not.

Most of the work of securing an AI agent is well-covered ground by now. Give it its own identity. Sandbox it. Watch what it does. Gate the dangerous actions behind a human. The published frameworks, from the labs to the cloud providers to the standards bodies, handle those layers well, and this control set crosswalks all of them.

The interesting part is what is left over. When I mapped everything against everything, three gaps kept showing up where a fully secured, governed, signed agent still leaves you exposed. No framework I could find closes them. They are the reason I think a unified crosswalk needs to exist, and they are the places I planted a flag of my own.

One note before the three. Each comes with a control I propose, and those proposals are mine: my read of where things are heading, not something a standards body has published. I keep that line bright on purpose. Getting credit right cuts both ways. I won't claim someone else's work, and I won't hang my own guesses on their name.

1. Your careful rules stop at your own front door

You can do everything right inside your own walls. Each agent has its own identity, short-lived keys, a human approval step on anything sensitive, full logging. Then your agent calls an outside agent or a vendor API you do not control, and that call routes through their agent layer, under their rules, or under no rules at all.

Every identity and permission guarantee you built ends at your organizational boundary. The individual pieces exist, but I could find no standard that composes them into a complete model for how trust, attribution, or revocation work across that boundary. If the partner's agent misuses your data, you often cannot even evidence what it did.

The control I propose is to down-scope the token before it leaves your boundary. Strip it to read-only, or to the single resource the external call actually needs, so a credential that escapes is worth as little as possible on the other side. It builds on existing pieces (OAuth, token exchange, signed agent cards), but no protocol specifies the scope degradation itself yet. Be clear about what this is, though: it does not create cross-organizational federation, downstream attribution, or revocation that travels across the boundary. It is the compensating control I would run until those exist, not a solution to the gap.

Where might this eventually get solved? The likeliest venues are the cross-vendor ones: the Coalition for Secure AI at OASIS, and NIST's AI Agent Standards Initiative, which stood up in early 2026. And the foundation underneath is beginning to form: NIST's NCCoE identity work and the Agent Standards Initiative point at the portable, verifiable identity (SPIFFE, DIDs) that cross-boundary trust would need. None of it closes the gap today. But that is the direction to watch.

How the different teams should hold it:

• If you build: down-scope tokens to the minimum before they cross the line.
• If you detect: alert on any cross-org call that returns more than it should.
• If you red-team: try to replay a partner's token back into your own environment.
• If you own risk: record the boundary as a known limit. You cannot yet prove what the external agent did with your data.
• If you respond: you can revoke your side's tokens and cut the connection, but you cannot reach into the partner's environment, so contain at your boundary and preserve whatever crossed it.

2. If an agent causes harm, can your logs stand up?

Picture the incident. A supervised agent took an action that caused real harm, and the monitor's logs are the primary evidence of what happened and why. Now the lawyers, or the regulators, are in the room. Are those logs admissible? Can you show they were not altered? Who is the named owner, and how long are they kept?

General digital-forensics standards (such as ISO/IEC 27037) govern electronic evidence broadly, but I found no agent-specific framework that defines the full chain-of-custody for agent-action logs in a legal or regulatory investigation. And this is on a collision course with the EU AI Act, whose Article 12 requires automatic logging with at least six months of retention for high-risk systems. The obligation is arriving before the practice is settled.

Readiness is nowhere near it. In a 2026 CSA and Strata Identity survey, 84% of practitioners doubted they could pass an audit of their agents' behavior. The duty to produce trustworthy records is arriving years ahead of most teams' ability to produce them.

My proposal here is a write-once, tamper-evident ledger: hash-chained, kept outside the agent's reach, so the agent cannot rewrite or delete its own history. Be precise about the limit: tamper-evident storage is the integrity foundation of chain-of-custody, not the whole chain, which also needs collection procedure, synchronized time, the collector's identity, access records, preservation, and named accountability. And on the law: Article 12 mandates the outcome (automatic logging and retention); the cryptographic hardening is my recommended implementation to make that record survive an adversarial audit, not something the regulation's text requires.

How the different teams should hold it:

• If you build: write logs to a tamper-evident store the agent cannot touch.
• If you detect: those same logs are your detection source. Protect them first.
• If you red-team: try to make the agent rewrite or delete its own audit trail.
• If you own risk: map these logs to Article 12 and name a retention owner and horizon.
• If you respond: the ledger is your incident timeline, so the first move is to preserve and snapshot it before anything, including a compromised agent, can touch it.

3. What guards the guard?

Every layer above assumes the security tooling itself is trustworthy. But a compromised supervisor agent, a poisoned policy engine, or a tampered governance tool turns your control plane, the thing making the decisions, into the attack surface. The threat model for the security and governance tooling is the least-written part of this whole field.

If the monitor watching your agent runs on the same model with the same context, an attacker who can manipulate one can often manipulate both.

The leading edge here is the frontier labs starting to treat the monitor itself as something that can be attacked. Google DeepMind's 2026 AI Control Roadmap, for one, treats internal agents as potential insider threats and layers escalating detection tiers over them. It is among the most developed public work in this direction I found, and even it does not fully close the gap. That is how early this is.

My proposal is asymmetric supervision: run the monitor on a separate, more constrained model so it does not share the supervised agent's full attack surface. The load-bearing word is separate, separate model family, context, privileges, administration, and failure modes; smaller can help keep it constrained and cheap, but smaller alone is not safer (a weaker model can simply be easier to evade). And it is a compensating control, not a fix: it reduces shared exposure, it does not by itself secure the security layer, and overstating it would be exactly the kind of thing I built this to avoid.

How the different teams should hold it:

• If you build: run the monitor on a smaller, separate model with less shared surface.
• If you detect: monitor the monitor. Watch for the supervisor going quiet, or always approving.
• If you red-team: target the policy engine and the approval channel, not just the agent.
• If you own risk: treat the security tooling as in scope for its own audit.
• If you respond: treat the supervisor and policy engine as incident-worthy assets themselves; if one is suspect, fail closed and fall back to a human gate.

None of these has a tidy answer yet

That is the point. I would rather name them plainly and propose a starting position than leave them in the white space, where they are easy to miss until an incident finds them for you. If you have a better answer to any of the three, I genuinely want to hear it.

You can see all 52 controls, including the ones that back these three positions, at apeiris.ai.

Sources

• RFC 8693, OAuth 2.0 Token Exchange · A2A Protocol v1.0.0
• EU AI Act Article 12
• CSA + Strata Identity, Securing Autonomous AI Agents (2026 survey)
• Google DeepMind, Securing the future of AI agents (AI Control Roadmap)
• Coalition for Secure AI (CoSAI) · NIST AI Agent Standards Initiative