Claude Managed Agents vs Hermes Agent: governance tradeoffs for teams

At a glance

What this is: This comparison contrasts a fully managed Claude runtime with a self-hosted open-source agent, and the key finding is that governance, not model preference, becomes the deciding factor at scale.

Why it matters: IAM, NHI, and platform teams need to judge whether approvals, vaulting, observability, and multi-user control can survive agent sprawl before choosing a runtime model.

Context

AI agent platform choice is now an identity governance problem as much as an engineering one. The article contrasts a managed runtime with a self-hosted runtime, and the practical gap is not just deployment style but where approvals, credentials, and monitoring live.

For teams running production agents, the important question is whether control boundaries stay intact once one agent becomes many. A managed stack can centralise some decisions, while a self-hosted stack can maximise flexibility, but both can leave governance fragmented if approvals, secrets, and audit trails are handled per agent instead of as a programme.

Key questions

Q: What breaks when AI agent governance starts at deployment instead of data?

A: Governance breaks because the system is already operating before the data, permissions, and accountability model are defined. That leaves training inputs, runtime access, and downstream actions outside enforceable controls, which is where regulatory exposure and shadow access emerge. If the lifecycle starts late, the programme is documenting risk instead of governing it.

Q: When should teams choose a managed agent runtime over self-hosted orchestration?

A: Choose a managed runtime when operational simplicity, built-in auditability, and centralised control matter more than code-level flexibility. Choose self-hosted orchestration when the organisation can reliably govern approvals, sandboxing, credentials, and observability across its own infrastructure. The decision should follow governance maturity, not developer preference.

Q: What are the signs that an agent governance programme is failing?

A: Common signals include unknown agents in staging or production, unvetted MCP connections, broad or long-lived credentials, and logs that show service-account activity without clear ownership. If the security team cannot map the agent to a tool chain and accountable owner, governance is already behind the deployment.

Q: What is the difference between managed and self-hosted AI agent governance?

A: Managed governance places runtime control, approvals, and some observability with the provider, while self-hosted governance places those responsibilities with the organisation. The practical difference is not just where the code runs. It is who must prove access control, credential lifecycle, and monitoring are working when the agent acts unexpectedly.

Technical breakdown

Managed runtime versus self-hosted runtime

Claude Managed Agents uses Anthropic's hosted execution environment, so the provider controls the infrastructure, session handling, and much of the operational surface. Hermes Agent runs on infrastructure the team owns, which means deployment, patching, scaling, and security all sit inside the organisation. That difference matters because identity controls follow the runtime boundary: session scoping, credential placement, and auditability are easier to centralise in a managed model, but self-hosting can support stronger data residency and platform flexibility if governance is disciplined.

Practical implication: Map the control boundary before deployment so approvals, logs, and credential storage do not fragment across runtimes.

Tool approvals, credentials, and model routing

Claude Managed Agents exposes a permission policy and per-user vaults, while Hermes Agent leaves policy and credential handling to whatever the team builds around it. That changes the trust model. In one case, tool use is mediated by a managed policy surface; in the other, the organisation must design the authorisation flow, the vaulting pattern, and the model access rules itself. The real technical issue is whether agent actions are governed at issuance time or deferred to ad hoc implementation choices.

Practical implication: Treat tool approvals and credential placement as architectural controls, not application details.

Observability and traceability across agent runs

Managed agent platforms can provide server-side run history and streaming telemetry, but self-hosted systems only become governable when logging, tracing, and cost attribution are built into the stack. For production use, observability is not just debugging output. It is the evidence layer for approvals, tool calls, sandboxed execution, and repeated behaviour across sessions. Without it, platform teams cannot tell whether an agent is operating inside its intended boundary or silently drifting into unmanaged access patterns.

Practical implication: Require end-to-end traces for every agent run before expanding beyond pilot use.

Threat narrative

Attacker objective: The objective is to exploit inconsistent agent governance so actions, credentials, or tool access escape central control and become harder to audit or revoke.

