The Boundary Problem

The Boundary Problem #

Every access control system answers one question: what is this actor allowed to do? We have two good answers to it, built up over decades, and they are opposites of each other. AI agents fit neither.

Two answers we already have #

For people, we grant broadly and constrain behaviorally.

A support rep at a bank can usually pull up any customer’s account. A nurse can open most of the charts in the hospital’s system. We do not build software that stops them from opening the wrong record at the wrong moment - we give them access to the whole surface they might plausibly need, and then we constrain them with policy, training, a code of conduct, supervision, and the knowledge that every access is logged and someone might ask about it later. The real boundary is not in the system at all. It lives in prose - handbooks, control narratives, annual attestations - and in the employee’s judgment about which of those small situational limits applies right now.

That works because people are slow, accountable, and good at reading context. A rep who gets a strange request tends to hesitate.

For software, we do the exact reverse. A service gets the minimum set of permissions it needs and nothing more, and it gets to talk to another service only when someone wrote down a business justification for the connection. Before a team ships anything into a regulated environment, they produce a System Security Plan and a control narrative: a document that says what talks to what, why, and how the team will produce evidence that it stayed that way. That process is only possible because deterministic software has a property people don’t have - you can enumerate everything it will ever do, in advance, because its behavior is fixed by its code.

So: humans get a wide boundary held in place by behavior. Software gets a narrow one held in place by configuration. Both work.

Agents are neither #

An agent is software that behaves like a person. It is nondeterministic, it improvises, and it exercises judgment. You cannot enumerate what it will do in advance, because deciding what to do is the thing you bought it for.

That alone would be awkward. Two other properties make it hard.

The first is that agents need a wide boundary to be worth deploying. Scope an agent as tightly as you’d scope a microservice and you get something that can’t do the job. The whole value is that it handles the case you didn’t anticipate, which means reaching tools and data you didn’t specifically anticipate it reaching.

The second is speed. The behavioral controls we rely on for people assume human latency - that there is time between the questionable act and the consequence for someone to notice, ask, and intervene. Agents act in milliseconds and continuously. Mistakes don’t arrive one at a time where a supervisor can catch them; they compound faster than any human process built for people can respond.

So the compliance and security functions are asked to approve something with a boundary far wider than they would ever accept for software, and without the human-speed remedies that make a wide boundary tolerable for people. It is not irrational that they are uncomfortable. It is the correct reaction to what is actually being proposed.

Three panels. A human: a large circle of granted access containing many small dashed circles of situational limits. Deterministic software: a small solid circle inside a large faint field. An AI agent: a small solid circle of what it is trusted with inside a much larger dashed circle of what it must reach to be useful, with the ring between them hatched and labelled the gap.

The result is a gap. There is a set of things we are currently willing to trust an agent with, and a much larger set it has to reach to be useful, and the distance between them is where every one of these programs stalls.

Organizations resolve that gap in one of two directions, and both are bad. They scope down, and ship the agent with no tool access and no proprietary data - which is roughly where the large banks started, JPMorgan’s LLM Suite among them, before adding internal data in stages. Or they scope up and hope.

What happens when you scope up #

On 31 May 2026, attackers took over Instagram accounts - including the Obama White House account - by asking Meta’s AI support assistant to do it. They used a VPN to appear in the target’s region, started a normal password recovery, escalated to the assistant, and asked it to link a new email address to the account. It did, and sent a one-time code to that address. Meta patched it that weekend.

The interesting part is what did not go wrong. The model wasn’t jailbroken in any meaningful sense. Nobody found a clever prompt. The assistant had been given the ability to change contact details on an account, because a support assistant that cannot help you recover your account is not a support assistant. It used that ability exactly as granted. As Check Point put it, an AI system doesn’t have to be compromised to cause an incident - it only has to be trusted too much.

This is the case that role-based access control cannot reach. RBAC answers “may this agent call this tool?” and the answer here was yes, correctly. The support agent should be able to link a recovery email. What was missing was a check on whether the identity verification step that is supposed to precede that action had actually been satisfied - a fact about this request, at the moment of the call, that no role assignment contains.

RBAC is necessary. Nothing here works without it. It is also, on its own, the wrong shape for the problem.

Why no boundary you can draw in advance works #

Put the two Meta requests side by side. Same agent, same tool, same action, same parameters in the same schema. One is the product working. The other is an account takeover. The only difference is context that exists at runtime and nowhere else.

Now try to draw a boundary that separates them.

A jagged region labelled safe and useful. A small dashed circle drawn inside it excludes legitimate work. A large dashed circle drawn around it admits unsafe work. Two dots mark the same tool call - linking a recovery email - one allowed with a verified requester, one refused without one, falling on opposite sides of the jagged edge.

The set of actions that are both safe and useful has a jagged edge. It is not a circle, and it was never going to be one. A circle is simply what you get when you have to commit to the boundary before you know the situation. Draw it tight enough to exclude every bad case and you have excluded most of the good ones with them. Draw it wide enough to include the good ones and the bad ones come along.

Every organization I talk to is somewhere on that trade, and they experience it as a tuning problem - as though there were a correct radius they haven’t found yet. There isn’t. The shape is wrong, not the size.

The market is a layer above this #

It is worth being precise about what already exists, because a lot of it is good.

AWS shipped Policy in Bedrock AgentCore, generally available since March 2026: every agent-to-tool call is intercepted at the gateway and evaluated against Cedar policies, outside the agent’s code and out of reach of prompt manipulation. Okta’s Cross App Access extends OAuth to agent-to-app connections and is now a formal MCP authorization extension. Google gives each agent its own IAM principal with allow and deny policies, and binds its credentials to a trusted runtime with mTLS.

These are real controls in the real path. Anyone claiming this space is still only dashboards and alerts hasn’t looked recently.

But look at what they evaluate. Identity, action, resource, tool input parameters - and rules the customer wrote before the agent ever ran. AWS describes the benefit accurately: set boundaries once, apply them consistently. That is exactly right for software whose behavior you can enumerate, and it is the assumption the whole stack inherits from the era it was designed in.

None of it asks the question the Meta case turned on: does this action match the purpose it was authorized for, given what has actually happened in this session? That is a different question from “is this call permitted,” and it is the one that separates the two dots in the diagram.

Dynamic trust boundaries #

What I think has to happen is that the boundary gets declared broad and resolved narrow.

The organization keeps writing the artifact it already knows how to write - a control narrative that says this agent may operate over these systems for this purpose. That boundary is wide, wide enough for the agent to be useful, and it is reviewable by the people whose job is to review it. What changes is that it is no longer the last line of defense, so it doesn’t have to be drawn defensively.

Underneath it, each individual call gets decided in context: who delegated this, what task was it delegated for, what has this agent already done in this session, has the precondition this action assumes actually been met. The effective boundary moves between the two extremes at runtime, tightening to something close to least privilege for any single call while the declared envelope stays broad enough for the agent to do its job.

That is what I mean by a dynamic trust boundary. Not a bigger circle or a smarter one - a boundary whose shape is computed at the moment of the action, from facts that only exist at that moment.

It also happens to be the only version I can see where the compliance conversation ends in a yes. You cannot get a regulated institution to approve a static boundary wide enough for a useful agent, and you shouldn’t be able to. You can get them to approve a wide envelope with real enforcement inside it, because that is a control they can describe, test, and produce evidence for.

This is the problem Aegis is built around: identity that binds an agent to the task it was given and the person it acts for, policy evaluated on every call in the path, a human checkpoint for the gray zone, and a record of what was decided and why. The boundary is still yours to declare. What we’re after is that it stops having to be a guess.