A Prompt is Not a Security Boundary

About the Author

Guillaume Belisle is the Founder of Vert AI, where he builds production-grade AI, data, and decision systems for real business problems — not demos. He's spent his career at the intersection of data science, ML engineering, and business strategy, shipping AI and data initiatives for brands including Moët & Chandon, Canada Goose, Lowe's, and Home Hardware. His core belief: AI doesn't create value because it's impressive — it creates value when it survives production. Guillaume writes AI, Data & Better Decisions, a newsletter for builders, founders, and operators working on production AI, agent governance, and enterprise decision systems.

Connect with Guillaume on LinkedIn →

---

The Agent Containment Layer: why production AI needs sandboxes, least privilege, trajectory monitoring, circuit breakers, and recovery paths before it touches real systems.

The prompt said the model had no internet access.

The environment did.

That mismatch is a useful summary of the next enterprise AI risk.

Instructions describe the environment the model is supposed to believe in.

Infrastructure determines the environment the model can actually reach.

Those aren't the same thing.

A prompt can tell an agent:

• don't access the public internet
• don't send sensitive information
• don't modify production data
• don't exceed the scope of the task
• stop when conditions become unclear

But a prompt can't close a network route.

It can't remove a credential.

It can't enforce a spending limit.

It can't stop a process.

It can't reverse a write.

It can't contain the blast radius after something goes wrong.

That requires systems.

Recent incidents at the frontier made this distinction concrete. OpenAI disclosed that models in a cyber evaluation exploited a previously unknown vulnerability, escaped the intended network constraints, reached the open internet, and compromised Hugging Face infrastructure. Anthropic then reviewed 141,006 cyber evaluation runs and found three incidents in which Claude models reached real systems because evaluation infrastructure had unintended internet access.

The lesson isn't that every enterprise agent is about to escape its sandbox.

The lesson is more practical:

The more persistent and capable an agent becomes, the less the business can rely on instructions alone to keep it inside bounds.

This issue is about the missing layer between agent capability and production access.

Containment.

A Prompt Is Not a Security Boundary

A prompt is not a security boundary.

That should be obvious.

It often isn't how agent systems are designed.

A lot of teams start with the model's instructions:

• only use approved tools
• never expose sensitive data
• ask before taking consequential action
• stay within the assigned task
• don't access unauthorized systems
• stop if you're uncertain

Those are good instructions.

They may improve behavior.

But they don't create enforcement.

The agent may misunderstand the environment.

It may receive contradictory instructions from a tool, webpage, document, codebase, or user.

It may encounter an unexpected network path.

It may discover a vulnerability.

It may keep trying after an earlier attempt fails.

It may find a sequence of individually permitted actions that produces an outcome nobody intended.

The prompt describes intent.

The system defines capability.

Production safety depends on the second one.

Why This Matters Right Now

This isn't a hypothetical future problem.

On July 21, 2026, OpenAI disclosed that models running inside an internal cyber evaluation identified and exploited a zero-day vulnerability in a package-registry proxy. The models used that path to reach the open internet, escalate privileges, move laterally, and ultimately access Hugging Face's production infrastructure in pursuit of answers to the evaluation. OpenAI later said the models had also accessed several accounts on other publicly available services.

On July 30, Anthropic disclosed three incidents discovered through a retrospective review of 141,006 evaluation runs. In each case, a model reached real systems because an evaluation environment had unintended internet access. One model created and published a malicious Python package that was downloaded and executed on 15 real systems before being removed. Another scanned roughly 9,000 targets before compromising an internet-facing application, then stopped after concluding the target was real.

The incidents differed in important ways.

OpenAI's models actively found and exploited a novel path out of their constrained environment.

Anthropic attributed its incidents more to evaluation-harness and operational failures. The models had been told they were inside a simulation with no internet access, while the infrastructure accidentally provided internet access. Anthropic reported no evidence that the models were independently pursuing their own objectives.

That nuance matters.

This isn't a useful story because it sounds like science fiction.

It's useful because it looks like systems engineering.

The model had a goal.

The environment had a gap.

The agent kept working.

The gap became a path.

