Does self-hosted tool execution actually solve the enterprise AI-agent security problem?

First, define the boundary you are moving

An AI agent has several distinct parts:

1. Model and orchestration: the service that receives context, decides what to do next, invokes tools, handles retries, and maintains session state.
2. Tool execution: code, commands, files, packages, browsers, or internal APIs that perform the work.
3. Data and identity services: document stores, databases, secrets managers, authorization systems, audit logs, and policy engines.
4. Connectivity: paths between the agent, the execution environment, the provider, MCP servers, and any external destination.

Self-hosted tool execution moves only the second part, and sometimes changes the connectivity path. It is a valuable security boundary because tools can mutate state. But moving tool execution does not automatically move the model or the orchestration service, and it does not automatically give the tools a safe identity or safe instructions.

The observed question was prompted by Anthropic's Claude Managed Agents feature. Its current documentation describes exactly this split: self-hosted sandboxes run tools on infrastructure the customer controls, while orchestration remains on Anthropic infrastructure. Anthropic also states that a self-hosted worker receives execution requests, runs them locally, and posts results back. Anthropic product announcement · Anthropic self-hosted sandbox integration guide

This article uses “customer-controlled” rather than “self-hosted” where precision matters. A sandbox operated in the customer's cloud account is customer-controlled. A configured sandbox from another managed provider may improve control and isolation, but it still adds another supplier and a separate shared-responsibility boundary.

Customer-controlled versus provider-controlled execution

Neither choice is universally safer. The safer design is the one whose boundaries, identities, data flows, and operational controls match the workload. This comparison assumes a hosted model and agent-control plane, because that is the architecture in the source record.

The table shows why the answer is not “hosted bad, self-hosted good.” Customer control can shrink the execution boundary and improve evidence, but it also transfers hard responsibilities to the customer. Anthropic's current security model makes this explicit: it secures the control plane, while the customer owns sandbox hardening, egress controls, service-key storage and rotation, isolation of untrusted workloads, tool-execution blast radius, and local log retention. Anthropic self-hosted-sandbox security model

What self-hosted execution genuinely improves

Local execution and network control

A customer-controlled sandbox lets the enterprise decide which directories are mounted, which tools exist, what process user runs them, how much CPU, memory, time, and disk they receive, and where they may connect. In the Claude Managed Agents design, Anthropic documents that tool execution, filesystem access, spawned processes, and network reach are under the customer's control. Anthropic self-hosted sandboxes documentation

That creates real defensive options:

• Mount a single read-only repository snapshot instead of a developer workstation or shared file share.
• Run one fresh, non-root microVM or hardened sandbox per task, rather than reusing a stateful environment across users.
• Allow only an internal package mirror, source-control API, and artifact store. Deny arbitrary internet access by default.
• Put outbound calls behind an egress proxy that enforces destination allowlists, request logging, content controls where appropriate, and rate limits.
• Give the sandbox a short-lived identity for one approved operation, rather than a long-lived general-purpose API key.

These controls directly reduce the damage a compromised or mistaken tool call can cause. They do not rely on the model always recognizing a malicious instruction.

Private service access without public exposure

Customer-controlled execution can reach private services without turning them into public APIs. In the specific Anthropic implementation, MCP tunnels use an outbound-only connection to private MCP servers, avoiding inbound firewall openings and public endpoints. The tunnel is not the authorization decision, however. Anthropic's documentation says each upstream MCP server still needs its own authentication and that the tunnel itself does not authenticate to it. Anthropic MCP tunnels overview

This is a useful pattern when combined with per-service authorization. It is not permission to treat every service on the internal network as trusted merely because the sandbox sits inside that network. NIST's Zero Trust Architecture says location and ownership alone should not grant implicit trust. NIST SP 800-207, Zero Trust Architecture

Customer-side telemetry and containment

