Claude Managed Agents vs Hermes Agent: governance tradeoffs for teams

At a glance

What this is: This is a comparison of two AI agent platforms that frame the core choice as managed runtime versus self-hosted flexibility, with governance and credential handling emerging as the decisive differences.

Why it matters: It matters because IAM, PAM, and NHI teams need controls that work across managed and self-hosted agent estates, not just within a single framework’s default assumptions.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read TruFoundry's comparison of Claude Managed Agents vs Hermes Agent

Context

Claude Managed Agents and Hermes Agent sit on opposite sides of a governance question that is becoming central to AI agent identity: do you want a hosted runtime with built-in guardrails, or a self-hosted agent stack that you must secure and operate yourself? In either case, the identity problem is not the model alone. It is how credentials, approvals, tool access, and observability are controlled once an agent can act beyond a single prompt.

For IAM and NHI programmes, the comparison matters because the actor being governed is not a human user and not a static workload in the old sense. These platforms expose different assumptions about where access lives, who can approve tool calls, and how ownership survives as deployments move from prototypes to production. That makes the choice about operating model as much as about model support.

The article reflects a typical enterprise tension: convenience versus control. That tension is now showing up in agent governance, not just application architecture.

Key questions

Q: How should security teams govern AI agents that choose tools at runtime?

A: Security teams should treat runtime tool choice as a governed access event, not a normal application call. That means task-scoped credentials, explicit approval boundaries for sensitive actions, and logs that record both the tool selected and the identity used. If the agent can change its plan, the control model must be able to change with it.

Q: Why do self-hosted AI agents increase operational risk for IAM teams?

A: Self-hosted agents shift security responsibility to the organisation, which means IAM teams must manage runtime access, credentials, logging, and updates directly. That can improve control, but only if the team has the process maturity to enforce it. Without that, flexibility turns into fragmented identity governance and weak revocation discipline.

Q: What breaks when agent credentials are stored only in the runtime environment?

A: Long-lived secrets become available to any tool path, prompt leak, or misconfigured connector that can reach the runtime. A credential broker pattern reduces that exposure by keeping raw secrets in a vault and exchanging them only when policy approves the request. The key failure is uncontrolled secret persistence, not just weak storage.

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 agent runtime versus self-hosted agent execution

Claude Managed Agents centralises runtime execution in the provider’s environment, which reduces operational burden but also narrows deployment control. Hermes Agent shifts execution onto infrastructure you own, which expands flexibility but moves security, patching, scaling, and monitoring into the customer’s responsibility. From an identity perspective, the key variable is where trust is anchored: provider-managed orchestration or customer-managed runtime boundaries. That choice determines how credentials are handled, how approvals are enforced, and how much evidence your control stack can actually collect.

Practical implication: define which side owns runtime trust, then align your approval, logging, and credential controls to that boundary.

Credential handling and per-agent tool approval in AI agent platforms

The article highlights two different patterns for tool access. Claude Managed Agents uses a permission_policy model with per-tool approval semantics and per-user vaults at session creation, while Hermes Agent leaves credential handling and policy enforcement to the implementer. These are not just implementation details. They determine whether access is centrally governed, locally improvised, or duplicated across multiple agent definitions. In NHI terms, the control issue is whether credentials are managed as reusable secrets or as governed, session-scoped access grants with auditable ownership.

Practical implication: map every external tool and secret to a named owner, approval path, and revocation process before production rollout.

Multi-model portability and observability in agent governance

Claude Managed Agents is tied to Claude models, while Hermes Agent can be pointed at multiple providers. That difference changes how teams think about portability, but it also affects observability and governance consistency. A multi-model stack is only manageable if tracing, policy enforcement, and cost attribution remain stable across execution environments. Without that, switching frameworks simply moves control gaps around. For enterprise teams, the technical question is whether the platform produces enough runtime evidence to support review, incident analysis, and policy enforcement across agents and models.

Practical implication: require end-to-end traces, cost visibility, and auditable tool events across every agent runtime before standardising on a platform.

NHI Mgmt Group analysis

The governance problem here is not agent quality, it is control placement. Claude Managed Agents and Hermes Agent show that AI agent governance can be abstracted into a managed runtime or pushed into customer-owned infrastructure, but neither model removes the need for explicit control ownership. The enterprise risk is that teams adopt a framework first and discover too late that approval, logging, and credential stewardship were never designed into the operating model. The practitioner conclusion is simple: ownership must be defined before deployment, not inferred after it.