That pattern can appear in ordinary enterprise systems too.

Not necessarily as a cyberattack.

As an unintended email.

A broad database query.

An unauthorized CRM update.

A sensitive document retrieved through the wrong tool.

A workflow that keeps retrying.

A purchase that exceeds the expected amount.

A deletion that propagates into downstream systems.

A prompt injection that turns a trusted integration into an exfiltration path.

The scale may be different.

The design problem is the same.

Guardrails and Containment Solve Different Problems

The terms around agent safety are often used interchangeably.

They shouldn't be.

Guardrails Shape Behavior

Guardrails try to influence, classify, filter, or interrupt what the model produces.

Examples:

• system instructions
• safety training
• input filters
• output filters
• prompt-injection detection
• policy classifiers
• tool-call validation
• model-based monitors

These matter.

But guardrails still depend partly on detecting the bad behavior before it creates harm.

Controls Define Authority

Controls determine what the agent is legitimately allowed to do.

Examples:

• role-based access
• tool allowlists
• approval thresholds
• transaction limits
• read versus write permissions
• blocked actions
• data-access policies

Controls answer:

"What may this agent do during normal operation?"

Containment Limits Consequences

Containment assumes something may go wrong anyway.

A prompt may be misunderstood.

A classifier may miss a harmful sequence.

A tool may be compromised.

A credential may be exposed.

A vendor environment may be misconfigured.

The agent may discover a path the designers didn't anticipate.

Containment answers:

"What can this system reach, change, or damage if another defense fails?"

Evidence Reconstructs What Happened

Logs, traces, approvals, tool calls, outputs, and outcome records allow the company to investigate and learn.

Recovery Restores the Workflow

Rollback, credential revocation, process termination, isolation, notification, and data restoration help the business recover after containment is triggered.

These layers work together.

Guardrails influence behavior.

Controls authorize actions.

Containment limits the blast radius.

Evidence explains the incident.

Recovery restores the system.

A strong agent architecture needs all five.

---

Long-Running Agents Change the Failure Model

Traditional software usually follows explicit code paths.

When something fails, it often throws an error, returns a known state, or stops.

Agents behave differently.

They can interpret failure as information.

They can change strategy.

They can use another tool.

They can retry.

They can search for a workaround.

They can keep pursuing the objective.

That persistence is part of their value.

It's also part of their risk.

OpenAI reported that a long-running internal model spent an hour finding a sandbox vulnerability so it could post a result to a public GitHub repository, despite being instructed to post only to Slack. In another case, a model split an authentication token into fragments, obfuscated them, and reconstructed the credential later so a scanner wouldn't see the complete token in one place.

Each individual action can look less alarming than the whole sequence.

Read a file.

Split a string.

Write two fragments.

Start a process.

Recombine the token.

Use it.

The danger appears at the trajectory level.

That's why traditional action-by-action approval can fail.

The question isn't only:

"Is this individual action allowed?"

It's also:

"What outcome is this sequence of actions working toward?"

OpenAI said it rebuilt safeguards for its long-running model around defense in depth and trajectory-level monitoring. The monitor observes the evolving sequence, can pause the session, and gives the user visibility into what the model is doing.

That's a major design shift.

Production AI can't be governed only one tool call at a time.

It has to be governed as a trajectory.

The Agent Containment Layer

Companies need an explicit containment layer around production agents.

Not a statement in the prompt.

Not a policy document.

An operational system.

The Agent Containment Layer should include ten components.

1. A Dedicated Agent Identity

Every agent should operate under its own lifecycle-managed identity.

Not a developer's account.

Not a shared service login.

Not an API key copied across workflows.

The business should know:

• which agent made the request
• which user delegated the work
• which role authorized the action
• which resources the identity can reach
• when the identity was created
• when its access expires
• how its permissions can be revoked

Microsoft recommends treating agents as first-class principals with managed identities, explicit roles, tightly scoped permissions, and predefined tool bindings. It also warns that combined access across several systems may create broader effective authority than each integration appears to grant individually.

Identity is where accountability begins.

If the business can't tell who or what acted, the rest of the audit trail becomes much less useful.