1. Entry occurs when an agent runtime is connected to tools, credentials, and model access without a shared governance layer across sessions or deployments.
2. Credential access or privileged action happens when per-user vaults, local secrets, or custom policy logic determine what the agent can invoke at run time.
3. Escalation appears when the same governance pattern is copied across more agents, more environments, and more users without central visibility or consistent approval control.
4. Impact is governance sprawl: teams lose reliable traceability over who authorised which action, which credential was used, and which model path executed it.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• Carbonato botnet 2026: A botnet puts a Hermes AI agent on exposed Docker hosts to steal AI API keys, SSH keys and tokens, powering the operators' own LLM gateway.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Managed simplicity and self-hosted flexibility are not the core decision points; governance placement is. The article is really about where authority sits for approvals, secrets, and observability once AI agents move into production. A managed runtime consolidates some controls, while a self-hosted runtime shifts responsibility to the organisation, but neither removes the need for a coherent identity operating model. Practitioners should evaluate the control plane before they evaluate the agent framework.

Credential governance becomes the differentiator as agent counts rise. The article makes clear that per-agent or per-session handling does not scale cleanly when many agents need the same tools. The named concept here is agent credential sprawl: once credentials are embedded in different runtimes, vaults, or local deployments, revocation and review become inconsistent by design. Teams should recognise that this is a governance architecture problem, not a storage problem.

Observability is the minimum condition for accountable agent operations. A production agent that cannot be traced across model calls, tool calls, and sandbox execution is already outside a defensible control envelope. That is true whether the runtime is managed or self-hosted. The implication is that platform teams need a programme-level view of event logging, run attribution, and policy evidence, not just application-level debugging.

Model portability changes the risk profile, but it does not eliminate vendor lock-in in governance. Hermes Agent reduces dependence on a single model provider, while Claude Managed Agents reduces operational burden through a managed stack. The deeper issue is that portability without control discipline simply moves the burden from provider dependency to internal fragmentation. Practitioners should treat multi-model flexibility as useful only when approval and credential policy remain centralised.

Multi-agent governance is now the breakpoint for enterprise adoption. The article implicitly shows that one-off agent deployments can be managed with local workarounds, but programme scale exposes the absence of common policy, shared telemetry, and consistent lifecycle control. That is where NHI-style governance begins to overlap with platform engineering. Teams should design for fleet management, not single-agent convenience.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Agent credential sprawl: once credentials are distributed across per-agent vaults, local deployments, and custom policy logic, revocation and review stop behaving like programme controls and start behaving like exception handling. That is the point where agent fleets need a governed gateway model instead of isolated runtime decisions.

Platforms that support multi-agent operations should be evaluated on whether they preserve policy consistency across model changes, runtime changes, and user boundaries. In practice, portability only matters when approvals, logging, and credential placement remain stable as the fleet grows.

For practitioners

• Define the control boundary first Map where approvals, credentials, logging, and model routing live before selecting a runtime, and make sure the same boundary works for one agent and fifty agents.
• Centralise agent credential handling Move API keys, OAuth tokens, and other tool credentials out of per-agent configurations and into a governed vaulting or gateway pattern that supports revocation and rotation.
• Require end-to-end execution traces Capture model calls, tool calls, sandbox activity, and approval events in a single audit trail so every run can be reconstructed after the fact.
• Standardise policy for multi-agent fleets Use one approval model, one logging model, and one ownership model across all agent deployments so governance does not diverge by team or runtime.
• Test portability against governance, not just code Before committing to a runtime, check whether your controls still work when the same agent moves between models, environments, and operating modes.

Key takeaways

• The article's core issue is not which agent framework looks easier to adopt, but whether governance survives once agents leave a single controlled runtime.
• Per-session vaulting, self-hosted secrets, and ad hoc policy logic all increase the chance that approvals and credential use diverge across agents.
• The practical test is simple: if the same agent can move between models or environments without breaking your approval and audit model, the architecture is ready for scale.

Key terms

• Managed Agent: A managed agent is a software identity that performs tasks on behalf of an organisation and must be governed like any other non-human identity. In practice, it needs an owner, a defined access scope, and reviewable entitlements so its actions can be traced and controlled.
• Self-Hosted Agent: An agent runtime deployed on infrastructure controlled by the organisation rather than the vendor. This gives teams more flexibility and model choice, but it also makes them responsible for access control, secrets handling, monitoring, and secure operations across the full lifecycle.
• Agent Credential Sprawl: Agent credential sprawl is the spread of API keys, OAuth tokens, and other tool credentials across multiple agents, vaults, or deployment patterns. It creates inconsistent revocation, uneven review, and a larger governance burden because the same access may be controlled differently in each runtime.
• Approval Boundaries: The policy limits that define which access requests can be approved automatically and which require human review. Strong approval boundaries prevent workflow tools from turning convenience into excessive entitlements or uncontrolled app adoption.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.