Back to the CIO and CSO starting point Security and GRC hub
AI agent security: sandboxes, permissions and tool access
AI agent security is the set of controls that limit what a model can do once it can run commands, call tools, and reach networks. Lightbridge frames it as four layers: least-privilege permissions, approval gates, a sandbox with egress limits, and tool authorization. Each layer narrows the damage. None of them stops prompt injection.
This page is for a CIO or CSO deciding how much freedom to give coding agents, browser agents, and tool-calling assistants. It covers what changes when a model can act, the controls that matter, a table that maps each control to its threat, its documented vendor feature, and its stated limit, and a rollout order. Vendor and standards statements are attributed and linked. Sources were checked on 2026-11-03; publication dates are shown where a source gives one, and vendor documentation pages carry none. Lightbridge does not recommend a vendor here. It sits in Lightbridge's security and GRC advisory hub.
What changes when a model can act: Lightbridge's framing of the risk.
A chatbot produces text that a person reads. An agent produces actions that a system runs. OWASP LLM06:2025 defines Excessive Agency as the vulnerability that enables damaging actions in response to unexpected, ambiguous or manipulated model outputs. It lists three root causes: excessive functionality, excessive permissions, and excessive autonomy.
The LLM06 page separates this from improper output handling. LLM05:2025 concerns insufficient validation of model outputs before they pass downstream, and recommends treating the model like any other user, with zero trust. Lightbridge's framing: agency is the other half, meaning what the model is allowed to do once its output is trusted enough to run.
OWASP also published a Top 10 for Agentic Applications for 2026 on 9 December 2025 (OWASP). The landing page offers the full list as a PDF only, so we do not cite its item numbers here.
The UK NCSC puts the readiness test plainly: if you cannot understand, monitor or contain an agent's actions, it is not ready for deployment (NCSC, 15 May 2026). Lightbridge uses that as the first question in any agent review. Who can contain this agent, and how fast?
Many agents start as unsanctioned experiments. Lightbridge's guide to shadow AI discovery covers finding them. How the agent reaches its model is a separate decision, compared on AI access paths.
Least privilege and approval gates: what Lightbridge advises security teams to set first.
Sources checked 2026-11-03. Dated sources: OWASP LLM06 (page modified 2025-05-05), NCSC (8 December 2025 and 15 May 2026). The joint guidance and vendor pages carry no date.
Enforce permissions outside the model
OWASP recommends enforcing authorization in downstream systems instead of relying on the model to decide whether an action is allowed. It also advises avoiding open-ended extensions, such as run-a-shell-command or fetch-a-URL, in favour of granular ones. The NCSC adds that design protections should focus on deterministic, non-LLM safeguards that constrain system actions, and quotes the rule that privileges drop to those of the party whose information the model processes (NCSC, 8 December 2025).
The joint agentic AI guidance, hosted by the Australian Cyber Security Centre and co-authored with the NCSC and international partners, goes further (ACSC-hosted guidance). It says strict adherence to least privilege is critical and warns that entitlements checked only at startup let an attacker exploit a stale allow decision. It recommends prohibiting agents from modifying their own privileges or initiating unapproved delegation without explicit expiry timers and recorded grant chains. The page shows no publication date. The NCSC blog of 15 May 2026 summarises it and recommends least privilege, scope limits and temporary credentials.
In practice, that means a service identity per agent, short-lived credentials, and a tool list written down. How agents and developers authenticate is covered on Lightbridge's page on AI identity and developer access.
Decide which actions ask first
OWASP LLM06:2025 recommends human approval of high-impact actions, implemented in a downstream system or in the extension itself. The joint guidance says the decision of when approval is required belongs to designers or operators and not to the agent, and gives network egress as one high-cost action that needs approval.
Placement matters. Anthropic states that if an application asks a human to confirm consequential actions with computer use, the check must come before each block runs, because a batch can complete a multistep action within one turn (Anthropic). Lightbridge's suggestion: gate by reversibility. Reads in a sandbox run freely. Writes outside the workspace, credential use, egress to new hosts, and side-effecting calls into other systems ask.
OpenAI states that Codex runs an auto-review agent only on actions that already need approval, such as sandbox escalations, blocked network requests, and side-effecting app or MCP calls. It states that actions inside the sandbox proceed without extra review (OpenAI). So an automated reviewer narrows human load. It does not widen what the sandbox allows.
Sandbox and egress controls: what Lightbridge checks and what the vendors say they cover.
Vendor documentation checked 2026-11-03. These pages carry no explicit date.
Anthropic states that effective sandboxing needs both filesystem and network isolation. Without network isolation, a compromised agent could exfiltrate SSH keys. Without filesystem isolation, a compromised agent could escape the network limits (Claude Code sandboxing). The same page lists the defaults and gaps worth reading before you rely on it:
- Anthropic states the sandbox is off by default, and that it covers shell commands only. File tools, MCP servers and hooks run outside it.
- Anthropic states writes default to the working directory, and reads cover most of the machine, including credential files such as the SSH directory.
- Anthropic states network traffic goes through a proxy with an initially empty allowed-domain list.
- Anthropic states that by default, if the sandbox cannot start, Claude Code runs commands without it. A setting makes it exit instead.
- Anthropic documents an unsandboxed retry for failed commands, and a setting that makes Claude Code ignore it.
On egress, Anthropic states the built-in proxy decides from the client-supplied hostname without inspecting TLS, so domain fronting could reach hosts outside the allowlist, and broad domains such as github.com can create exfiltration paths. It also states that sandboxing reduces risk but is not a complete isolation boundary.
OpenAI describes two layers for Codex: a sandbox mode for what it can do technically, and an approval policy for when it must ask. It states network access is off by default and the local sandbox is typically limited to the workspace. It states the workspace-write sandbox keeps .git, .agents, .codex and .aws read-only under writable roots (OpenAI). Its stated gaps are specific:
- The command network proxy does not filter web search, app or connector calls, MCP server connections, browser or Computer Use activity, cloud tasks, or the client's model requests.
- The DNS and IP check reduces but does not eliminate DNS rebinding risk. OpenAI recommends lower-layer egress controls if hostile DNS is in scope.
- Where policy permits full sandbox escalation and it is approved, execution can bypass the command proxy. OpenAI recommends testing both ordinary and escalated commands.
- With full-access flags inside a devcontainer, a malicious project can exfiltrate anything available there, including Codex credentials.
Anthropic also states that its permission mode that skips prompts should be used only in isolated environments such as containers or VMs, and can be disabled through managed settings (Claude Code permissions). Where the agent runs, on a laptop, in a container, or on a hosted platform, changes which of these limits apply. Lightbridge compares those options on AI hosting options. Cloud agent platform guardrails: Not stated in the documentation we reviewed.
Prompt injection: what Lightbridge says controls do and do not stop.
Sources checked 2026-11-03. Dated sources: OWASP LLM01 (page modified 2025-04-17) and NCSC (8 December 2025). Vendor pages carry no date.
Start with the limit. OWASP LLM01:2025 states it is unclear whether fool-proof prevention of prompt injection exists, and that RAG and fine-tuning do not fully mitigate it. The NCSC states that models do not enforce a boundary between instructions and data, and that the problem may never be totally mitigated the way SQL injection can be. It warns that deny-listing known-bad content is easily evaded and advises caution toward products that claim to stop prompt injection (NCSC).
The vendors say the same about their own safeguards. Anthropic states Claude may follow commands found in content even when they conflict with the user's instructions. It says it trained the model to resist this and added classifiers that scan screenshots, and that precautions remain important even with them. It advises isolating Claude from sensitive data and actions, and states the classifier protection can be turned off on request for use cases without a human in the loop (Anthropic). OpenAI states Codex defaults to cached web search to reduce exposure to live content, and warns that enabling network or live search lets prompt injection fetch and follow untrusted instructions (OpenAI).
What the controls do. OWASP lists least-privilege access, with functions handled in code using the application's own tokens, and human approval for high-risk actions among its mitigations. Its Scenario #2 shows the exfiltration path to design against: a webpage with hidden instructions makes the model insert an image that links to an attacker's URL and carries the private conversation. Egress limits and output handling sit directly on that path.
What the controls do not. None of the sources we reviewed offers a control that stops an injected instruction from being followed. They limit what a followed instruction can touch. Lightbridge's advice: plan as if one injection will land, and ask what the agent could reach in that moment. Lightbridge does not offer a test suite for this and this page does not include one. Independent testing of a specific agent is work for a qualified security testing partner.
MCP and tool authorization: what Lightbridge reads in the specification.
Sources checked 2026-11-03. The tools specification is version 2025-11-25. The security best practices page is a draft with no date.
The Model Context Protocol specification (version 2025-11-25) says there should always be a human in the loop able to deny tool invocations, and that clients should show tool inputs before calling the server to avoid exfiltration. It says servers must validate tool inputs, implement access controls, rate limit tool invocations, and sanitize tool outputs. Those are requirements on the server. A client or agent host decides whether to show inputs, so the approval screen is where your policy lives.
The draft security best practices add three points. Servers must not accept tokens not explicitly issued for the MCP server, and token passthrough is explicitly forbidden. A client that supports one-click local server configuration must show the exact command, flag it as potentially dangerous, and require explicit approval. And they recommend a progressive least-privilege scope model: a minimal initial scope, with incremental elevation through scope challenges.
Two scope limits matter for planning. Anthropic states MCP servers run outside the Claude Code sandbox. OpenAI states its command network proxy does not filter MCP server connections. So an MCP server is a path out of the sandbox by design, and each one needs its own review: who runs it, which tools it exposes, what credentials it holds, and what it can write. The specification's authorization section was not part of our review: Not stated in the documentation we reviewed.
The control map Lightbridge uses: control, threat, documented feature, stated limit.
Each row pairs a control with the threat it addresses, a feature the vendor documents, and the limit the vendor or standards body states. Vendor features are listed as examples of documented capability, not as recommendations. Threat cells that carry no citation are Lightbridge's own mapping. Vendor documentation was checked on 2026-11-03 and carries no publication date.
| Control | Threat addressed | Documented vendor feature | Stated limit |
|---|---|---|---|
| Least-privilege permissions | Excessive permissions and functionality (OWASP LLM06). | Anthropic states Claude Code permission rules are evaluated deny, then ask, then allow, first match wins, and a managed-settings deny cannot be overridden by lower levels or command-line flags (source). | Anthropic states Bash patterns that constrain arguments are fragile: a curl URL pattern misses option-order, protocol, redirect and variable variants. |
| Approval gate | Excessive autonomy: high-impact actions taken without a person (OWASP LLM06). | OpenAI states Codex has an approval policy that controls when it must ask before acting (source). The MCP specification says clients should keep a human able to deny tool invocations (source). | Anthropic states computer use confirmation must happen before each block runs, because a batch can finish a multistep action in one turn. OpenAI states auto-review evaluates only actions that already need approval. |
| OS-level sandbox | A followed injected instruction reading or writing beyond the task. | Anthropic documents an OS-enforced sandbox for shell commands (source). OpenAI states Codex locally uses an OS-enforced sandbox typically limited to the workspace (source). | Anthropic states it is off by default, covers shell commands only, fails open if it cannot start unless configured otherwise, and is not a complete isolation boundary. OpenAI states devcontainers do not prevent every attack. |
| Egress allowlist | Data exfiltration to attacker-controlled hosts (OWASP LLM01, Scenario #2). | Anthropic states network goes through a proxy with an initially empty allowed-domain list. OpenAI states Codex network access is off by default. | Anthropic states the proxy does not inspect TLS, so domain fronting could reach hosts outside the list, and broad domains can create exfiltration paths. OpenAI states its proxy does not filter MCP connections, web search, browser activity or model requests, and its DNS check does not eliminate rebinding risk. |
| Protected paths and managed settings | Agent changing its own guardrails or reaching credentials. | OpenAI states the workspace-write sandbox keeps .git, .agents, .codex and .aws read-only under writable roots. Anthropic states the prompt-skipping permission mode can be disabled in managed settings. | Anthropic states sandbox reads cover most of the machine, including credential files. OpenAI states approved full escalation can bypass the command proxy. |
| Injection classifiers and safer defaults | Instructions hidden in pages, images, or retrieved content. | Anthropic states it trained Claude to resist injected commands and added classifiers that scan screenshots. OpenAI states Codex defaults to cached web search. | Anthropic states precautions remain important even with the classifiers. The NCSC states prompt injection may never be totally mitigated and advises caution toward products claiming to stop it. |
| MCP server and tool authorization | Over-broad tools, token misuse, untrusted local servers. | The MCP specification and draft best practices describe input validation, access controls, rate limits, exact-command consent, no token passthrough, and progressive scopes (source). | The best practices page is an undated draft. Anthropic states MCP servers run outside its sandbox. Enforcement by specific clients: Not stated in the documentation we reviewed. |
| Monitoring and rate limits | Slow detection of misuse and unbounded damage. | OpenAI states safety monitoring runs asynchronously. The MCP specification says servers must rate limit tool invocations. | OWASP states monitoring and rate limiting will not prevent Excessive Agency but can limit damage. OpenAI states a pause can arrive after the triggering activity and monitoring does not replace sandboxing, permissions or review. |
The sources we reviewed state no effectiveness rates for any of these controls. Cloud agent platform equivalents: Not stated in the documentation we reviewed.
A rollout sequence Lightbridge advises for agent access.
The order below is Lightbridge's planning judgment. It is not drawn from a vendor or standards source, though each step rests on the statements above.
- Inventory first. List which agents, extensions and MCP servers are already in use, who owns each, and what each can reach. Shadow AI discovery feeds this step.
- Start read-only. Give the first agents read access in a sandbox, with network off. Watch what they ask for.
- Write down the tool list. One owner per tool. Replace open-ended tools like shell and URL fetch with narrow ones where you can.
- Move credentials out of reach. Use a service identity and short-lived credentials per agent. Keep long-lived keys off the machine the agent runs on.
- Add the approval gates. Gate writes outside the workspace, credential use, new egress hosts, and side-effecting calls into other systems. Put the policy in managed settings so a user cannot lower it.
- Open egress by exception. Allow named hosts only. Remember the proxy limits above, and add network-layer controls where the stakes justify them.
- Review each MCP server before connecting it. Read the command, the tools, the scopes and the token handling.
- Turn on logging, then test the stop. Confirm you can see what an agent did and halt it. The NCSC readiness test is whether you can understand, monitor and contain it. See AI observability and audit logging.
- Widen autonomy in steps. Expand scope only after a review period, and record each decision.
Agent contracts raise their own questions about data use, liability and subprocessors. Lightbridge covers those on AI contracts and legal.
How Lightbridge advises on AI agent security.
Lightbridge is an independent advisory and program-management firm. We help a CIO or CSO decide where agents are allowed, set the permission and approval model, and run the rollout through delivery. Where hands-on configuration, tooling or security testing is needed, vetted partners deliver under Lightbridge's program management. This page does not recommend a vendor.
Related Lightbridge guides: the security hub, AI access paths, and shadow AI. For wider strategy, see Lightbridge's AI advisory.
Lightbridge Automation, a sibling practice in the Lightbridge group, offers AI governance consulting and publishes explainers on LLM gateways, zero data retention, and the NIST AI RMF. If a recommendation here points to work a sibling practice would deliver, Lightbridge discloses that upfront and you remain free to take the work elsewhere.
AI agent security: frequently asked questions answered by Lightbridge
What changes when a model can act and not only answer?
A chat answer can be wrong. An action can be wrong and also change something. OWASP defines LLM06:2025 Excessive Agency as the vulnerability that enables damaging actions in response to unexpected, ambiguous or manipulated model outputs, and names excessive functionality, excessive permissions and excessive autonomy as the root causes. Lightbridge reads that as a design question: every tool, credential and unattended step you grant is a decision someone should own.
Can a sandbox stop prompt injection?
No. A sandbox limits what an injected instruction can reach after it lands. Anthropic states the Claude Code sandbox reduces risk but is not a complete isolation boundary, and OpenAI states its devcontainer guidance does not prevent every attack. The UK NCSC states that LLMs do not enforce a security boundary between instructions and data, and that prompt injection may never be totally mitigated the way SQL injection can be.
Who should decide when an agent needs human approval?
The people who design or operate the system, not the agent. The joint agentic AI guidance hosted by the Australian Cyber Security Centre, co-authored with the NCSC and international partners, recommends that the decision of when human approval is required is set by system designers or operators and not delegated to the agent. It lists network egress among the high-cost actions that need approval.
Is a permission prompt enough protection for shell access?
Not on its own. Anthropic states that Bash permission patterns which constrain command arguments are fragile: a curl URL pattern, for example, does not match option-order, protocol, redirect or variable variants. Anthropic recommends using both permissions and sandboxing, because sandbox restrictions still apply if a prompt injection bypasses the model's decision-making. Lightbridge advises treating prompts as a usability layer and the sandbox and credentials as the control.
What should we check before connecting an MCP server?
Read the exact command or endpoint, the tools it exposes, and the credentials it receives. The MCP security best practices say a client supporting one-click local server configuration must show the exact command, flag it as potentially dangerous, and require explicit approval. They also state that servers must not accept tokens not explicitly issued for the MCP server. Whether a given client enforces these points: Not stated in the documentation we reviewed.
Do approval gates slow teams down too much?
They can, if every step asks. Gate the actions that are hard to undo: writes outside the workspace, network egress, credential use, and calls that change data in another system. Let read-only work in a sandbox run. OpenAI states Codex pairs a sandbox with an approval policy so routine in-sandbox work proceeds and escalations ask. Lightbridge's view is that a gate people click through unread has stopped being a control.
Where does monitoring fit?
It limits damage and supports investigation. It does not prevent the action. OWASP states that logging, monitoring and rate limiting will not prevent Excessive Agency but can limit the damage. OpenAI states its safety monitoring runs asynchronously, a pause can arrive after the triggering activity, and monitoring does not replace sandboxing, permissions or review. The logging side of this is covered on Lightbridge's page on AI observability and audit logging.
Set the limits before the agents scale: talk to a Lightbridge advisor.
Bring your current agent tools, MCP servers, and endpoint setup. Lightbridge will help you map controls to threats and plan a rollout your security team can defend.