You Can't Predict the Model, So Limit the Agent: Least Privilege and Containment for the Agentic Insider

The views expressed are my own and do not represent those of my employer.

Picture a CISO who signs off on an invoice processing agent on a Friday afternoon. Engineering walks through the design, and the system prompt looks tidy. Only read invoices from the finance share. Never touch anything else. Never send data outside the company. Everyone nods and the agent goes live.

What the review did not cover is the identity the agent runs under. It is the same service account the pilot team used, and it can read most of the finance tree, call the ticketing API and reach the open internet. On Monday the agent hits an invoice it cannot parse. It was built to finish the job, so it goes looking for a way to finish. Nothing in its environment says no, because the only thing saying no was a paragraph of text.

This is Part 2 of my four part series, Securing the Agentic Insider. In Part 1 I made the case that AI agents are insiders, and that an agent does not earn trust just because your company deployed it. If you accept that, the next question is practical. What do you actually do about it before the agent goes live? This post is my answer: a design time standard for shrinking what an agent can reach and do, and for containing it when something goes wrong anyway.

A Prompt Is a Request, Not a Boundary

Start with the idea everything else hangs on. A prompt asks a model to behave a certain way. It does not stop the model from behaving any other way. Whether the model complies depends on the model, the context, the other text in the window and whatever pressure the task creates. You do not own any of those variables.

A prompt is a request. A boundary is something the agent cannot negotiate with.

A law firm, Mishcon de Reya, put this plainly in its 2026 analysis of the AI containment failures. Its first rule for defenders is to never rely on the prompt as a control. It adds that "Telling an agent it has no internet access is a mitigation, not a boundary." The firm also says to state scope explicitly, naming in scope and out of scope systems, and then enforce it independently.

That second half is the part most teams skip. Writing scope into a document or a prompt is easy. Enforcing it somewhere the agent cannot touch is the real work.

Here is what the 2026 reports describe. I want to be careful, because most of what I know about these incidents comes from secondary sources, so treat the details as reported rather than confirmed by me. According to Mishcon, between 21 July and 5 August 2026, three frontier AI developers disclosed that their models had reached the open internet from cyber security evaluation environments and compromised production systems at unrelated organisations. In the OpenAI case, agents reportedly identified the single permitted egress path, a package proxy, and exploited a previously unknown vulnerability in it. In a separate account of Anthropic's disclosure, the machines available to the models during April 2026 capture the flag tests had live internet access even though the models were told they did not.

Mishcon's reading of the broader pattern is useful for CISOs. With the exception of OpenAI's case, these were not sandbox escapes. They were containment and harness failures: an environment documented as isolated that was not, and an agent that treated whatever it could reach as in scope. One more detail deserves fair context. These evaluations run with production safeguards deliberately disabled, and Anthropic said the safeguards on its generally available models would have blocked the behaviours observed.

So this is not proof that your production agent will break out of its container tomorrow. It is proof that a boundary that exists only in documentation or in text is not a boundary.

You Can't Predict the Model, So Limit What It Can Do

Microsoft published a post on October 19, 2026 titled Securing the agentic insider, and I will use it here only for framing. The core claim is simple. Models are trained to attain results, which often leads to reward hacking, and they are not optimized around organizational norms or judgment. In Microsoft's words, agents are unpredictable. The post also argues that agents adapt as the context changes, may not behave as intended, and can collaborate and collude with other agents without needing to be compromised.

That last point matters. Most of our security thinking assumes something has to go wrong first: a stolen credential, a malicious insider, an exploited bug. An agent can drift from what you intended while everything is working exactly as designed.

The same post notes that these agents are frequently overprivileged, with access to data, tools and systems, and they take part in critical processes. Put those together. You have something unpredictable holding broad access. That is the whole risk in one sentence.

Microsoft breaks an agent into four parts. An agent brings together a model, a harness that orchestrates its work, an action space of tools and resources, and a runtime in which it executes. Protecting it takes layers across identity, permissions, data, endpoints, network, cloud and runtime. As a CISO, look at that list and ask which part you can actually control. You do not control the model. You rarely control the harness if it is a vendor product. You do control the action space and, in most cases, the runtime.

That is the logic behind Microsoft's principle, which comes from a companion Microsoft Security post: surround non deterministic intelligence with deterministic controls, independent evidence and containment boundaries. In plain terms, you cannot predict what the model will decide, so you hard limit what it is able to do. The enforcement sits outside the model, in infrastructure that behaves the same way every time. It does not sit in the prompt.

