> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/3.-runtime-sandbox-and-autonomy/3.9-central-hosted-agent-runtime-hardening.md). # 3.9 Central hosted-agent runtime hardening For agents you run yourself on frameworks or cloud platforms — container isolation, egress, secrets, tool sandboxing, and audit are yours to own end-to-end. *Last reviewed: August 18, 2026* {% hint style="info" %} For agents you host, the runtime is your control plane. Own isolation, secrets, egress, logging, and kill switches before production. {% endhint %} ## What security teams need to know about central hosted-agent runtime hardening A hosted agent is an application runtime that calls models and tools. The provider may host the model, but your team usually owns the container, network policy, credentials, tool registry, retrieval systems, and logs. Treat each agent like a service with extra autonomy. It needs standard app security plus controls for tool choice, prompt injection, model calls, and human approval. ## Common central hosted-agent runtime hardening security failures * Multiple agents share the same runtime and secrets. * Outbound network access is open for convenience. * Tools run in the same process as the orchestrator. * Rate limits and spend limits are not tied to agent identity. * Logs omit prompts, retrieved context, or tool-call outcomes. ## Central hosted-agent runtime hardening security controls checklist * Authenticate inbound triggers and protect them against replay, duplication, and unauthorized scheduling. * Run each task in a tenant- and task-isolated environment; prefer an ephemeral environment for high-risk work. * Separate the control plane, orchestrator, model access, and tool execution boundaries where feasible. * Issue task-scoped, short-lived credentials through a secret broker or vault instead of injecting broad static secrets. * Deny network egress by default and own every allowed destination. * Restrict inbound access, local bindings, metadata services, management sockets, and internal network routes. * Pin and verify container images, tools, agent definitions, models, and deployment artifacts. * Set concurrency, duration, recursion, token, spend, rate, storage, and action limits per agent and environment. * Require approval or deterministic policy for actions outside the approved baseline. * Capture initiator, agent identity, version, tool, approval, target, result, spend, and termination events. * Provide a tested kill switch that stops work and revokes active credentials, sessions, queues, and downstream access. * Define quarantine, rollback, recovery, and evidence-preservation procedures before production. ## Minimum production architecture **Ingress.** Authenticate every API call, webhook, queue message, schedule, and remote dispatch. Use nonces, timestamps, idempotency keys, and narrow trigger identities where the protocol supports them. Reject stale or duplicate work. **Run boundary.** Create a distinct security context for each tenant and task. Reset or destroy state after the run unless persistence is an explicit requirement with its own access and retention controls. Do not let one task inherit another task's files, memory, browser session, network state, or credentials. **Credentials.** Resolve credentials at execution time from a broker or vault. Bind them to the task identity, tool, destination, and duration. Prevent models and untrusted tools from reading raw secret values when a mediated action can perform the operation instead. **Control plane.** Keep deployment, policy, identity, secrets, and termination controls outside the agent's writable runtime. An agent must not be able to change its own sandbox, policy, logging, budget, or kill switch. **Recovery.** Preserve the triggering request, agent and tool versions, approvals, actions, outputs, and runtime evidence before cleanup. Practice stopping active work, draining queues, revoking credentials, quarantining outputs, and restoring the previous approved version. ## Anthropic ### Overview The build-or-rent decision comes first: a Messages API loop your team hosts, or Claude Managed Agents. Managed Agents define an agent by model, system prompt, tools, MCP servers, skills, environment, session, and event history, and run in Anthropic-managed cloud sandboxes (isolated Linux containers with network access disabled by default) or self-hosted sandboxes. Credentials go through vault-based authentication rather than baked-in secrets, and multi-agent sessions pin referenced agents to versions resolved when the coordinator is created or updated, which is a real supply-chain control. Two facts gate production use: Managed Agents is in beta and requires the beta header on all requests, and sessions persist state server-side with no current zero data retention or HIPAA BAA eligibility, so regulated workloads need a different home for now. For self-built loops, the tool boundary is yours: tool definitions, descriptions, schemas, and results are part of the trust boundary, and the MCP connector's allowlist and denylist toolsets are the narrowing mechanism. Do not treat Cowork remote sessions as customer-hosted runtimes. They run in temporary Anthropic-managed sandboxes with proxy-mediated egress, and endpoint tools cannot inspect the sandbox. If a workflow needs customer-owned container, network, and evidence controls, use a self-hosted API loop or a supported self-hosted Managed Agents sandbox instead. Claude Tag is another Anthropic-hosted runtime, optimized for shared Slack work rather than a customer-built agent. Each thread receives an isolated sandbox, requests leave through Agent Proxy, and connected systems see the dedicated service account. Include it in the hosted-runtime inventory when a channel can reach production repositories, data warehouses, ticketing systems, or monitoring tools. ### Anthropic documentation * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Cloud sandbox reference](https://platform.claude.com/docs/en/managed-agents/cloud-sandboxes-reference) * [Multi-agent sessions](https://platform.claude.com/docs/en/managed-agents/multi-agent) * [Tool use with Claude](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview) * [MCP connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector) * [Using Agent Skills with the API](https://platform.claude.com/docs/en/build-with-claude/skills-guide) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) * [How Claude Tag agent identity works](https://claude.com/docs/claude-tag/concepts/agent-identity) ## OpenAI ### Overview The supported OpenAI path for self-hosted agent runtimes is the Agents SDK, which manages the agent loop, tool execution, handoffs, sessions, guardrails, approvals, and tracing, the harness features a hardening review should verify are actually configured. Agent Builder is now legacy: OpenAI has scheduled its shutdown for November 30, 2026, with published workflows exportable as Agents SDK code, so treat any Agent Builder workflow in production as a migration item with a deadline. Codex SDK and Codex-as-MCP-server extend the same review to coding agents embedded in delivery workflows. For credentials and identity, prefer workload identity federation, which exchanges external identity tokens for short-lived OpenAI access tokens through scoped service-account mappings, over long-lived API keys in the runtime, and keep staging and production in separate projects. Workspace Agents deserve a dedicated line: their access tokens are distinct from platform and Compliance API credentials, and a published agent with agent-owned connections can expose data through the builder's credentials rather than the end user's. ChatGPT Work is also vendor-hosted on web and mobile, but it is a user task surface rather than a customer-hosted application runtime. Its workspace RBAC, plugins, apps, and Work compliance evidence do not replace the isolation, secrets, egress, tracing, and kill switches required for an Agents SDK service. Desktop Work follows local Codex controls and belongs in the local runtime model instead. ### OpenAI documentation * [Agents SDK](https://developers.openai.com/api/docs/guides/agents) * [Agent Builder](https://developers.openai.com/api/docs/guides/agent-builder) * [Using tools](https://developers.openai.com/api/docs/guides/tools) * [Codex SDK](https://developers.openai.com/codex/sdk) * [Workspace Agents](https://developers.openai.com/workspace-agents) * [Workload identity federation](https://developers.openai.com/api/docs/guides/workload-identity-federation) * [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275) * [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about central hosted-agent runtime hardening ### What is a hosted-agent runtime? It is the application infrastructure that runs an agent as a service: the orchestration loop, tool registry, model calls, secrets, retrieval systems, and logs. The model may be the vendor's, but the runtime is typically yours, whether built on the Messages API or the OpenAI Agents SDK, or rented through Claude Managed Agents. Hardening it is standard service security plus agent-specific tool and injection controls. ### Who owns hosted-agent security? It is shared, and the split should be written down. The provider owns model hosting and, for managed offerings, the sandbox substrate, such as the Anthropic-managed containers behind Managed Agents. Your team owns everything it configures: tool registry, MCP server selection, credentials, egress policy, approval gates, logging, and deployment. A hardening review that cannot name an owner for each of those has found its first gap. ### Should tools run in the same process? Avoid it for risky tools. Sandboxing tool execution away from the orchestrator means a compromised or injected tool call cannot read the orchestrator's secrets or memory, and it gives containment and per-tool logging a natural seam. MCP makes the boundary explicit; the specification itself notes that tools can represent arbitrary code execution and require careful consent and authorization. ### What limits should agents have? Per agent and per environment: rate limits, spend and token ceilings, action counts, connector scopes, and network allowlists, tied to the agent's identity so a runaway or hijacked agent hits its own ceiling rather than a shared one. Limits double as detection, because a spend spike on one agent identity is one of the cheapest anomaly signals available. ### What logs matter most? Model calls, tool calls, input classification, retrieved-context identifiers, action results, agent identity, and deployment version: enough to reconstruct what the agent saw, decided, and did in a session. Version matters more than teams expect; multi-agent setups that pin referenced agent versions make "which version acted" answerable, and unpinned setups do not. ## Applicable regulations and frameworks | Governance page | Relationship to this article | | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | G.1 Map your controls to NIST AI RMF and CSF 2.0 | This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes. | | G.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports runtime monitoring, version evidence, and intervention controls. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports ICT containment, resilience, continuity, and recovery. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies and Inference Security guidance. | | G.6 Write an AI Acceptable Use Policy that holds up | This article supplies a technical or process control used to enforce the acceptable-use policy. | | G.7 Ownership and RACI for AI security | This control depends on the ownership and evidence responsibilities defined in the RACI. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA technical access, integrity, transmission, availability, and audit safeguards. | *G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.* ## Related handbook guidance * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy.md) * [3.1 What Even is an AI Sandbox?](/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox.md) * [3.3 Network egress control](/handbook/3.-runtime-sandbox-and-autonomy/3.3-network-egress-control.md) * [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity.md) * [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.harmonic.security/handbook/3.-runtime-sandbox-and-autonomy/3.9-central-hosted-agent-runtime-hardening.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.