Anthropic's September 10, 2026 release added the auto permission policy to Claude Managed Agents. The server now evaluates individual tool calls and can run them, deny them, or pause for approval. Teams handling customer requests need to check which actions they are willing to delegate to that decision.
Consider a support agent that can change an account. A customer gives it clear instructions but may lack permission to affect the account they named. Anthropic treats relayed user.message content as developer intent, including untrusted customer input. Keep tools on always_ask where an authorized person must review the operation. Permission policy documentation.
This guide develops that support scenario into an approval procedure. The configuration and recovery recommendations are illustrative; General Analysis has not tested a Managed Agents deployment for this article.
Decide what the customer can cause#
Write down the authority for each action before choosing its permission policy. In the hypothetical support application, a customer can request a correction, a support reviewer can approve certain corrections, and a service credential performs the actual write. Those are separate identities.
Our recommended split is:
| Reader task | Tool exposure and review decision |
|---|---|
| Answer from approved support material | Expose a narrow search tool; constrain its data access to the intended customer and knowledge base. |
| Propose an account correction | Let the agent prepare a proposal. Keep the write behind independent review. |
| Change account ownership or access | Omit the tool from the customer workflow unless an authorized reviewer and downstream checks cover it. |
| Execute application-owned business logic | Enforce customer scope and approval inside the custom-tool handler. |
The table is a design recommendation, not a list of vendor-defined risk levels. A read can disclose another customer's records; a small write can grant access. Judge the reachable data and effects.
The broader MCP server threat model explains why restricting tool names alone is insufficient. Review the credentials and the server implementation behind each enabled tool.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Expose a small MCP toolset#
The MCP connector supports a disabled default with individual tools enabled by their bare server-reported names. It separates server declarations on the agent from vault-backed authentication supplied when creating a session.
Here is an illustrative excerpt from an agent definition. The server and tool names are placeholders for your own reviewed support service. Replace them with its exact schema names. Other required agent and session fields are omitted.
Code source: illustrative; configuration fields follow the MCP connector reference.
mcp_servers:
- type: url
name: support
url: https://support-mcp.example.com/mcp
tools:
- type: mcp_toolset
mcp_server_name: support
default_config:
enabled: false
permission_policy:
type: always_ask
configs:
- name: search_support_articles
enabled: true
permission_policy:
type: auto
- name: update_customer_contact
enabled: true
permission_policy:
type: always_ask
This configuration leaves newly exposed server tools disabled. Review a schema change before adding another name. On the service side, derive the customer scope from authenticated application state; do not accept an arbitrary customer ID from the agent as proof of access.
Also inspect the built-in agent toolset. Including it enables its tools by default, and individual entries can be disabled. Omit it if this workflow does not need sandbox file, shell, or web access. A carefully reviewed MCP write path offers little protection if the same service credential is available to an unrestricted shell.
Managed Agents is an API beta; Anthropic documents API-account access and the managed-agents-2026-04-01 header. Use the current setup requirements, rather than treating Claude Code settings as this API's configuration.
Route each pending call to the right handler#
Under auto, a call may run, be denied, or require confirmation. A server denial cannot be overridden by a confirmation. Custom tools sit outside these policies and execute in your application. Policy scope and outcomes.
Build separate handlers for these paths. The event guide documents server-tool confirmations: an idle event with requires_action identifies blocking calls in stop_reason.event_ids. Resolve each ID to its persisted tool-use event. An approval uses user.tool_confirmation, with that ID in tool_use_id and an allow or deny result. The session resumes after all blockers resolve.
For a custom tool, the application receives agent.custom_tool_use, decides whether to execute it, and returns user.custom_tool_result. Use the custom-tool flow for that branch. A generic handler that executes every requires_action event would discard the distinction.
Treat a missing event, an unsupported event type, or an unfamiliar permission outcome as unresolved work. Alert the operator and preserve the pending record. Do not infer an approval from the agent's explanation of what it intends to do.
Bind review to the actual operation#
Build the review screen from the recorded tool name and input. Show the customer account, destination, proposed change, and the authority the tool will use. Keep explanatory model text visually separate so it cannot substitute for the requested operation.
We recommend saving an approval record with:
- Session and tool-use event IDs, plus the authenticated customer identity.
- The proposed operation and an immutable copy or digest of its exact arguments.
- Reviewer identity, authorization check, decision, and decision time.
- Confirmation delivery state and the eventual downstream operation ID or result.
These are application record fields, not additional fields to send to Anthropic. Restrict access to the record: tool arguments can contain personal information.
Authorize the reviewer against the affected resource. A person allowed to review one customer's request should not approve another customer's account change by altering a URL. Recheck that authority when they submit the decision, including whether the account or requested change has become stale.
Make the approval single-use in your application, keyed by the session and tool-use event. Two browser tabs should not create competing decisions. Record the decision before delivering it through a worker, and serialize delivery for that key. A later request with different arguments needs its own review.
Recover a dropped connection without repeating the effect#
A lost HTTP response leaves the client uncertain about delivery. It does not establish that the server rejected the confirmation. Record that uncertainty explicitly.
Anthropic's streaming documentation directs reconnecting clients to reopen the stream and retrieve event history. Rebuild your pending set from persisted records. Assistant-text previews are not an approval ledger.
For an uncertain confirmation, first look for the accepted confirmation, the tool result, and the current session state. Check the downstream service when those records do not settle whether the write occurred. Keep the action unresolved until the evidence supports another delivery attempt or a completed outcome.
For custom writes, use the downstream service's idempotency mechanism when it has one. Persist the operation result before returning it to the agent. If that result delivery fails, recover the saved result instead of executing the write again. Where the downstream service has no reliable deduplication or lookup, send an uncertain outcome to an operator.
These recommendations do not assume that a tool-use ID is a vendor-supported idempotency key or that confirmation delivery has an exactly-once guarantee. They keep your application from turning a network retry into a second business operation.
Roll out the policy to new sessions deliberately#
Updating an agent leaves existing sessions on their original toolset configuration. The new configuration applies to later sessions. Session policy lifetime.
Record the agent configuration used to create each session. When tightening a policy, identify sessions that still have the old authority and decide which must stop before the rollout is complete. Follow the existing ant apply deployment and recovery procedure for resource changes; verify the session state separately.
Before handing this workflow to customers, check the application with synthetic records and non-production tool implementations. A reviewer should be unable to approve another customer's call; duplicate submissions should preserve one decision; a disconnect should recover the pending operation; and a custom-tool failure should return through its own handler without triggering another write. Record expected and observed results separately.
For the surrounding deployment baseline, see securing coding agents. Enable customer access only when someone can trace a sensitive operation from the authenticated request through review to its actual effect.
