The seams are where agents break

There is a moment that should worry anyone running AI agents in production. You have given an agent its own login, scoped its permissions, put a human approval step on the risky actions, and you are logging everything it does. Every box checked. Then the agent calls out to a partner's API that routes through their agent, and every guarantee you just built stops at your own front door.

That gap, and a handful of others like it, is why I built this.

The problem isn't a shortage of guidance

Over the past year, just about every serious player in security started publishing guidance for autonomous agents. The frontier labs. The big cloud providers. The standards bodies. The identity vendors. The endpoint vendors. That sounds like good news, and in a way it is.

The trouble is they are not building one framework. They are each building a different layer of the same stack, and the layers do not meet at the seams. One vendor owns identity. Another owns runtime detection. A standards body covers governance. Nobody publishes the thing that ties them together.

If you are the person who actually has to secure these systems, that leaves you doing the integration in your head. I kept trying to hold the whole picture at once, and at some point I couldn't anymore. So I wrote it down.

And this is not a someday problem. In a 2026 survey of around 285 practitioners by the Cloud Security Alliance and Strata Identity, 40% already had agents in production, only 18% were highly confident in how they manage agent identity, and 84% doubted they could pass an audit of their agents' behavior. The agents are already in production. The controls to govern them, and the proof that they work, mostly lag behind.

What actually makes an agent dangerous

Here is the part that reframed it for me. What turns a capable model into operational risk is not capability alone. It is orchestration: the scaffolding around the model that lets it choose and chain steps on its own.

A definition, since the rest of this rests on it. In this control set, an agent is software that uses a model to choose or sequence actions and tools toward a goal, with some degree of autonomy. A chatbot that only returns text is not the same animal as a system that can call tools, change state, delegate to other agents, or keep going without a person approving each step. The controls here are aimed at that second kind.

Anthropic put numbers on this in June 2026. They mapped a year of real AI-enabled attacks onto MITRE ATT&CK, the standard catalogue of attacker techniques, and found that the highest-risk actors were not the most technically sophisticated, and did not use the widest range of techniques. They were the ones who built scaffolding to let the model run the attack itself. One espionage campaign they disrupted hit a maximum risk score using a fairly ordinary count of techniques, because the attacker wired open-source penetration-testing tools into a coding agent and let it drive the operation.

The uncomfortable conclusion: the threat catalogues most security programs start from do not yet have entries for autonomous orchestration, the model deciding in real time what to do next. The taxonomy lags the behavior. MITRE has started to catch up, and ATLAS now carries some agentic technique IDs. But the orchestration itself, the model choosing its next move, still has no first-class entry. A control set that only maps to today's threat IDs inherits that blind spot, so I treat closing it as its own control, and I label that as my own position rather than pretending a standards body has said it.

One stack, six layers

Read across all that published guidance and a defense-in-depth stack falls out. I organize the Security domain into six layers:

1. Identity and authority: who the agent is, and what it is allowed to do.
2. Environment and containment: where it runs, and what it can reach.
3. Inter-agent and tool protocols: how it talks to tools and to other agents.
4. Governance and human-in-the-loop: who approves, and what is on the record.
5. Runtime supervision and detection: what it actually does, watched live.
6. Continuous assurance: proving it before it ships, and re-proving it as it changes.

Fifty-two controls sit across those six layers. Each one names the threat it stops, the standard that backs it, how to put it in place, and the part I care about most: how to prove it is working.

Those six layers are not my invention, and that is deliberate. Google's own published approach to securing agents boils down to three principles: an agent needs a well-defined human who controls it, powers limited to its task, and actions you can actually observe. The six layers are my synthesis of that crosswalk, made concrete and carried across the whole lifecycle; that an independent group reasoning from scratch landed on a similar shape is a useful check, not a proof that this exact split is the only right one. And I did not invent a new control framework either. The field already has two control sets worth building on, CSA's AI Controls Matrix and NIST's forthcoming control overlays, so I anchored to those and crosswalked everything else against them. The thing I am adding is the crosswalk none of them publishes in one place. The last thing this space needs is another standalone taxonomy.

The plane that makes the layers enforceable

The six layers describe what has to be secured. They still need somewhere to meet while the agent is running. Read the control set by plane and the shape of it shows: a control plane decides who the agent is and what it may do; a data plane watches what it actually does. The recurring failure is that a permission granted in the control plane is rarely re-checked against what the data plane sees.