Agent credential sprawl: emerges when per-agent or per-user tool access is treated as an implementation detail instead of a governed identity surface. The article makes clear that one model distributes credentials across per-session vaults while the other leaves secret handling to the customer. That difference matters because credential lifecycle, not model choice, determines whether access can be reviewed, rotated, and revoked consistently. The practitioner conclusion is to treat agent credentials as NHI assets with formal lifecycle controls.

Managed convenience does not equal enterprise governance. A hosted runtime reduces infrastructure work, but it does not automatically solve approval design, observability depth, or model portability. Conversely, self-hosting provides control without guaranteeing discipline. This is why agent programmes need an identity governance layer that sits above the framework choice and spans approvals, logging, and privilege boundaries. The practitioner conclusion is to evaluate control completeness, not just delivery model.

Multi-agent estates will force convergence between IAM, NHI, and agent oversight. As agents move from isolated experiments to shared enterprise services, the same controls that govern human access and workload identity must be adapted to runtime decisioning and tool use. That convergence is where current programmes will either scale or fragment. The practitioner conclusion is to build one governance model that can cover users, services, and AI agents without duplicating policy logic.

Runtime evidence will become the deciding factor in AI agent assurance. A platform that cannot produce consistent traces, approvals, and credential events across sessions cannot support durable governance, even if it is easy to deploy. The enterprise implication is that security teams will increasingly choose based on auditability and policy continuity, not just on agent capabilities. The practitioner conclusion is to make evidence generation a selection criterion, not a later integration task.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
• Start with OWASP Agentic AI Top 10 to align agent governance with the controls most likely to fail in production.

What this signals

Agent governance is moving from architecture choice to control design. Teams that treat managed versus self-hosted frameworks as a platform preference will miss the larger issue: approval, traceability, and credential stewardship need to survive framework changes. The governance model has to outlast the agent runtime, not depend on it.

Runtime evidence will determine whether agent programmes are defensible. If your platform cannot produce consistent traces for tool calls, approvals, and secret use, you do not have enough evidence for incident response or access review. That is where tools like the Analysis of Claude Code Security and broader identity controls become useful reference points.

Agent credential governance is now a lifecycle problem. The same lifecycle discipline that applies to service accounts needs to apply to agent tool access, especially where multiple teams, models, and environments are in play. The Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the right lens for turning deployment sprawl into an auditable NHI programme.

For practitioners

• Map the agent identity boundary Document where runtime execution, approval authority, and credential ownership live for each agent platform before deployment. If the platform cannot answer those questions clearly, it is not ready for production governance.
• Centralise tool credentials and revocation Treat every API key, OAuth token, and external tool secret as a governed NHI asset with a named owner, rotation path, and revocation trigger. Avoid per-agent secret copies that make offboarding impossible to verify.
• Require audit-ready agent traces Standardise on trace output that captures LLM calls, tool calls, approvals, and sandbox activity in one event stream. Use that evidence for incident review, policy validation, and access recertification.
• Test portability before standardisation Validate whether policies, approvals, and observability remain intact when an agent changes model, environment, or execution host. If governance breaks during migration, the platform is not portable in operational terms.

Key takeaways

• Claude Managed Agents and Hermes Agent represent two different control models, not just two product options.
• The hardest governance problem is credential lifecycle and approval evidence, not model selection.
• Enterprises should standardise on auditability, revocation, and ownership before they standardise on an agent framework.

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: A credential used by an AI agent to authenticate to tools, data sources, or downstream services. In practice, it should be scoped to a single task or session and never carry more authority than the agent actually needs to complete the approved action.
• Runtime evidence: Cryptographic proof collected from the environment a workload is using, such as image hashes, cloud-signed metadata, boot measurements or code signatures. It is the material a verifier checks to decide whether an identity should be trusted.

What's in the full article

TruFoundry's full article covers the implementation detail this post intentionally leaves for the source:

• The article includes a side-by-side breakdown of deployment model, model support, cost, and operational overhead.
• It shows how Claude Managed Agents handles per-session vaults and approval policy, which is useful if you are comparing runtime controls in practice.
• It explains how Hermes Agent behaves as a self-hosted runtime with persistent memory and multi-model flexibility.
• It outlines where TrueFoundry positions its own Agent Harness against both approaches for teams that need centralised governance.

👉 TruFoundry's full article covers deployment tradeoffs, governance gaps, and the Agent Harness contrast in more detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.