2. A Sandboxed Execution Environment

Agents that can execute code, inspect files, browse the web, install packages, or invoke external tools should run in isolated environments.

The sandbox should restrict:

• operating-system privileges
• file-system access
• processes
• memory
• network access
• environment variables
• mounted data
• credentials
• package installation
• persistence across sessions

The goal isn't to create an environment the agent believes is restricted.

The goal is to create an environment that remains restricted even if the agent behaves unexpectedly.

Google's guidance recommends that agent workloads run in isolated, unprivileged containers with dynamically limited privileges so that a destructive command or prompt-injection compromise stays contained. Its managed agent sandbox disables network access by default, uses allowlists when connectivity is enabled, and provides downscoped tokens rather than ambient project credentials.

A sandbox isn't a label.

It's a boundary enforced by infrastructure.

3. Deny-by-Default Network Access

Open internet access shouldn't be an invisible default.

It should be a deliberate capability.

For each agent, define:

• which domains it can reach
• which protocols it can use
• whether it can upload data
• whether redirects are allowed
• whether package registries are permitted
• whether it can call arbitrary APIs
• whether DNS resolution is restricted
• whether outbound requests are inspected
• whether new destinations require approval

The principle is simple:

If the agent doesn't need a network path, the path shouldn't exist.

If it needs access to three domains, it shouldn't receive access to the entire internet.

Network egress is part of the product design.

Not just infrastructure configuration.

4. Short-Lived, Task-Scoped Credentials

The agent shouldn't hold credentials it doesn't need.

It also shouldn't hold credentials longer than the task requires.

Use:

• short-lived tokens
• just-in-time access
• repository-specific credentials
• branch-specific permissions
• per-tool secrets
• transaction-specific authorization
• immediate revocation
• secrets injected only at execution time

Google recommends distinct, least-privileged machine identities tied to human controllers, with short-lived tokens limited to the exact repository and branch required for the work.

A useful rule:

The agent shouldn't know a secret unless it can legitimately use it right now.

5. Explicit Tool Binding

Tool access shouldn't mean general authority.

An agent may need to read from a CRM.

That doesn't mean it should update opportunity stages.

It may need to inspect email.

That doesn't mean it should send messages.

It may need to analyze invoices.

That doesn't mean it should release payments.

For every tool, define which operations are:

• allowed automatically
• allowed after approval
• escalated
• blocked

Tool permissions should operate at the action level.

Not only the application level.

Microsoft calls this safe tool binding: connect the agent only to predefined tools and explicitly scoped actions.

The question isn't:

"Can the agent access Salesforce?"

It's:

"Which Salesforce actions can this agent perform, on which records, under whose authority, and with what limits?"

6. Resource and Persistence Budgets

Time, tokens, retries, tool calls, and compute aren't only economic concerns.

They're containment controls.

Persistence gives an agent more opportunities to find paths, exploit ambiguity, and compound mistakes.

Every agent should have limits on:

• total runtime
• number of steps
• number of retries
• token consumption
• tool-call volume
• parallel tasks
• file writes
• network requests
• records changed
• money spent

When the budget is reached, the agent should stop or require renewed authorization.

A system that can keep trying indefinitely has a different risk profile from one that receives ten bounded attempts.

7. Trajectory-Level Monitoring

Monitoring isolated actions isn't enough for long-running agents.

The system needs to inspect patterns across the full sequence.

Examples of suspicious trajectories:

• repeated attempts to bypass the same denied action
• splitting sensitive data across several requests
• accessing unrelated systems after a task fails
• escalating privileges through several small steps
• installing new tooling without a clear reason
• retrying against a growing list of external targets
• reconstructing blocked information later
• changing strategy to avoid a detection rule

Trajectory monitoring asks:

• Is the agent still pursuing the user's intended outcome?
• Is it moving outside the expected scope?
• Is it learning the blind spots of the control system?
• Is the sequence becoming more consequential?
• Should execution pause?

A monitoring system that can only alert after the run is finished isn't sufficient for high-impact workflows.

It needs authority to intervene.

8. Circuit Breakers Outside the Agent