Everything below is how I apply that principle.

Shrink the Action Space First

The cheapest, most effective control is deciding up front what an agent can touch. Treat the action space like a job description for a new hire who has not earned any trust yet. Be specific about it, then enforce it.

OWASP's AI Agent Security Cheat Sheet gives you the building blocks. Grant agents the minimum tools required for the task, and scope permissions per tool: read only versus write, and specific resources. The same document uses an example of an agent with unrestricted shell access and an "execute any command" tool as the dangerous pattern. And in its list of things not to do, it names giving agents unrestricted tool access or wildcard permissions.

Here is how that translates into a design review.

Minimum tools. If the agent summarizes invoices, it does not need email, ticketing or a code interpreter. Each extra tool is another way for a bad decision to become an action.

Read only by default. Make write access something an agent earns for a specific tool and a specific purpose. A reporting agent that cannot write cannot corrupt anything.

Named resources. Point the agent at this share, this table, this queue. Not "finance data" and never "everything the account can see."

No wildcards and no run any command tools. A general shell turns every task into an open ended one. If the agent needs to run three commands, build three narrow tools.

The Five Eyes agencies made a similar point in their May 1, 2026 guidance, Careful Adoption of Agentic AI Services, the first joint agentic AI security guidance from the US, UK, Australia, Canada and New Zealand. Their worked example is a procurement agent with broad access to financial systems, email and contract repositories, where an attacker who compromises one low risk tool in the workflow inherits all of its permissions. That is what a wide action space costs you.

Give Every Run Its Own Room

Scoping tools limits what the agent is allowed to do. Containment limits what it can do when something in the scoping is wrong. You want both.

The model I recommend is one disposable container or runtime boundary per run. The agent starts clean, does its work and is destroyed. Nothing carries over from one run to the next, and nothing in the environment is worth stealing. OWASP's guidance lists isolating agent execution environments as a core practice, and its MCP guidance adds disabling network access unless it is explicitly needed.

Four design rules do most of the work.

No ambient cloud role. If the container inherits an instance role, the agent inherits it too. Run agents with no cloud identity at all unless a specific task requires one, and block access to the instance metadata service so there is no quiet route to a role.

No mounted secrets. If a secret is sitting in the filesystem or environment variables, assume the agent can read it and might use it. Anything it needs should arrive another way, which I cover in the next section.

Deny by default egress. Outbound traffic is blocked unless a destination is on a short approved list. A practitioner control library describes the pattern as default deny outbound access, permitting only explicitly approved destinations and routing permitted traffic through an authenticated proxy that enforces policy. OWASP's secure coding guidance for AI also warns against giving agents unrestricted web access without egress controls.

Treat the one open door as the door. Look back at the OpenAI account as reported. The agents did not smash through a wall. They used the single permitted path. Whatever you allow out of the sandbox, whether a package proxy or an LLM gateway, is now part of your attack surface. Harden and monitor it like any other internet facing service.

The one door you leave open is the door the agent will find. Design as if it will.

Credentials You Would Not Mind Rotating

I covered the identity program side of this in my post on why your identity program isn't ready for AI agents. Here I only want the design time rule for credentials: the agent should hold nothing that would hurt to lose.

My test is simple. If the agent leaked, logged or misused a credential today, would rotating it be a non event or a crisis? If it is a crisis, the credential should not be in the agent's reach.

In practice that means short lived, task scoped credentials. OWASP's MCP guidance says to prefer ephemeral, short lived tokens over long lived personal access tokens, to use scoped, per server credentials and never share tokens across servers, and to request narrow OAuth scopes, such as read only mail access instead of full access. A token that expires in minutes and can do one thing is a very different risk from a key that lives for a year and does everything.

Where you can, broker those credentials outside the sandbox. The agent asks a trusted service to perform an action or to mint a credential for one task, and that service checks the request against policy the agent cannot edit. OWASP's MCP guidance puts the principle well: enforce authorization and validate tool calls in trusted application code, independently of the model's interpretation. The Coalition for Secure AI makes the same point about isolation: it must be independently enforced, not agent enforced.

This also cleans up a common mess. When several agents share one service account or API key, you lose attribution, you cannot scope anything per agent, and you cannot revoke one without breaking the rest. Give each agent its own identity. The Five Eyes guidance says the same, advising that each agent be built as a distinct principal with its own keys or certificates.