What closes that gap is not a seventh layer. It is a cross-layer substrate I think of as the agent runtime enforcement plane: the in-path gateway that, for every attempted action, identifies the acting agent and its delegation chain, evaluates policy against the current state, brokers only the short-lived credential that one action needs, and writes the decision and result to a tamper-evident record. Identity, protocols, governance, and runtime response all converge there, and it is where advisory policy is meant to become enforceable. The concrete component is plain enough that it deserves a plain name: the agent action gateway, the point every agent action is meant to pass through.

Two design points matter. The agent never holds broad standing authority and never decides whether to use the gateway. And the plane is logically one thing but should be physically several, a decision service, a credential broker, an approval service, an audit store outside its own trust boundary, so that compromising the gateway does not also let it mint credentials, rewrite its own logs, and approve its own requests. That separation is the same "what guards the guard?" instinct behind the third gap below. The plane owns the seams inside one trust domain; the moment the chain crosses into another organization, you are back at the first gap.

A control nobody can prove is not a control

That last point was the thing I wanted and couldn't find anywhere else. It is easy to write a list of controls. It is harder to show that any of them actually holds. So every entry carries three checks: is it configured (a design check), does it hold up under attack (a runtime test), and what artifact proves it on an ongoing basis (the thing an auditor or an investigator will eventually ask you for).

And because the person reading any given control might be an engineer, a detection analyst, a red teamer, someone in GRC, or someone in a SOC at two in the morning, every control is written to read clearly to each of those readers. Plain language, not acronym soup. You should not need ten years in the field to use this, and you should not feel talked down to if you have them.

The three gaps

The six layers are well covered by the existing guidance. The real value, the reason a crosswalk needs to exist at all, is the seams none of them close. I found three:

• Cross-organization agent identity federation. Your careful rules stop at your own front door.
• Chain-of-custody for agent-action logs. If an agent causes harm, can your logs stand up as evidence?
• Securing the security layer itself. What guards the guard?

I propose a control for each, and I am clear that these are my positions, not anyone's published standard. They get their own post.

How to use it

If you run agents in production, do not wait for a unified standard. There isn't one. Map what you are running against the six layers and start with the layer you find empty. Running tool chains with no agent-identity verification? Identity is your most exposed surface. Multi-agent workflows where nobody's authority is defined? Governance is the gap. High-autonomy agents reaching outside with little human review? Runtime supervision is the gap.

A lot is about to land. NIST stood up an AI Agent Standards Initiative in early 2026 and has agentic control overlays (the COSAiS work) still to come; the Coalition for Secure AI at OASIS is pulling vendors toward common ground; and the EU AI Act's logging duties are already in motion. None of it has converged yet, but the direction is clear, and this control set is built to move with it. That is the whole reason it is data-first and not a static PDF.

If you want a starting set rather than a layer, here is the minimum I would not run an autonomous agent without: a distinct identity per agent (IA-01) with short-lived, scoped credentials (IA-02); a sandbox matched to what it executes (EC-01), with default-deny egress (EC-02) and least file-and-tool access (EC-04); validation of tool input and output (PT-04); a human hard-stop on irreversible actions (GV-01) over a tamper-evident audit trail (GV-02); OS-level telemetry (RT-01) with prompt-injection detection (RT-02); a tested external pause/kill switch (RT-04); and a real pre-launch red-team (AS-01). That is twelve controls. Tier up from there by how much autonomy, external reach, irreversibility, and regulated data each agent touches: the more of those, the more of the control set you pull in.

The control set is built to be filtered, scored, and exported, so you can find your own hole and close it first. It is free for individuals and for education, it is sourced down to primary documents, and it is meant to be a living thing that tracks the standards as they land. Mistakes are possible, and I would rather hear about them than pretend they aren't there.

apeiris.ai

Sources

• Anthropic, LLM ATT&CK Navigator + ARiES (Jun 2026) and Disrupting an AI-orchestrated espionage campaign / GTG-1002 (Nov 2025)
• CSA + Strata Identity, Securing Autonomous AI Agents (2026 survey)
• Google, An Introduction to Google's Approach for Secure AI Agents
• CSA AI Controls Matrix (AICM) · NIST COSAiS overlays · NIST AI Agent Standards Initiative · Coalition for Secure AI (CoSAI)
• MITRE ATLAS · EU AI Act Article 12