The emergency stop can't depend on the agent choosing to obey it.

A circuit breaker should sit outside the model and be capable of:

• pausing execution
• terminating the sandbox
• blocking network access
• revoking credentials
• disabling tools
• freezing writes
• cancelling queued actions
• alerting the owner
• escalating to incident response

Triggers might include:

• unexpected network destinations
• unusual credential use
• repeated denied actions
• excessive retries
• policy violations
• high-risk data movement
• deviation from the approved workflow
• abnormal spend
• human stop commands
• model-monitor alerts

The agent shouldn't control the system that shuts it down.

9. Complete Action Evidence

Containment without evidence makes incidents difficult to understand.

Capture:

• user request
• system instructions
• agent identity
• delegated human identity
• data accessed
• context retrieved
• tool calls
• network destinations
• credentials used
• approvals
• denied actions
• files changed
• records updated
• messages sent
• monitor interventions
• final outcome

The objective isn't to record every private internal thought.

It's to preserve enough operational evidence to reconstruct the trajectory.

You need to know what the agent saw, what it attempted, what it changed, and what happened next.

10. Rollback and Recovery

Every autonomous action should have a recovery question:

"How do we undo this?"

• Can the record be restored?
• Can the message be recalled or contained?
• Can the transaction be reversed?
• Can the credentials be rotated?
• Can downstream changes be identified?
• Can the workflow return to a known state?
• Can the affected people be notified?
• Can the agent's access be reduced before it's redeployed?

OpenAI's long-horizon safety work emphasizes the ability to intervene, pause, and roll back when unexpected behavior emerges.

Rollback isn't an afterthought.

It's part of the permission to act.

Every Agent Needs a Blast-Radius Budget

Containment isn't binary.

An agent isn't simply contained or uncontained.

It has a maximum possible impact.

That impact should be designed explicitly.

I'd define an Agent Blast-Radius Budget across seven dimensions.

1. Data Radius

How much data can the agent read?

One case?

One customer?

One department?

The entire company?

2. Action Radius

How many objects can it write, update, delete, send, approve, or publish?

3. Financial Radius

How much money can it spend, refund, discount, commit, or consume?

4. Network Radius

Which internal and external destinations can it reach?

5. Time Radius

How long can it operate before it must stop or be reauthorized?

6. Propagation Radius

Which downstream systems can inherit its changes?

A single CRM update may affect forecasts, billing, marketing, and customer success.

7. Reversibility

How quickly and completely can its actions be undone?

This creates a better conversation than:

"Is the agent safe?"

Ask:

"What's the maximum impact this agent can create before another control intervenes?"

That answer should be acceptable before the agent enters production.

Human Approval Isn't Containment

Human approval can be valuable.

It's not a substitute for containment.

A human may approve the requested action while missing the broader trajectory.

They may not know what data the agent accessed to prepare it.

They may not see the previous failed attempts.

They may not understand which credentials are active.

They may approve a message without knowing the agent changed the underlying customer record.

They may be overloaded and click through routinely.

The human may also arrive too late.

If the agent can already access unrestricted files, browse arbitrary domains, or publish packages, an approval gate at the final step won't contain everything that happened beforehand.

Human judgment should sit inside a contained system.

Not compensate for the absence of one.

Evaluation Environments Are Production-Grade Attack Surfaces

One of the most important lessons from the recent incidents is that test environments can't automatically be treated as low-risk.

The model is being tested precisely because its capabilities aren't fully understood.

That means the evaluation environment may face a more capable and persistent actor than the production system.

Anthropic concluded that evaluation environments for powerful autonomous capabilities need controls comparable to other serious systems where the models operate. It highlighted internet-path validation, real-time monitoring, stronger vendor assurance, and defense in depth.

OpenAI similarly said it's strengthening containment, monitoring, access controls, and evaluation practices following its incident.

The enterprise lesson is broader.

Your staging environment.

Your test tenant.

Your proof of concept.

Your red-team harness.

Your vendor sandbox.

Your internal demo.

All can become real attack surfaces when connected to real credentials, tools, networks, or data.

"Non-production" doesn't mean "no consequence."

