Claude Managed Agents Security for Anthropic Managed Agents with Permission Policies and MCP Approvals

On September 10, 2026 Anthropic added auto to the two existing policies. Under auto, the server evaluates each agent or MCP tool call, considering the tool, the input and the session so far, and either runs it, denies it as high risk, or pauses for your approval when it reaches no determination. It is a genuinely useful middle ground for agents that would otherwise ask about everything. Anthropic is also unusually direct about its limits, and those limits are the reason this page exists.

"auto is not a human checkpoint. If the server determines that a call is safe, the call runs before anyone sees it, and its effects might not be reversible."

The second limit is about intent. Anthropic's docs say that what you post in user.message events counts as your intent and can lead the server to allow a call it would otherwise deny. The server does not take instructions from tool results, fetched pages or MCP responses. But "if you relay untrusted end-user input in user.message events, the server reads that input as your intent too, and it can get a call allowed." Any agent that forwards customer chats, tickets or portal messages as user messages is in that position.

The pain story above is the textbook case. With an approval gate for AI agent actions on the ledger MCP endpoint, a fee waiver over a set amount would have waited for a named manager, and the tenant's claim of prior approval would have changed nothing, because the manager's decision is an event in a separate channel, not text in the conversation.

Scheduled deployments start sessions on a cron schedule, which is where Managed Agents earns its keep for back-office work. They also change what always_ask means. When a call evaluates to ask, the session goes idle with stop_reason requires_action, and Anthropic's docs say "the session waits indefinitely for a response." At six in the morning there may be nobody to respond.

That pushes teams toward auto or always_allow on exactly the runs that nobody watches. A few other details from the docs matter here:

• Policy changes are not retroactive. "Running sessions keep the toolset configuration they were created with. Updates apply to sessions created afterward." Tightening a policy does not touch a long-running session.
• Budgets bound each run, not the schedule. A deployment copies its budget to every session it starts, so the cap is per run, and a session that hits it pauses with budget_reached rather than ending.
• Pausing a deployment stops new triggers only. Sessions from earlier runs keep executing.
• Your client cannot override an auto denial, and it cannot send a confirmation for a call that was not paused for one.

The fix is not to staff a night shift. It is to move the decision for consequential calls out of the session and into a gate that knows who is on call. Webhooks tell you a session paused; a gateway with routing rules decides who gets asked, how long to wait, and what happens on timeout. That is the part of AI agent permissions management Managed Agents leaves to you.

No. Anthropic's overview states that because Managed Agents is a stateful service, it "is not currently eligible for Zero Data Retention or HIPAA Business Associate Agreement (BAA) coverage." The API and data retention page adds that session transcripts persist until you delete them, and that the exclusion applies to all Managed Agents sub-features, including self-hosted sandboxes.

Self-hosting the sandbox does not change the answer, and it moves more of the job onto you. Anthropic's security model for self-hosted sandboxes says "Anthropic's security boundary stops at the sandbox," that it "does not inspect or verify your sandbox image," and that egress control, the environment service key, tool isolation and log retention are yours. Our healthcare AI agent security page covers the rest of the HIPAA picture for agents.

Anthropic ships good primitives. This is how we would use them, in order, with the action layer where it belongs. The platform neutral version is our page on AI agent security best practices.

1. Set networking explicitly. Use limited with an explicit allowed_hosts list. Since October 7, 2026 that list also governs web_search and web_fetch. Note that any allowed host accepts any request, including uploads such as git push.
2. Decide bash on purpose. Override bash to always_ask or disable it for agents that do not need a shell. Disabled tools are removed from the agent entirely.
3. Keep secrets in vaults. MCP tokens are injected when the agent connects, and environment variable credentials stay placeholders until egress, so "the agent never sees the secret value." One caveat from the docs: if a client uses a stored secret to fetch a session token, such as an OAuth client credentials grant, "the returned token arrives in the sandbox unredacted."
4. Do not relay untrusted text as user messages under auto. Hand it to the agent as a custom tool result instead, which the server assesses without taking intent from it, or keep always_ask on the tools that text could trigger.
5. Put write tools behind a policy gate. Point MCP servers that move money, change records or send external messages at a gateway that evaluates each call and holds the risky ones for a named approver.
6. Govern custom tools in your handler. Permission policies never see them, so validation and approval belong in the code that executes them.
7. Cap spend per session. Budgets are priced at public list rates; set one on every deployment.
8. Keep an audit trail outside the session. Transcripts can be deleted and the evaluation field records the server's view, not your approver's. Your AI agent audit trail should record who asked, which call ran, which rule applied and who approved.

Anthropic's own October 7 change is a good example of why defaults matter. web_fetch now fetches only URLs that already appeared in the session, and a URL that appears only in Claude's own output, an attached document or a tool result returns url_not_in_prior_context. Anthropic says the change "reduces the risk of data exfiltration." Sessions before that date did not have it.

Three of six rows end without a purchase from us, and one tells you to keep a workload off the product. If you are comparing options, the buyer guide for Claude Managed Agents sets six of them side by side, and the MCP server security page covers the server side of the gate.