- Home
- AI agents
- Agent identity and access
- Least privilege and sandboxing
Govern and secure · Agent identity and access
Least privilege and sandboxing for AI agents: how to limit what an agent can reach
Least privilege for an AI agent means it holds only the permissions, tools, data and network paths its task needs, for no longer than the task takes. Sandboxing means any code, browser or desktop the agent drives runs in an isolated environment with no standing credentials, so misbehaving code stays away from the host and other sessions.
In this guide: 83 pages
Key takeaways
- Several 2025 agent incidents needed no software bug, only an agent with more access than its task: an assistant running with a database service role in the Supabase demonstration, and a coding agent at Replit that could run commands against a production database.
- Least privilege for agents has five layers: identity scopes, tool policy, the sandbox code runs in, network egress and the data the agent can read. Each layer limits a different failure, so a gap in one stays open.
- Sandboxes are now a managed service. AgentCore runs each session in its own microVM, Google's Computer Use sandboxes reached general availability on 9 Sep 2026, and Anthropic and Microsoft both say to run screen-driving agents on machines with no credentials or sensitive data in reach.
- Sandboxes have bugs too. A 2026 AgentCore SDK flaw allowed command injection in the Code Interpreter sandbox, and an OpenClaw flaw let an attacker switch off approval prompts and sandboxing, so patch the sandbox like any other dependency.
What does least privilege mean for an AI agent?
It means scoping five things to the task: the identity's grants, the tools and arguments the agent may call, the environment its code runs in, where it can send data, and which data it can read. An agent needs all five because the model decides at run time which of its permissions to use.
The five layers, the control that ships for each on 2 Nov 2026, and an incident or risk the layer would have limited.
| Layer | Question it answers | Control that ships today | Incident or risk it limits |
|---|---|---|---|
| Identity scopes | What may the agent's token do? | Foundry agent identities start with zero permissions; Entra Conditional Access for agents; IAM roles on AgentCore and Google principals | Supabase demonstration, July 2025: the assistant ran with the service role, which bypasses row-level security |
| Tool policy | Which calls, with which arguments? | AgentCore Policy (Cedar) at the gateway; the Foundry MCP tool's allowed_tools and require_approval; Google Agent Gateway | GitHub MCP toxic agent flow, May 2025: one repository per session was the recommended fix |
| Sandbox | Where does generated code or a browser run? | AgentCore Runtime microVM per session; AgentCore Code Interpreter and Browser; Google Computer Use sandbox | Replit, July 2025: the agent could run destructive commands on a production database |
| Network egress | Where can the agent send data? | Network egress controls for Foundry hosted agents (preview); Global Secure Access for Copilot Studio; Agent Gateway egress policies | EchoLeak, ForcedLeak and CamoLeak, 2025: data left through image URLs |
| Data | What can the agent read? | Sensitivity labels; permission-aware retrieval; read-only tool modes | Oversharing: an agent surfaces whatever its user can already reach |
Each layer stops something the others miss. A narrow token still lets an agent send what it legitimately read to an attacker's URL, which an egress rule blocks. A sandbox still lets a tool call through if the token allows it, which a tool policy catches.
How do you scope an agent's permissions in practice?
Start from zero, grant per tool, and prefer read-only and single-resource modes wherever the tool offers them. Then put a deterministic policy at the tool call, so that what the token allows and what the agent may do with it are checked separately.
- Start from zero. New Foundry agent identities start with no permissions, and Foundry's move to per-agent identities does not carry role assignments across, so grant each role on purpose and write down why.
- Use the narrow modes the tool already has. For the Supabase MCP server the listed fixes were read_only=true, scoping to one project and limiting tool groups. GitHub's Copilot cloud agent can push to only one branch, and a firewall limits its internet access.
- Write the rule outside the model. AgentCore Policy (GA 3 Mar 2026) checks every agent-to-tool request at AgentCore Gateway against Cedar policies, written directly or converted from natural language, in enforce or log-only mode. AWS's launch example permits a payment tool only for one role and below a set amount.
- Keep the tool list short. The Foundry MCP tool treats an empty allowed_tools list as all tools, so list them explicitly. Tool choice also gets worse as the list grows; Anthropic reports that selection accuracy degrades beyond 30 to 50 tools.
- Separate development from production credentials. Replit's response to its July 2025 incident was automatic separation of development and production databases, better rollback and a planning-only mode.
When does an agent need a sandbox, and what should the sandbox include?
Whenever the agent runs code it wrote, installs packages, or drives a browser or desktop. The sandbox should be created per session, hold no standing credentials, reach only allow-listed hosts and be destroyed when the task ends.
The clouds now sell this as a service. AgentCore Runtime runs each user session in a dedicated microVM with isolated CPU, memory and filesystem, for up to 8 hours on microVMs. AgentCore Browser is a managed, isolated browser with sessions of 15 minutes by default and 8 hours at most, Live View and session recording to S3. Foundry hosted agents run with microVM-level isolation, and hosted-agent code gets tokens only from a token service outside its sandbox. Google's Computer Use sandboxes in Gemini Enterprise Agent Platform became generally available on 9 Sep 2026.
For agents that drive a screen, the vendors' advice converges. Anthropic recommends a minimal-privilege virtual machine with no credentials in reach, domain allow lists and human confirmation for consequential actions. Microsoft says Foundry computer use carries significant security and privacy risks, including prompt injection, and should run on virtual machines with no sensitive data. Copilot Studio's allow list blocks actions on sites that are not listed but does not stop the model from opening them.
Test the isolation yourself. CNBC reported on 18 Sep 2026 that Google disclosed a Gemini model in a capture-the-flag test run by Irregular had reached three real external systems because a bug in the test environment exposed the internet. Send a canary request from inside the sandbox to a host that should be blocked, and confirm it fails, before any real task runs there.
How do sandboxes and permissions fail?
They fail when the sandbox software has a flaw, when credentials sit inside an agent other people use, when an attacker can change the agent's own safety settings, or when a gateway accepts callers it never checks. Each case below has a public record.
- A flaw in the sandbox. CVE-2026-12530 (CVSS 7.3, 17 Jun 2026) let a crafted install_packages() argument run arbitrary commands in the AgentCore Code Interpreter sandbox; the fix is AgentCore Python SDK 1.6.1.
- Safety settings an attacker can switch off. CVE-2026-25253 in OpenClaw (CVSS 8.8, 1 Feb 2026) let a link send the app's auth token to an attacker, who could then disable approval prompts and sandboxing and run commands on the host. Version 2026.1.29 fixed it; tokens had to be rotated.
- Credentials inside a shared agent. Copilot Studio warns that sharing an agent configured with maker-provided credentials lets anyone using it act with the author's access.
- Gateways that skip the check. AgentCore Gateway's NONE inbound mode accepts unauthenticated callers, and AUTHENTICATE_ONLY verifies the caller but leaves the authorization decision to a policy engine, an interceptor or the target. Without one of those, nothing decides what a caller may do.
How do Microsoft, AWS and Google implement it?
Where each layer lives on each cloud, as the vendor pages showed on 2 Nov 2026.
Capability, Microsoft, AWS, Google
| Capability | Microsoft | AWS | |
|---|---|---|---|
| Scoped identity | Entra agent identity; Foundry identities start with zero permissions | AgentCore workload identity with IAM roles | SPIFFE-based principal with IAM roles |
| Tool-call policy | Foundry MCP tool allowed_tools and require_approval; Copilot Studio data policies | AgentCore Policy with Cedar (GA 3 Mar 2026) | Agent Gateway; semantic governance policies on tool calls (preview 29 Jun 2026) |
| Code and browser sandbox | Foundry hosted agents with microVM isolation; code interpreter and browser automation tools | AgentCore Runtime microVMs, Code Interpreter and Browser | Computer Use sandbox (GA 9 Sep 2026) |
| Egress control | Network egress controls for hosted agents (preview); Global Secure Access for Copilot Studio | Gateway targets you register; no agent-specific egress feature verified for this page | Agent Gateway egress allow and deny rules |
Status labels move fast. Foundry egress controls for hosted agents and Google's semantic governance policies were previews on 2 Nov 2026, and sources disagree on when Foundry hosted agents reached general availability.
Frequently asked questions
What is the difference between least privilege and a sandbox?
Least privilege limits what the agent may reach through its identity and tools. A sandbox limits the damage when something the agent runs misbehaves, by isolating code, browsers and files from everything else. You need both: a sandboxed agent with a broad token can still misuse the token, and a narrow token does nothing to contain a malicious package.
Can the code an agent runs work without any credentials?
It can and should. Foundry hosted agents get tokens from a token service outside the sandbox, and AgentCore keeps third-party tokens in a vault that releases them only to the right agent. The agent process still needs an identity to call tools, but the generated code and the browser it drives should never see a secret.
How often should we review an agent's permissions?
At every version that adds a tool or a data source, and on a fixed cycle for autonomous agents, for example every quarter. Compare the granted permissions with the ones the logs show the agent used, and remove the rest. Google warns that deleted agents leave inactive IAM bindings, so include deleted agents in the review.
Do sandboxes stop prompt injection?
No. Injection changes what the agent decides to do, and a sandbox only limits where the resulting code or clicks can reach. Pair sandboxes with egress allow lists and approval gates for consequential actions, which is what Anthropic and Microsoft both advise for computer use.
More in Agent identity and access
Sources
Each source was read on 2 November 2026. The date shown is the date on the page, or the page’s ms.date for Microsoft Learn; an undated page shows the date it was read.
- Host agents with AgentCore Runtime
- AgentCore Browser
- Policy in Amazon Bedrock AgentCore is now generally available
- Amazon Bedrock AgentCore adds quality evaluations and policy controls
- AgentCore Gateway inbound authorization
- Agent identity in Microsoft Foundry
- Connect to Model Context Protocol servers (Foundry Agent Service)
- Guardrails and controls in Microsoft Foundry
- Computer use tool (Foundry)
- Computer use in Copilot Studio
- Computer use tool
- Introducing advanced tool use
- Gemini Enterprise Agent Platform release notes
- Report on a Gemini model reaching external systems during a security test
- Supabase MCP data leak demonstration
- GitHub MCP toxic agent flow
- Report on the Replit agent deleting a production database
- Risks and mitigations for Copilot cloud agent
- CVE-2026-12530
- CVE-2026-25253
Planning an AI program?
Talk to the team that builds it and runs it after launch.
- Built to SOC 2, HIPAA and GDPR standards
- EU AI Act-aligned delivery
- Microsoft Solutions Partner