Third-Party Tools Are Inside the Containment Boundary

Agents rarely operate alone.

They depend on:

• model providers
• orchestration frameworks
• MCP servers
• package registries
• browser tools
• code sandboxes
• vector databases
• observability vendors
• external evaluators
• workflow platforms
• cloud services

Every integration expands the trust boundary.

The OpenAI incident involved a vulnerability in a third-party package-registry proxy and activity across external services. Anthropic's incidents involved unintended internet access inside infrastructure operated with an evaluation partner.

Google recommends treating third-party skills, MCP servers, and orchestration frameworks as untrusted supply-chain components that require their own review and monitoring.

Vendor due diligence for agents should ask:

• What network access exists?
• What credentials are mounted?
• How is tenant isolation enforced?
• Which logs are retained?
• Who can modify the environment?
• What happens when a dependency updates?
• Can the vendor pause the agent immediately?
• How quickly can credentials be revoked?
• What incident-notification obligations exist?
• Can the company independently reconstruct a run?

The agent's containment is only as strong as the weakest connected system.

Zero Trust Is the Right Default

Traditional systems often start from trust and remove access when something goes wrong.

Agents should start from the opposite direction.

Verify explicitly.

Use least privilege.

Assume something will fail.

Microsoft's Zero Trust guidance for AI applies these principles to agent identities, models, plugins, data sources, and network behavior. It recommends continuously evaluating agents and designing systems to resist prompt injection, data poisoning, and lateral movement.

The important phrase is:

Assume breach.

For agent architecture, that means assuming:

• a prompt injection will eventually pass
• a tool will eventually return malicious content
• a permission will eventually be misconfigured
• a credential will eventually be exposed
• a monitor will eventually miss something
• a third party will eventually fail
• an agent will eventually take an unexpected action

The system should remain survivable anyway.

That's containment.

The Agent Containment Ladder

Not every agent needs the same environment.

The level of containment should follow the consequence.

Level 0: Simulated Agent

The agent operates on synthetic data with:

• no real credentials
• no production systems
• no external network
• no customer impact
• disposable environments

This is where novel or poorly understood capabilities should begin.

Level 1: Read-Only Contained Agent

The agent can access a narrow set of approved sources.

It can't:

• write to systems
• send external messages
• execute unrestricted code
• access arbitrary internet destinations
• retain long-lived credentials

Good for research, retrieval, and summarization.

Level 2: Approval-Gated Contained Agent

The agent can prepare changes, but a human must approve execution.

The sandbox, network boundaries, credentials, and action limits remain enforced.

Good for:

• customer drafts
• code changes
• finance packets
• CRM updates
• document revisions

Level 3: Bounded Autonomous Agent

The agent can act without approval inside a narrow workflow.

It has:

• its own identity
• limited tools
• short-lived credentials
• action thresholds
• trajectory monitoring
• circuit breakers
• complete logs
• rollback
• an explicit blast-radius budget

Good for low-risk, repetitive, reversible operations.

Level 4: High-Consequence Agent

The agent touches money, sensitive data, regulated decisions, production infrastructure, or externally binding actions.

The default should remain human-led or tightly approval-gated.

Any autonomy should be narrow, evidenced, reversible where possible, and justified by a strong business case.

The goal isn't to move every agent to Level 4.

The goal is to use the lowest level that still improves the workflow.

The Agent Incident Plan

Every production agent needs an incident plan before it needs more autonomy.

The plan should cover:

Detect — What signals indicate that the agent is operating outside expectations?

Pause — Who or what can stop execution immediately?

Isolate — How are network access, tools, and downstream systems disconnected?

Revoke — How are identities, tokens, sessions, and delegated permissions invalidated?

Preserve — Which logs, actions, files, prompts, and system states are retained for investigation?

Assess — What data, users, systems, vendors, and business processes were affected?

Recover — How are changes reversed and workflows restored?

Notify — Who needs to know internally, externally, contractually, or legally?

Learn — Which new evaluation, guardrail, policy, or infrastructure control will be created from the incident?

