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

Why This Matters for Security Teams

Managed and self-hosted agent governance create very different accountability models. With managed services, the provider may handle some runtime guardrails, audit telemetry, and model-side controls, but the organisation still owns the risk of what data the agent can reach, which secrets it can use, and whether approvals are meaningful. With self-hosted agents, those responsibilities move fully in-house, including patching, policy enforcement, logging, and incident response.

This matters because AI agents are not static applications. They can chain tools, request new privileges, and make context-driven decisions in ways that traditional app teams do not anticipate. Guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward governance that is runtime-aware rather than assumption-based. NHIMG research on the OWASP NHI Top 10 reinforces that identity and secret handling are often the weakest link, not the model itself.

In practice, many security teams discover the gap only after an agent has already used a valid token in an unexpected workflow, rather than during design review.

How It Works in Practice

Managed governance is usually strongest at reducing operational burden. The provider may expose built-in approval workflows, content filters, usage logging, policy toggles, and platform-level abuse monitoring. That can be useful when the organisation wants faster adoption and accepts that some control decisions remain opaque. But managed does not mean outsourced responsibility. If the agent is allowed to read customer records, call internal APIs, or create tickets, the organisation still has to prove least privilege, secret hygiene, and monitoring coverage.

Self-hosted governance shifts those controls into the organisation’s own environment. That gives security teams more direct control over access governance, policy-as-code, network boundaries, logging pipelines, and retention. It also means they must manage the full identity lifecycle for the agent, including workload identity, short-lived secrets, approval gates, and revocation. For autonomous agents, current best practice is to treat identity as the control plane: issue per-task credentials, constrain them to the minimum scope, and revoke them automatically after use. That aligns with the lifecycle discipline described in NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

• Use workload identity for the agent, not shared human credentials.
• Prefer short-lived tokens over static API keys.
• Evaluate policy at request time, not only at provisioning time.
• Log tool calls, approvals, and downstream actions as separate events.
• Bind high-risk actions to explicit runtime approval or JIT elevation.

For agentic systems, the practical question is less “where is the model hosted?” and more “who can stop the agent when its intent shifts?” That is why the CSA MAESTRO agentic AI threat modelling framework emphasises lifecycle controls, trust boundaries, and execution governance. These controls tend to break down in multi-tenant SaaS environments where the provider limits telemetry access and the organisation cannot independently verify every runtime decision.

Common Variations and Edge Cases

Tighter governance often increases friction, so organisations have to balance speed against control depth. That tradeoff is especially visible when a team wants the simplicity of managed AI but also needs evidentiary control for regulated workloads, customer data, or privileged internal actions.

There is no universal standard for this yet, but current guidance suggests that managed platforms are best suited to lower-risk use cases or to front-end experimentation, while self-hosted deployments are better when the agent needs deep integration with privileged systems. A mixed model is common: keep base model inference managed, but host the orchestrator, policy engine, and secret broker internally. That lets security teams enforce their own controls while still using provider-side model capabilities. The NIST AI Risk Management Framework and NHIMG’s Analysis of Claude Code Security both support this layered approach, because governance must survive provider abstraction.

The main edge case is when an agent can act across multiple tools, identities, or environments in one workflow. In those environments, provider controls may not see the full chain of action, and self-hosted controls may not cover SaaS-to-SaaS hops unless the organisation centralises policy and telemetry. Best practice is evolving, not settled, for how much of that chain should be provider-enforced versus customer-enforced. Managed governance tends to fall short when the agent can cross trust boundaries faster than the provider’s monitoring or approval layer can keep up.

Related resources from NHI Mgmt Group

• What is the difference between human identity governance and AI agent governance?
• What is the difference between managed identities and hardcoded secrets for AI agents?
• What is the difference between governing human access and governing AI agent access?
• When should teams choose a managed agent runtime over self-hosted orchestration?