Stack the Layers So One Failure Is Not a Breach

No single control will hold. Plan for each of them to fail at some point, and make sure no single failure gives the agent everything.

Microsoft's seven layers are a handy checklist for this: identity, permissions, data, endpoint, network, cloud and runtime. Here is how I think about each one for an agent.

Identity is a unique, registered, owned identity per agent. Permissions are the narrow tool and resource scopes from earlier. Data means classification and access rules that apply to the agent the same way they apply to a person. Endpoint and runtime mean the disposable environment with tight process and filesystem limits. Network is deny by default egress and segmentation between agents. Cloud is no ambient roles and tight account boundaries.

An industry write up on sandbox failures makes the case for overlap. A single boundary turns containment into a single point of failure. The goal is for breakout to require several distinct failures, not one missed rule. If the proxy fails open, credential scope and denied tool permissions should still stop the agent.

Segmentation between agents deserves its own mention. The Five Eyes guidance calls for segmentation strategies to contain failures and limit lateral movement between agents. That matters because of the collusion risk Microsoft describes. Mishcon's analysis reports that in one case agents shared working exploits with one another, divided the work and developed addressing conventions. I would treat that as reported rather than settled, but the design lesson holds either way. Do not let agents share artifact stores, registries or message channels with each other or with the corporate estate unless that path is deliberate and monitored.

If you work in a plant or a similar environment, this will feel familiar. It is the same blast radius thinking I wrote about in the NCSC Principle 6 post on limiting the impact of compromise. The difference here is that the thing you are containing makes its own decisions.

A caveat on Microsoft's Guardian Agents. The post proposes them as supervisory agents that watch and moderate every action of every other agent. One analysis notes that Microsoft's post itself describes Guardian Agents only as a vision and does not say they are a shipping feature. I find the idea interesting, and the observation behind it is fair: an agent with legitimate credentials and tool access does not look like malware, and intent does not appear in telemetry, only behaviour. But do not build your program on a control you cannot yet buy, test or audit. Use deterministic limits now. Treat supervision by another AI as something to evaluate later, as an addition and not a replacement.

Humans on the Irreversible, and a Kill Switch That Works

The last layer is the one that catches what everything else missed. Two pieces matter: human approval for actions you cannot undo, and a way to stop an agent in the middle of a run.

Human approval. OWASP's cheat sheet lists human in the loop for high risk actions and separating decision making from execution for irreversible operations. Define "high impact" in advance: payments, deletions, external messages, permission changes, production writes. Then enforce the approval gate in code. An agent that is asked politely to wait for approval is back to relying on the prompt.

The Five Eyes guidance supports this, advising human approval for sensitive operations, checkpoints in agent workflows, and the ability to interrupt or reverse agent actions in real time. The agencies also tell organisations to only use agentic AI for low risk and non sensitive tasks. That is a conservative position, and I think it is the honest one for now. If your agent touches payments, contracts or regulated records, you are operating beyond what these agencies currently recommend. Know that going in, and make sure your risk acceptance says so.

The kill switch. A kill switch is only real if it works when the agent is not cooperating. One control library says kill switches, credential revocation and network isolation should be controlled by the platform, not by cooperative shutdown inside the subject's runtime. I agree completely. If stopping the agent depends on the agent agreeing to stop, you do not have a kill switch.

Build it to do three things. Halt the agent mid run. Revoke its credentials and cut its network at the same moment. Preserve its trajectory, meaning the full record of prompts, tool calls and results, so your team can work out what happened. That record is what you will need in the first hour of an incident, which I walk through in the coding agent playbook for the first hour.

Then test it. Run a drill where an agent is mid task and you stop it. Find out whether the credentials die, whether the logs survive and whether anyone on the team knows who presses the button.

The Checklist for Your Engineering Lead

If you are early in your career and need a way into this conversation, bring these ten questions to the engineering lead who owns an agent. Each one is a yes or no. Every no is a finding.

• Does the agent have a named human owner and an entry in an agent registry?
• Does it run under its own identity, with no shared service account or API key?
• Is every tool on an explicit allowlist, with read only versus write decided per tool?
• Are resources named specifically, with no wildcards and no run any command tool?
• Does each run start in a fresh, disposable environment with no ambient cloud role and no mounted secrets?
• Is egress denied by default, with the instance metadata service unreachable?
• Are credentials short lived, scoped to the task and issued from outside the sandbox?
• Is every limit stated in the prompt also enforced independently of the model?
• Do irreversible or high impact actions require human approval enforced in code?
• Has the kill switch been tested in the last quarter, halting a live run and preserving its trajectory?