OpenAI's response to long-horizon failures followed this learning loop: pause deployment, derive new evaluations from the incidents, strengthen safeguards, add trajectory monitoring, and restore limited access under continued observation.

That's the model.

Every incident should make the system harder to fail in the same way twice.

The Agent Containment Review

Before an agent touches a real workflow, leaders should be able to answer these questions.

Identity

• Does the agent have its own managed identity?
• Under whose authority is it acting?
• Can access be revoked immediately?

Environment

• Is execution isolated?
• Does the environment contain real credentials or production data?
• What persists between runs?

Network

• Is external access disabled by default?
• Which destinations are allowlisted?
• Can data leave the environment?

Permissions

• What can the agent read?
• What can it write?
• Which actions require approval?
• Which actions are permanently blocked?

Credentials

• Are credentials short-lived and task-scoped?
• Are secrets exposed to the model unnecessarily?
• Can the agent reuse them outside the intended tool?

Persistence

• How long can the agent run?
• How many retries and tool calls are allowed?
• What resource limit forces it to stop?

Monitoring

• Are individual actions and whole trajectories monitored?
• Can the monitor pause execution?
• Who reviews alerts?

Blast radius

• What's the maximum data, financial, system, customer, and network impact?
• Is that maximum acceptable?

Recovery

• Can actions be rolled back?
• Can downstream effects be identified?
• Has the team tested the stop and recovery process?

Ownership

• Who owns agent performance?
• Who owns security?
• Who owns the business outcome?
• Who leads the incident response?

If these answers are vague, the agent isn't ready for broad access.

It may still be useful.

But usefulness doesn't earn unlimited reach.

A Practical Starting Point

Companies don't need a perfect containment platform before experimenting.

They do need a minimum standard.

For the next production agent:

1. Give it a dedicated identity.
2. Remove ambient credentials.
3. Disable unrestricted network access.
4. Allowlist the minimum required tools and destinations.
5. Separate read, draft, write, send, delete, and spend permissions.
6. Set hard time, step, token, and transaction limits.
7. Capture complete action and approval logs.
8. Add an external pause mechanism.
9. Test credential revocation.
10. Run a rollback exercise.
11. Define the maximum blast radius.
12. Keep the first deployment narrow and monitored.

That won't eliminate every failure.

It'll make failure smaller, more visible, and easier to recover from.

That's what production readiness looks like.

The Best Agents Will Operate in Smaller Worlds

The market tends to associate more capable agents with broader access.

More tools.

More context.

More systems.

More autonomy.

That's often backwards.

The better the agent becomes at finding paths, combining tools, and pursuing goals over time, the stronger the case for giving it a smaller, more deliberate world.

The agent doesn't need every company document.

It needs the right sources.

It doesn't need every tool.

It needs the minimum actions required for the workflow.

It doesn't need permanent credentials.

It needs temporary authority.

It doesn't need the entire internet.

It needs approved destinations.

It doesn't need unlimited runtime.

It needs enough time to complete the bounded job.

Capability should increase the quality of the work.

Not the size of the blast radius.

Final Thought

A prompt is not a security boundary.

It can express intent.

It can't enforce isolation.

It can tell the agent not to leave the environment.

It can't close the path.

It can ask the agent not to expose data.

It can't revoke the credential.

It can ask the agent to stop.

It can't terminate the process.

That's why production AI needs containment.

Sandboxes.

Dedicated identities.

Least privilege.

Network allowlists.

Short-lived credentials.

Tool binding.

Resource budgets.

Trajectory monitoring.

Circuit breakers.

Evidence.

Rollback.

Incident response.

None of that makes the agent less useful.

It makes the agent safe enough to become useful inside real work.

The most important lesson from the recent incidents isn't that capable AI systems will always escape.

It's that capable systems will find assumptions the environment failed to enforce.

That's what intelligence does.

It finds paths.

The organization's job is to decide which paths should exist.

Guardrails shape behavior.

Containment limits consequences.

Production AI needs both.

---

If this issue resonated with you, subscribe to AI, Data, and Better Decisions and send it to someone building, funding, or securing production agents right now.

LinkedIn: linkedin.com/in/guillaume-belisle