Managed Agent

What a managed agent is for

A managed agent is not just an AI tool that happens to run in production. It is a governed software identity, which means the organisation has to know who owns it, what it is allowed to do, and where its authority begins and ends. That framing matters because the agent’s usefulness depends on delegation, but its safety depends on control.

In practice, the term usually signals that the agent has moved beyond experimentation. A managed agent should have a defined business purpose, an accountable owner, and a lifecycle that includes approval, review, and retirement. Without those basics, the organisation may still have an agent, but it does not really have management.

Ownership, scope, and accountability

The core governance question is simple: who is responsible when the agent acts? A managed agent needs an owner who can approve changes, answer for its behaviour, and decide whether its permissions still match the work it performs. Scope is equally important, because a broad or vague remit makes it difficult to judge whether the agent is operating inside policy.

That ownership model is what separates a managed agent from an informal automation script or a loosely supervised assistant. The agent should have a clearly stated task domain, a bounded set of systems it may touch, and a review process for changes to its remit. Those controls let teams distinguish intended automation from drift, sprawl, or unauthorised use.

Where organisations are still defining their agent governance model, it helps to treat the managed agent as part of the broader AI Agent Identity Security Buyer's Guide thinking: capability, ownership, and control should be evaluated together rather than as separate afterthoughts.

Access, entitlements, and operational limits

The practical security value of a managed agent comes from limiting what it can reach. It should have reviewable entitlements, task-appropriate access, and enough restriction that a mistake does not become a broad compromise. That is especially important when the agent can call APIs, read internal data, trigger workflows, or interact with other systems.

Managed does not mean harmless. The same autonomy that makes an agent efficient can also magnify error if the scope is too broad or the permissions are inherited by default. Good governance therefore focuses on least privilege, explicit approval boundaries, and the ability to change or revoke access quickly when the task changes.

That is why the access model should be linked to the action model. A managed agent should be designed so that its authority is understandable before it is deployed, not reconstructed after an incident.

Tracing, review, and retirement

A managed agent should leave an audit trail that makes its decisions and actions reviewable. If you cannot tell what it did, when it did it, and under whose authority it acted, then the management model is incomplete. Logging, attribution, and periodic entitlement review are what turn an agent from opaque automation into something the organisation can supervise.

Lifecycle control matters as much at the end as at the beginning. Managed agents should be retired when the business need ends, when their integrations change materially, or when their access pattern no longer matches the approved use case. That is how organisations avoid stale automation, hidden privilege, and agent sprawl.

For teams building the monitoring side of that lifecycle, the AI Agent Observability, Audit and Incident Response Guide is a useful companion because it focuses on attribution, logging, and response when an agent behaves unexpectedly.

How managed agents differ from unmanaged automation

The distinction is not merely semantic. Unmanaged automation may still work, but it usually relies on implicit trust, inherited permissions, and unclear ownership. A managed agent is the opposite: it is intentionally brought into governance so the organisation can control its authority, detect misuse, and explain its behaviour to auditors, operators, and security teams.

This is why managed agent programs often become a bridge between AI adoption and identity governance. They force teams to ask the right questions about authority, access boundaries, and accountability before the agent becomes embedded in daily operations. The more capable the agent, the more important that discipline becomes.

Where identity and delegation are central to the design, the Agentic AI Identity Guide and the AI Agent Authorisation Guide both help explain how delegated authority and per-action control support a managed model.

Related resources from NHI Mgmt Group

• What is the difference between an AI agent and a managed service account?
• What is the difference between workload identity and directory-managed agent identity?
• What breaks when agent access is managed in a separate governance process?
• What is the difference between gateway-managed credentials and agent-held credentials?