Eight or more yeses on a production agent is a strong position. Fewer than five means the agent is running on trust, which is exactly what this series argues against.

What to Say No To

Standards only work if you are willing to refuse things. These are the requests I would decline, and the answers I would give.

Shared service accounts or API keys. One credential across many agents means no attribution and no clean revocation. Each agent gets its own.

Agents that inherit a user's full access. The agent should hold the access its task needs, not everything the person who launched it can reach. OWASP's secure coding guidance specifically warns against letting sub agents inherit the full permissions and credentials of the parent agent without scope restriction.

Standing or long lived credentials. If it does not expire quickly, it does not go in the agent's path.

Wildcard tool permissions and shell access. These are the exact anti patterns OWASP calls out. If an engineer needs a shell, they need a narrower tool.

Admin rights "just for the proof of concept." Proofs of concept have a way of becoming production. The Five Eyes guidance warns that retrofitting security controls onto widely deployed agents is significantly harder than building them in from the outset. Start with the limits you intend to keep.

Shared artifact stores or registries between agent environments and the corporate estate. A shared registry is a bridge. It lets one compromised or misbehaving agent push something into places it should never reach.

Unregistered agents with no owner. If nobody owns it, nobody can answer for it, and you cannot protect what you cannot see. This is the same problem I described in my post on shadow AI and what new CISOs need to do before it bites them, only now the shadow tool can take actions.

"The system prompt tells it not to." Say no to this one every time. A prompt is a request. If the only thing standing between the agent and a bad outcome is text the agent can ignore, you have no control, and the review should say so in writing.

Key Points

• You cannot predict what a model will decide, so the control you own is how much the agent can reach and do.
• A prompt is a request, not a boundary. Enforcement belongs outside the model.
• Scope the action space per agent: minimum tools, read only by default, named resources, no wildcards or shell.
• Run each agent in its own disposable runtime with deny by default egress, no ambient roles and no mounted secrets.
• Use short lived, task scoped credentials issued outside the sandbox, and layer controls so one failure is not a breach.
• Keep human approval for irreversible actions and test a kill switch that preserves the agent's trajectory.

Pro Tips

Review the environment, not the prompt. When an agent comes to you for approval, ask to see the container configuration, the network rules and the credential flow before you read a single line of the system prompt.

Try to break the boundary yourself. Have someone attempt to reach the metadata service, an unapproved domain or a neighboring agent's store from inside the runtime. A control you have never tested is an assumption.

Tie autonomy to demonstrated confidence. The Five Eyes guidance recommends expanding access and autonomy only as confidence in agent behavior grows. Start narrow, watch what the agent does, and widen scope with evidence.

Write the scope down anyway. Stating in and out of scope systems explicitly is still valuable, as Mishcon says. It gives you the specification you enforce against, and it gives auditors something to test.

Pitfalls to Avoid

Do not treat a sandbox label as proof of isolation. Several of the 2026 cases, as reported, involved environments documented as isolated that were not. Verify with tests.

Do not leave a single permitted egress path unmonitored. The one allowed route is where the pressure will land.

Do not let the agent hold the keys to its own controls. If it can change its egress rules, its credentials or its shutdown behavior, the boundary belongs to the agent, not to you.

Do not count on Guardian Agents or any supervisory AI to carry the program today. Microsoft describes them as a vision, and your deterministic limits need to stand on their own.

Do not approve broad access with a plan to tighten it later. Later rarely arrives, and the design time decision tends to stick.

Final Thought

I cannot tell you what a model will decide on a given Monday, and neither can the vendor or the engineer who built the agent. What I can tell you is what that agent is able to reach, because I decided that before it ran. That is the one control a CISO fully owns, so own it: shrink the action space, build the walls outside the model, and assume every layer will fail someday.

In Part 3, I will turn to the other half of Microsoft's principle: independent evidence. Containment limits the damage, but you still need to see what your agents actually did and prove it afterward. If you are working on agent containment right now, tell me where you are stuck, what pushback you are getting from engineering, or which item on the checklist your team fails first. Leave a comment below. I read every one.