TL;DR: Claude Managed Agents and Vercel eve solve the same production problem in very different ways: one centralises runtime control, the other shifts ownership to the development team, according to TruFoundry. For IAM and NHI practitioners, the real question is whether governance, approvals, credential control, and observability are explicit controls or left to surrounding infrastructure.
At a glance
What this is: This comparison explains how Claude Managed Agents and Vercel eve split responsibility for AI agent runtime, with governance, approvals, observability, and credential handling landing differently across the two models.
Why it matters: It matters because IAM, PAM, and NHI teams must decide where control lives when agent execution, tool use, and approvals move into production workflows.
Context
AI agent platforms now differ less on model access and more on who owns the runtime, the approvals, and the audit trail. In practice, that shifts the governance question from “can we build it?” to “which control plane is responsible when the agent uses tools, credentials, and external services?”
Claude Managed Agents and Vercel eve represent two opposite operating models for AI agents. One centralises execution in a managed service, while the other makes the application team own the runtime and the surrounding infrastructure. That difference matters for enterprise identity governance because the control boundary changes even when the user-facing outcome looks similar.
Key questions
Q: What should security teams do first when choosing an AI agent runtime?
A: Start by defining where approvals, credential brokerage, and sandboxing will be enforced. If those controls live only in application code, the team owns the full operating burden. If they live in a managed platform, verify the platform exposes audit events, revocation paths, and connector policy you can actually govern.
Q: Why do AI agents create governance problems that normal access reviews miss?
A: AI agents can read, copy, transform, and re-share data after the original access decision, so a static review of entitlements does not capture downstream impact. Governance has to measure what the agent actually did with the data, not only whether the agent was allowed to see it. That is why lineage and activity evidence matter.
Q: How do teams know whether agent observability is good enough for audit and response?
A: Look for logs that preserve who approved the action, which tool was invoked, which connector or secret was used, and how the session progressed. If the trace only shows model tokens or generic runtime events, it may help debugging but not accountability.
Q: How should organisations compare managed and self-hosted AI agent platforms?
A: Compare them by control ownership, not by interface polish. Managed platforms reduce operational burden but concentrate trust in the provider. Self-hosted platforms increase flexibility but require the organisation to design approvals, network restrictions, and credential handling itself.
Technical breakdown
Managed runtime versus self-hosted agent ownership
Claude Managed Agents places the agent loop, sandbox, and session lifecycle under the provider’s runtime, while Vercel eve treats the repository, files, and deployment environment as the agent itself. That architectural split changes where controls such as approvals, logging, and network restriction are enforced. In the managed model, governance is concentrated in platform defaults and APIs. In the self-hosted model, those controls must be designed into the application stack and deployment pipeline.
Practical implication: decide whether your governance team can rely on platform-enforced boundaries or must enforce them in your own runtime and deployment controls.
Credential brokerage and MCP server control
The article contrasts vault-backed, per-user credential handling and centralized MCP credential management with more developer-owned integration patterns. For AI agents, the critical issue is not simply access to tools, but who brokers the secret, how approval is checked, and whether the model ever sees the credential material. That makes MCP gateway design an identity control point, not just an integration layer. Once agents can call external tools, credential scope and broker policy become part of the trust model.
Practical implication: place credential brokerage, approval policy, and connector governance under a control point you can audit and revoke cleanly.
Observability and auditability in agent execution
The article shows two observability patterns: built-in runtime tracing versus OpenTelemetry export into external platforms. Both are useful, but they are not equivalent for governance. Trace data only helps when it records tool calls, session state, approval events, and identity context in a way that supports review. For enterprise AI agent operations, the gap is often not logging volume but whether the logs are tied to a durable identity and policy story across sessions and tools.
Practical implication: verify that agent telemetry preserves approval, tool-use, and session identity details needed for audit and incident review.
Threat narrative
Attacker objective: The objective is to exploit the agent’s legitimate runtime access to reach tools, data, or actions that were never meant to be broadly or persistently available.
- Entry begins when an AI agent is given production access to tools, sandboxes, and external connectors as part of normal deployment.
- Credential exposure risk appears if the agent runtime can reach MCP servers or APIs without a central broker enforcing per-call approvals and scoped credentials.
- Escalation happens when the agent is allowed to execute tasks, write outputs, and retain state across sessions without a corresponding governance trail.
- Impact is operational rather than purely technical: a misgoverned agent can act with legitimate access at scale, making misuse harder to detect and unwind.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
- 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.
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
AI agent governance now depends on where runtime authority sits, not just which model is in use. The article’s central distinction is architectural, but the security consequence is governance placement: if the platform owns the loop, policy can live there, and if the team owns the loop, so does the control burden. That means enterprise AI risk is increasingly a control-plane question rather than a model-selection question. Practitioners should evaluate who can approve, observe, and revoke agent actions before deployment.
Credential brokerage has become the real identity boundary for agentic systems. The article repeatedly shows that MCP servers, connectors, and vault-backed access are not secondary implementation details. They are the points where identity, authorization, and tool execution intersect. Tool broker boundary: the practical unit of control is no longer the agent alone, but the broker that decides which credentials, approvals, and scopes reach that agent. Teams should treat that boundary as a first-class governance object.
Managed and self-hosted agent runtimes create different accountability models, but neither removes accountability. A hosted runtime concentrates responsibility in the provider, while a self-managed runtime pushes it into the application team and infrastructure stack. That changes audit evidence, incident response ownership, and change control expectations. The conclusion is not that one model is safer by default, but that the accountability chain must be explicit before the first production workflow goes live.
Observability is only governance when it is identity-aware. Traces, spans, and session logs are useful, but only if they preserve approval events, tool calls, and the session identity behind each action. Without that, teams get telemetry without decision context. For AI agents, the governance question is whether the log can answer who authorised the action, what identity acted, and which connector or secret was used.
Open-source flexibility increases governance optionality, but it also increases policy design risk. Vercel eve’s filesystem-first approach makes agent behaviour diffable and portable, which is operationally attractive. But that same flexibility means approvals, egress controls, and runtime restrictions are design decisions, not inherited protections. Practitioners should assume that more control at build time also means more responsibility at run time.
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 Authorisation Guide
What this signals
Identity-aware control points will matter more than model choice as agent adoption grows. Security teams should expect more scrutiny on where approvals are enforced, how credentials are brokered, and whether session telemetry can reconstruct agent decisions. The governance conversation is moving from model capability to control placement.
Tool broker boundary: the next operational question is not whether an agent can call tools, but which system is allowed to hand those tools credentials and policy context. That boundary will increasingly define whether agent platforms are governable in enterprise environments.
For practitioners
- Define the agent control boundary Map whether approvals, sandboxing, and credential brokerage live in the platform, the application stack, or both before production rollout.
- Centralise MCP credential governance Treat MCP servers and connectors as governed access paths, with per-call approval policy and revocation points that can be audited.
- Require identity-aware telemetry Make sure session logs retain tool calls, approval events, and the identity context needed to reconstruct agent actions after an incident.
- Separate runtime choice from governance choice Evaluate managed and self-hosted agent models independently from security controls so that convenience does not hide missing governance capabilities.
Key takeaways
- Agent platforms are diverging on who owns runtime control, and that ownership decision changes where governance must live.
- Credential brokerage, approvals, and audit logging are the practical identity controls that separate manageable agent deployments from opaque ones.
- Enterprises should evaluate AI agent platforms by control placement, not by model support alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent runtimes concentrate identity and privilege decisions in tool execution paths. |
| ASI02 — Tool Misuse | The article focuses on how agents use tools, connectors, and MCP servers in production. | |
| Recommendation — Enforce scoped approvals and privilege boundaries for every agent tool invocation. Restrict tool reach and require approval for high-risk agent actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Managed connectors and MCP credentials are the trust boundary for agent access. |
| NHI-05 — Overprivileged NHI | AI agents can accumulate access beyond their task scope if governance is weak. | |
| Recommendation — Broker credentials centrally and prevent direct model access to secrets. Map each agent to least-privilege scopes and revoke excess access paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about who may approve and execute agent actions. |
| Recommendation — Align agent permissions and approvals to explicitly governed authorisation rules. | ||
Key terms
- Agent Runtime: The agent runtime is the execution environment where an AI agent reads data, calls tools, and carries out actions. It matters because the runtime is where identity, policy, and filesystem boundaries either hold or fail. If those boundaries are weak, the agent becomes a high-privilege path into the environment.
- Credential Broker: A credential broker is a control layer that releases credentials, tokens, or federated access only after verifying the requester and the request context. It reduces secret copying by shifting access from static distribution to point-of-use delivery, which improves auditability and narrows exposure windows.
- Session-level telemetry: Security data captured from inside the browser session, such as logins, clipboard events, file transfers, extension changes, and OAuth consents. It is more useful than alert-only reporting because it preserves the context needed to explain how identity and data risks developed.
- MCP credential: An MCP credential is the authentication material used by a client, agent, or tool to access a Model Context Protocol server or connected resource. In practice, it may be an API key, token, certificate, or delegated identity. It should be scoped, revocable, and tied to the minimum permissions needed for the interaction.
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.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org