When execution is in your environment, you can correlate a tool invocation with the actual API request, process, filesystem path, egress decision, data classification, and delegated identity. You can also stop the worker, revoke the customer-side identity, quarantine a mounted data source, or remove a network route without waiting for a provider change.

That is especially valuable for incident response. The customer should design these controls before onboarding the agent, not infer them from a successful demo.

What it does not solve

1. Data residency is a data-flow question, not an execution-location question

Keeping execution local can keep local files, artifacts, and local logs local. It does not make all data resident in the same location. In the documented hybrid architecture, tool inputs and outputs go to the hosted control plane, and attached memory stores may remain hosted by Anthropic and synchronize with the local sandbox. Anthropic self-hosted sandboxes documentation · Anthropic self-hosted-sandbox security model

For the current Claude Managed Agents product, Anthropic also documents that sessions are stateful and transcripts persist until deleted, so Managed Agents is not eligible for its zero-data-retention arrangement. That is a product-specific fact, not a general property of all hosted agents. Anthropic API and data retention documentation

Decision rule: draw a data-flow map before approving the workload. Mark every item that can cross the provider boundary: user prompt, system prompt, tool definition, tool arguments, tool result, error, file metadata, retrieved text, memory, session transcript, telemetry, and support record. For restricted data, either keep it out of the context entirely or make the tool return a minimum necessary, redacted, aggregated, or policy-approved result. Contract terms, region configuration, subprocessor disclosures, retention controls, and applicable privacy obligations still need separate review.

2. Secrets and identity need a real authorization design

A self-hosted worker needs credentials to receive work and access services. That turns credential design into a central security task, not an implementation detail. Anthropic's guidance says to keep the environment service key in a secrets manager, rotate it on suspected exposure, and use per-session secrets where applicable. Anthropic self-hosted-sandbox security model

The minimum standard is:

• A tool receives the narrowest identity needed for one operation, not the user's broad cloud, database, or source-control credential.
• The identity is short-lived, audience-bound, tenant-bound, and scoped to the object, environment, and action.
• A policy enforcement point checks the user, agent session, tool, arguments, resource, data classification, approval status, and risk context immediately before execution.
• High-impact writes, exports, deployments, payment-like actions, and privilege changes require a separate approval or deterministic workflow.
• Secrets never appear in prompts, tool descriptions, model-visible error messages, source repositories, container images, or ordinary logs.

MCP does not remove this responsibility. Its authorization specification requires access tokens to be validated for the intended resource and explicitly forbids token passthrough. An MCP server calling an upstream API needs a separate appropriate credential for that API. Model Context Protocol authorization specification

3. Prompt injection remains an authorization problem

Prompt injection occurs when content an agent reads changes its behavior away from the user's legitimate request. That content may be a public page, a support ticket, a document, a database record, a tool result, or a piece of persistent memory. NIST's adversarial-machine-learning taxonomy includes indirect prompt injection, in which an attacker modifies an external information source that the system later ingests. NIST AI 100-2e2025

A local sandbox does not prevent a model from reading hostile text and choosing an unsafe tool call. The correct assumption is that some manipulations may succeed. OpenAI's current guidance argues that filtering inputs alone is insufficient and that systems should constrain the impact of manipulation even when it succeeds. OpenAI, Designing AI agents to resist prompt injection

Treat the model as an untrusted planner, not as the final security authority:

• Give it narrow tools with typed inputs and constrained verbs.
• Keep any private-data retrieval and external communication from occurring together unless a specific policy permits the pairing.
• Validate tool arguments in ordinary deterministic code, not by asking the model whether its own request is safe.
• Separate planning from execution. An agent may prepare a proposed change, while an approval service or deterministic pipeline executes it.
• Label context by source and trust level, and test indirect-injection paths using safe copies of real work artifacts.

4. Sandboxing is valuable, but it is not a magic isolation guarantee

A sandbox is only as strong as its runtime hardening, host configuration, permissions, mounts, network path, and patching. Container technologies provide useful isolation and packaging, but NIST's container-security guidance treats them as a technology with distinct security concerns that require controls. NIST SP 800-190, Application Container Security Guide

