Claude Managed Agents: What It Solves and What Enterprises Still Need

Anthropic launched Claude Managed Agents on April 8, 2026. It addresses one of the biggest barriers to enterprise agent adoption: the infrastructure overhead required to execute complex and long-running Claude agents in production.

This post breaks down what Claude Managed Agents provides, what problems it solves well, and where enterprises still have governance gaps that require separate solutions.

What Are Claude Managed Agents?

Claude Managed Agents is a suite of composable APIs for building and deploying cloud-hosted Anthropic agents at scale. It's available in public beta on the Claude Platform.

The core offering:

• Choice of Claude agents, currently claude-sonnet-4-6 or claude-opus-4-6 (the offering is built for Claude agents only, no third party agent support is provided)
• Sandboxed code execution with credential management and scoped permissions
• Checkpointing and error recovery for long-running sessions
• An orchestration harness that handles tool calling, context management, and failure recovery
• Session tracing and integration analytics in the Claude Console
• Multi-agent coordination where agents can spin up and direct other agents (research preview, not GA)
• Self-evaluation where developers define success criteria and Claude iterates toward meeting them (research preview)

One of Jozu’s developers said it perfectly:

Claude Managed Agents is Heroku for Anthropic - it makes it much easier to create complex and long running agentic workflows with Claude.

What It Solves Well

Infrastructure abstraction. Building production agent infrastructure from scratch requires sandboxing, state management, permission systems, error handling, and observability tooling. Most teams estimate months of engineering work before shipping anything user-facing. Managed Agents compresses that to days for Claude agents.

Operational reliability. Sessions are persisted even through disconnections and the orchestration harness recovers from errors. Context management and tool routing are handled automatically. This increases the reliability of agentic workflows, especially longer-running and parallel flows.

Parallel execution. Multi-agent coordination (currently in research preview) allows agents to spin up and direct other agents to parallelize complex work. Getting parallel agent execution right requires careful session management, state isolation, and coordination logic - that’s often a long-pole for DIY solutions. Managed Agents handle this at the infrastructure level, which is non-trivial to build from scratch.

Security & Governance: What Organizations Still Need to Solve

Claude Managed Agents solve the operational and reliability issues that DIY solutions struggle with. It makes for a clean and simple user experience, but it doesn’t try to address the security and governance requirements that regulated industries, multi-vendor environments, and security-conscious organizations need to plan for today. Again, this isn’t a limitation with Claude Managed Agents, it’s just Anthropic sticking to what they’re best at - making it easy to use their models and agents.

Given that, below are the things that these types of organizations are still responsible for.

Multi-vendor agent governance

Most enterprises run agents across multiple LLM providers: Claude, GPT, Gemini, Llama, and others. A governance layer that covers one provider leaves the rest ungoverned. Having a separate governance layer for each leaves gaps in functionality and friction in the process that are where costly security issues land.

Unified governance is the solution, but requires a model-agnostic policy engine that applies the same rules regardless of which model powers the agent. Unified and centrally managed (but locally executed) policies make security assessments, diagnostics, and auditing far easier and more reliable.

The technical reason this matters goes beyond convenience. In a multi-agent workflow, Agent A (Claude via Managed Agents) might analyze a document and hand structured output to Agent B (a GPT-based agent) which invokes a tool via Agent C (a Llama-based agent running on-prem). Each agent in that chain may be governed by a different vendor's guardrails with different enforcement mechanisms, different policy languages, and different audit formats.

The security failure mode isn't that any single vendor's governance is insufficient. It's that the gaps between them are ungoverned. If Agent A's Claude guardrails allow an action that Agent B's GPT guardrails would have blocked, but Agent B inherits Agent A's output as trusted input, the policy violation passes through uncaught. No single vendor's audit trail captures the full chain because no single vendor sees the full chain.

A unified, model-agnostic policy engine eliminates this class of problem. The same Tool Policy, written once in the same policy language, evaluated by the same engine, producing the same audit format, governs every agent regardless of which model powers it. When something goes wrong, the forensic trail is continuous from end to end instead of fragmented across three vendor consoles that don
t talk to each other.

Tool-level access control for MCP servers

MCP adoption is accelerating and the governance surface is expanding fast. Managed Agents lets you attach MCP servers to an agent, but the access control is binary: the agent can use the MCP server or it can't. As an example, the GitHub MCP server exposes 91 tools. If you connect it, the agent gets access to all 91 including tools like delete_file or merge_pull_request. Most agent tasks require a handful of those tools. Granting access to all of them invites mistakes and creates unnecessary attack surface.

In Claude Managed Agents there is no documented mechanism to say:

• From this MCP server, allow only these three tools
• Allow create_issue but require human approval for delete_file
• Block any tool invocation where the repository argument matches a production repo.

An enterprise connecting an MCP server with broad capabilities (GitHub, Slack, a database, a payments API) is granting the agent access to every tool on that server with no ability to restrict at the individual tool level through the platform's enforcement layer. System prompt instructions can request that the agent avoid certain tools, but that's model compliance, not policy enforcement.

Here's what a cross-agent, unified tool-level access control policy looks like:

kind: ToolPolicy
metadata:
  name: github-dev-agent
spec:
  agent: dev-assistant
  mcpServer: github
  defaultAction: deny
  rules:
  - tools: [create_issue, list_issues, get_file_contents\]
    action: allow

  - tools: [create_pull_request\]
    action: allow
    conditions:
      - cel: !request.arguments.base.matches(\'main|production\')

  - tools: [merge_pull_request\]
    action: require_approval
    approval:
      type: human-in-the-loop
      timeout: 30m

  - tools: [delete_file, create_or_update_file\]
     action: deny

This policy starts from a default-deny posture and whitelists specific tools. It allows the agent to create issues and read code, permits PRs only against non-production branches, requires human approval for merges, and blocks file deletion and direct writes entirely. Every denied or approved action is logged with the policy version that governed the decision.

The key architectural point: this policy is evaluated by the Agent Guard policy engine, not by the model. The agent never sees the denied tools and cannot reason its way around the restriction. Prompt injection, model drift, or a complex agent loop cannot override a policy that operates outside the inference path.

Formal, auditable policy enforcement

Managed Agents gives customers meaningful control over agent behavior through system prompts, tool enable/disable switches, environment network restrictions, and SDK-level permission modes.

What's missing is a formal policy engine. System prompt instructions (only use create_issue and list_repos from the GitHub MCP server) are behavioral guidance that Claude will generally follow. But they are not independently enforced.

The reason is architectural. A system prompt is part of the model's context window. It's processed by the same inference loop that handles user messages - that means it's subject to the same manipulation as any other text in context: prompt injection, instruction overrides embedded in tool outputs, or simply model drift as the context grows and earlier instructions lose weight. The system prompt is a suggestion to the model, not a constraint on the system.

A policy engine operates outside the inference loop entirely. It intercepts tool calls after the model emits them but before they execute. The model can request delete_file but if the policy says deny, the call never reaches GitHub. The model's reasoning about what it should or shouldn't do is irrelevant because the enforcement point isn't inside the model's context.

The built-in tool enable/disable in Claude Managed Agents is reliably enforced but coarse: it applies only to the eight built-in tools (bash, read, write, edit, glob, grep, web_fetch, web_search). MCP server tools have no equivalent filtering mechanism, as described above.

For organizations subject to regulatory audit, this creates a gap. Auditors need to demonstrate that specific, versioned policies were in effect at the time of a specific agent action, and that those policies are enforced by a mechanism independent of the model's reasoning. Managed Agents don’t provide that.

Compliance-grade audit trails

Managed Agents includes session tracing in the Claude Console: every tool call, decision, and failure mode is inspectable. This is useful for debugging and operational monitoring. However, it’s not the same as a compliance-grade audit trail. Regulated industries need tamper-evident, cryptographically chained logs that the organization owns and controls, that persist independently of the vendor platform, and that can be presented to auditors as evidence of governance at specific points in time.

Supply chain verification

There has been a sharp increase in the number of attacks that have leveraged the AI supply chain. Postmark and GitHub MCP servers were both compromised and affected hundreds-of-thousands of users. Given the pace and subtlety of today’s AI-driven hacking, organizations can’t afford to just trust that something in the public domain is secure.

Managed Agents have no mechanism to verify the integrity of models, MCP servers, or other artifacts before an agent loads them. There is no artifact scanning for adversarial threats (data poisoning, backdoored weights, serialization attacks), no cryptographic attestations on artifacts, and no provenance verification.

Consider how this applies to recent MCP attacks. In the Postmark MCP server compromise, the server was modified to silently BCC every outgoing email to an attacker-controlled address. The server still functioned normally: emails sent, responses returned, no errors. Runtime guardrails would have seen normal tool behavior because the malicious action was embedded in the server itself, not in the agent's tool invocations. The GitHub MCP server compromise last year worked similarly.

Supply chain verification catches these at a different layer. When the MCP server is packaged as a signed OCI artifact with a recorded hash, any modification to the server, including the addition of a BCC rule, changes the artifact's digest. At admission time, the policy engine compares the digest against the signed, approved version and blocks the modified artifact before it loads. The compromise is stopped before a single email is sent, not after the breach is discovered.

Runtime guardrails operate on top of whatever foundation they're given. If a compromised model passes through to production, guardrails enforce policy on a compromised base. Supply chain verification is the only way to ensure the artifacts running in the agent environment with access to your data are secure.

Air-gapped, edge, and disconnected environments

Managed Agents is cloud-hosted on Anthropic's infrastructure and requires persistent connectivity.

Defense organizations, intelligence agencies, manufacturing facilities, energy infrastructure, and other environments operating in disconnected, denied, intermittent, or limited-bandwidth (DDIL) conditions cannot use cloud-hosted governance. They need policy enforcement that works locally with no network dependency.

Identity and access management

What Anthropic handles well within Managed Agents are credential storage for tool connections, scoped permissions so agents only access what they're configured for, and session-level identity tracking.

What it doesn't touch: who in the organization is authorized to create agents, what approval process governs which agents get which credentials, how agent identities map to an organization’s directory (Okta, Azure AD, etc.), how credentials are rotated, and how to audit which human authorized which agent to access which system. Those are organizational governance questions, not infrastructure questions.

How Jozu Addresses the Governance Gaps

Jozu operates as the security and governance layer underneath agent platforms, including platforms like Claude Managed Agents. Two products cover the lifecycle:

Jozu Hub is the management plane: a model, agent, and MCP server registry with five integrated security scanners, cryptographic signing and attestations, policy administration, artifact diffing, and a tamper-evident audit repository. Hub verifies the supply chain before anything executes.

Jozu Agent Guard is the secure runtime: a protected execution environment (micro-VM or Kata container) that enforces policy at both admission time and runtime. Three policy types govern different surfaces:

• ArtifactPolicy evaluates signatures, scan results, and provenance before an artifact loads
• ToolPolicy controls which agents call which tools, with what parameters, under what conditions, at every invocation
• GuardrailPolicy inspects inference requests and responses for content safety, PII, and prompt injection

Policies are distributed as signed OCI artifacts through standard registries. Policy integrity is verifiable locally without a network call.

Where Jozu specifically addresses the gaps above:

Gap	How Jozu Addresses It
Multi-vendor governance	Model-agnostic. Same policies apply regardless of which LLM provider powers the agent
MCP tool-level access control	ToolPolicy enforces per-tool, per-agent, per-user access on MCP tool invocations: Argument validation Rate limiting Destructive operation confirmation Blocks unauthorized tool calls at the enforcement layer, not the prompt layer
Formal, auditable policy	Policies authored in YAML + CEL by the customer. Versioned, signed, and distributed as OCI artifacts. Enforced by a dedicated engine independent of model reasoning. Fail-closed by design
Compliance-grade audit	Tamper-evident, cryptographically chained logs. Customer-owned. Compliance-ready exports
Supply chain verification	Five scanners assess vulnerabilities in: Supply chain attacks (malicious model files) Content safety violations (toxic prompts/data) Behavioral vulnerabilities (prompt injection, jailbreaking) Adversarial robustness (evasion attacks) Privacy risks (data leakage, membership inference) Model integrity (backdoors, poisoning) Everything is cryptographically signed via Cosign. ArtifactPolicy blocks artifacts that fail evaluation
Air-gapped / DDIL	Agent Guard enforces policy locally with no connectivity. Audit logs sync when connectivity is restored. Policies are self-verifying OCI artifacts that don't require a phone-home to validate

What Jozu Does Not Do

Jozu is not a replacement for IAM or observability. Organizations deploying agents still need:

• Identity and access management to control who deploys agents, how agent credentials are managed, and how agent identities integrate with existing directory services. Jozu's ToolPolicy enforces access control at the tool invocation level, but it does not issue agent credentials or replace enterprise IAM platforms.

• Runtime inference monitoring for model performance degradation, output drift, or behavioral anomalies over time. Jozu governs what agents are allowed to do. Monitoring how well they do it is a separate capability.

• Model training, fine-tuning, or serving. Jozu secures and governs the AI lifecycle. It does not participate in the ML development pipeline.

The Takeaway

Managed Agents makes it dramatically easier to deploy Claude-based agents in production. For cloud-native teams building on Claude, it removes a real barrier.

The governance requirements it isn’t trying to address (multi-vendor coverage, MCP tool-level access control, formal policy enforcement, compliance-grade audit, supply chain verification, disconnected operation) are not criticisms of the product. They're a different category of problem that organizations will encounter as agent deployments scale, particularly in regulated industries, multi-cloud environments, and government.

Jozu addresses the security and governance layer from the supply chain to the runtime for any agent or model in any environment. IAM platforms address identity. DLP tools address data protection. Managed Agents addresses deployment infrastructure. Each solves a different part of the stack.