Forrester's six AEGIS domains, and what closes each

AEGIS is Forrester’s framework for securing agentic AI: Agentic AI Enterprise Guardrails for Information Security, written for the CISO who has just been handed responsibility for agent traffic. It names six domains of control, from governance and identity through to zero trust, and says what has to be true in each. It names no component and no vendor.

That silence is the framework working. Where a control becomes true is an architecture question, and it has a different answer per architecture.

Our answer is that most of what AEGIS asks for can only be enforced by a process holding the connection at the moment the request is made. A control upstream of that moment constrains what the code was likely to do. A control downstream of it describes what already happened. For the traffic that existed before agents the six domains had six owners and six budgets, and for a prompt and a tool call they collapse onto one moment.

What AEGIS changes

The framework’s move is to say that the object of security is now intent.

Infrastructure is something drawn in advance. A vendor was assessed, an integration was scoped, an agreement named the data categories. Intent is typed fresh, by anyone, thousands of times a day, and an agent acting on it reaches a tool nobody put in the diagram. The other two ideas follow. Least agency says an agent should hold the smallest reach that lets it finish. Continuous assurance says the check runs while the work runs.

Both are statements about a moment. Neither is discharged by a document, and neither is discharged by a component reading a copy of the traffic afterwards.

One request, and the domains it crosses

An agent has decided to issue a refund, and the call is on its way to a tool server.

The credential arrives first. A token from your identity provider is verified against an audience that names the gateway, and two principals come out of it: the agent, which is the workload or the client the token was issued to, and the person it is acting for. They stay separate for the rest of the request. Identity is settled before any content has been read.

The body is read next. The arguments of the tool call are scanned the way a prompt is scanned, because personal data travels in tool arguments more often than anywhere else, and a span that matches is rewritten in the pass that found it. 83 identifier types, 51 of them checksum-validated, 19 kinds of credential. The rewriting is the part that makes it a control.

Then the call itself. One rule reads the server, the method, the tool by name, its arguments and both principals in a single condition. A refund above five hundred with no person behind the agent is refused before the server hears about it. When the tool call is the attack surface, the argument is the payload, and this is where application security for an agent actually happens.

The injection check that read the body ran on a model loaded into the gateway’s own process, so the verdict cost a function call and no round trip. That is the runtime, and the detection content in it is somebody else’s. The decision it produced goes to your collector, which is threat management up to the point where a person has to read it.

Nothing in any of that inherited a permission from the request before it. Identity was presented, the rule was evaluated for this request, and a refusal stopped the call. Zero trust as behaviour.

What comes out is one signed record: the rule that decided, the spans a redaction rewrote, the control identifiers the rule named, chained to the record before it and signed by the node that made it. That record is what the governance programme reads.

The domains close together because this is the only moment identity, content and action are in the same place.

Three layers, and what each decides

A request meets three policies here, written in two languages, and they decide different things.

Access rules decide whether the call may be made at all. One CEL condition over one request at one hop, reading who is calling and what the call is: the model and the route at an LLM hop, the server, the method, the tool by name and its arguments at an MCP hop. Deployment-wide rules run first and a profile’s own rules run after them and can only narrow. A deny at the deployment level is final, and an allow there ends that list without skipping the profile’s, so a permissive profile is no way to opt out of an org-wide rule. A condition that cannot be evaluated refuses the request, because a deny rule that a large enough argument list could switch off is not a deny rule.

Guardrail rules decide what to do about what is in the content. The detectors annotate a request, and CEL over those annotations rewrites a span, refuses the call or lets it through.

The Cedar policy decides who may change either of those. It is the admin plane, it denies by default, and it never sees a request body. Roles come from a claim your identity provider sets, so a change to a rule is attributed to a person and lands in the same trail as the decisions that rule goes on to make. There is no shared admin secret to hold.

A Cedar policy cannot read a request. An access rule cannot authorize an API call. Each one stays small enough to be right.

The six AEGIS domains

Forrester’s own advice for assembling a stack is to start from the control gap, trace it to the technology categories that close it, and check what the tools you already run cover. The third column is written for that. It names what closes the rest of each domain, and in every row some of it is not us.

Under each domain name is how much of it is ours. Held is work done while one process holds the connection. Through is work done on something we do not own. Theirs is a domain that belongs to somebody else, where the most we do is feed it.

How an AEGIS domain reaches the record

A control identifier is an opaque string a rule carries and the gateway never reads. Put aegis:iam on a rule and every decision that rule makes carries it onto the record, exactly the way eu-ai-act:art-50 does. A decision made at half past two on a Tuesday can be found a year later by the control it served, which is what the governance domain’s row above is for.

There is no AEGIS mode, and the word appears nowhere in the code. Which domain a rule discharges is your security team’s reading, and whether it is discharged is your assessor’s finding. A vendor who tells you a framework is satisfied has handed you a reading you will inherit without being told when it goes wrong.

Where the boundary falls

Identity is the row to press on. The gateway is a resource server: it verifies a token that names it in the audience and it mints nothing. A product claiming both enforcement and identity is describing an identity provider.

Threat management is the same shape at the other end. What we own is the runtime and the decision, and most of the checkpoints loaded into it are other people’s. The people reading those decisions at three in the morning are yours.

If something else already holds the connection

An API gateway with an AI plugin, or another AI gateway, is in the same position on the path and can do much of this. The question worth putting to any of them, and to us, is what comes out the other side.

A log is a record a system keeps about itself, in a store that system controls. Ours is chained to the record before it on that node and signed with that node’s key, and kirto-gate audit verify reads a trail and reports every record that was altered, removed from the middle, moved or forged, by sequence number. That is a check somebody who trusts neither the gateway nor the store can run.

The second difference is how narrow a refusal can be. One rule reads the tool by name, its arguments, the agent and the person behind it in a single condition, so a call is refused on what it would do and on who is behind it at once.

What least agency costs to claim

Least agency is the sentence worth pressing on, so here is where ours stops.

An agent and the person behind it are separate principals in every rule at every hop, and a rule can narrow on either. A chain is not represented. One agent and one person per request, so a call that went agent to sub-agent to tool names the caller and not the delegation that produced it. Scopes are requested per configured credential, so an agent can be given less reach at a tool server and cannot be given less reach at the third step of a chain than at the first.

And no rule can require that the outbound credential was exchanged at the upstream’s issuer. That exchange is configuration, and no variable in the policy vocabulary names it, so it is a deployment property and not a decidable one.

Three gaps on our own axis, and they are worth more written down than argued about.

When this is the wrong answer

If the AI traffic is one application in one language with no agent talking to a tool, the SDK your governance platform ships sees almost everything a gateway would and is already joined to the binder. That stops working at the first service that does not embed it, and until then it is the cheaper answer.

If nobody outside the organisation will ever verify one of these records, the signing is a cost with no reader, and the prevention half of this stands on its own. Most of the framework is still worth doing. Some of it is not worth doing with us.