For the specific self-hosted feature, Anthropic says it does not inspect or verify a customer's image, does not isolate tools inside the customer sandbox, and cannot detect a supply-chain compromise in the image from its control plane. It recommends non-root execution, dropping unnecessary Linux capabilities, a read-only root filesystem, per-trust-boundary environments, and egress restriction. Anthropic self-hosted-sandbox security model

So use per-session isolation for untrusted or multi-tenant work, minimize mounts, disable unnecessary interpreters and tool classes, patch the host and image, and assume a sandbox escape or misconfiguration is possible in your incident plan.

5. Supply-chain and tool trust move closer to you

Customer control also means customer responsibility for sandbox images, language packages, helper binaries, skills, MCP servers, custom tools, CI builds, and infrastructure definitions. Track provenance and versions, use approved artifact sources, scan and patch images, verify signatures where supported, and make new tools or tool changes subject to review.

NIST SP 800-218A extends its Secure Software Development Framework with practices specific to generative AI and dual-use foundation models. It is intended for AI model producers, system producers, and acquirers, which makes it a practical baseline for the part of the stack you control. NIST SP 800-218A

For MCP servers, include the server package, owner, data access, auth method, scopes, tool schema, network destinations, version or digest, and kill switch in the service inventory. The protocol's security guidance also calls out token passthrough, confused-deputy, SSRF, session, and consent concerns. MCP Security Best Practices

6. Auditability and incident response must cover the whole path

Self-hosting makes local audit evidence possible, not automatic. A useful record links a user request to the policy decision, agent session, model/version, tool definition/version, delegated identity, validated arguments, data sources, approval event, process or API result, and egress decision. Protect the log store itself with access controls, retention rules, integrity controls, and a clear division between routine diagnostics and forensic evidence.

Plan for the event in which a tool or credential is compromised:

1. Disable the affected tool, MCP server, worker environment, or egress route.
2. Revoke and rotate customer-side service identities, session secrets, tunnel tokens, and keys.
3. Preserve relevant logs and determine which users, data sources, tools, destinations, and identities were actually involved.
4. Quarantine affected memory, retrieval, or artifact sources and inspect the ingestion and release paths.
5. Repair the deterministic control or reduce authority, then reproduce the scenario safely and add it to the regression suite before re-enabling the capability.

Anthropic's current documentation notes that it cannot know that a customer key has leaked and that the customer must revoke and replace the environment key if exposure is suspected. Anthropic self-hosted-sandbox security model

A concrete enterprise architecture

The following is a recommended hybrid pattern for a software-engineering agent that can inspect a private repository, run tests, and prepare a deployment change. It is a hypothetical architecture, not a claim about any vendor's default configuration.

Employee
  |
  v
Enterprise app and request policy
  |  user, tenant, task class, data label, approval requirement
  v
Hosted model and orchestration control plane
  |  minimized task context, tool requests, tool results
  v
Customer environment worker, outbound-only connection
  |
  +--> Per-session microVM or hardened sandbox
  |      - non-root process, read-only base image
  |      - repository snapshot mounted read-only
  |      - no persistent cross-user workspace
  |      - default-deny egress through proxy
  |
  +--> Tool and action broker
  |      - typed tool schema and allowlisted operations
  |      - policy decision at execution time
  |      - short-lived, task-scoped service identity
  |      - human approval for production change
  |
  +--> Internal services
         source control, CI test runner, artifact store, change system
         each enforces its own identity and authorization

Telemetry path: policy decision + tool call + identity + egress + result
                -> protected audit/SIEM store

The model can propose: “Run the approved test suite for commit X” or “Create a deployment-change draft.” It cannot run arbitrary shell commands against an unrestricted network, read an unrelated repository, push to production, or export data to an external destination. The tool broker checks each request independently. A production deployment is executed only after the change system receives a human approval and its own release controls pass.

This design implements the main insight of zero trust: the sandbox's network location is not the authorization. Each resource evaluates a concrete access request. NIST SP 800-207, Zero Trust Architecture

Threat-model example: a hostile support ticket reaches an internal agent

Hypothetical scenario: An engineering triage agent reads a support ticket, searches an internal issue tracker, and can create a draft remediation ticket. An attacker submits a ticket containing text intended to redirect the agent toward unrelated private data and an external destination.

The risk is not limited to whether the model recognizes the text as hostile. The relevant source, capability, and controls are:

The conclusion is deliberately modest: this architecture does not prove that injection will never influence the agent. It makes the influence insufficient to perform a prohibited action unless another control also fails.

Implementation checklist before allowing internal tool access

• Inventory every model, agent, worker, image, tool, MCP server, identity, data source, memory store, egress destination, owner, and kill switch.
• Document the full data-flow map, including prompts, tool inputs and outputs, transcripts, memory, logs, provider processing, and subprocessors.
• Define permitted verbs per tool. Prefer narrow operations such as “create draft change request” to broad shell, database, or administrative access.
• Put a deterministic policy/action broker between the model and every consequential operation.
• Use per-user or per-workload delegation with short-lived, audience-bound, least-privilege credentials. Do not reuse a powerful shared key.
• Run untrusted or cross-tenant tasks in fresh isolated environments with minimal mounts, non-root users, read-only bases, resource limits, and default-deny egress.
• Store service and session secrets in a secrets manager. Keep them out of images, prompts, logs, and shared volumes. Practice rotation.
• Require independent authentication and authorization at every MCP or internal service. A private tunnel is transport protection, not authorization.
• Test indirect prompt injection, over-broad arguments, cross-tenant retrieval, egress abuse, secrets exposure, tool-schema changes, and incident containment end to end.
• Exercise the disable-and-revoke runbook. Measure how quickly a team can stop a tool, revoke its identity, and determine the affected data and actions.

Common mistakes

• Calling the hybrid pattern “fully self-hosted.” If the model, orchestration, memory, or transcripts are hosted, describe the exact data boundary instead.
• Treating the corporate network as permission. Internal location does not authorize a tool to access every database or service.
• Passing a broad user or cloud credential into the sandbox. This converts a manipulated tool request into the maximum privilege of that credential.
• Using one long-lived shared sandbox. Files, state, tool output, and credentials can leak across sessions or trust boundaries.
• Allowing unrestricted internet egress “for convenience.” This turns a tool-enabled agent into a potential data-transmission path.
• Assuming JSON schemas or an AI security filter decide safety. They help constrain inputs but cannot replace server-side authorization, destination controls, and human approval.
• Treating an MCP tunnel as complete access control. It protects connectivity, but upstream MCP servers still need their own strong authentication and authorization.
• Logging everything without a privacy and integrity design. Raw prompts and tool outputs can themselves become a high-value sensitive-data store.

Alternatives when self-hosted execution is not enough

1. Provider-controlled sandbox with narrow external tools. Choose this when the provider's sandbox, data handling, compliance terms, and audit evidence meet the workload requirements. Keep tools read-only or narrowly scoped.
2. Hybrid execution with redaction and an action broker. This is often the best middle ground when private systems must be accessed but only a minimized result may reach the model.
3. Private inference and customer-run orchestration. Choose this when policy requires the model context and control plane to remain in a customer-approved environment. This may increase operating complexity and may change model availability or capability.
4. Non-agent workflow. For highly sensitive, regulated, or irreversible actions, use the model to draft or summarize while an ordinary deterministic workflow, with accountable human review, executes the action.

For legal, medical, financial, employment, housing, education, and child-related decisions, security architecture alone is not enough. Apply the relevant privacy, recordkeeping, validation, human-accountability, and sector-specific obligations. Do not let an agent be the final authority for a decision that requires qualified human judgment.