Shortlists for NHI governance tools tend to mix products that solve different problems. A secrets vault, a cloud console, a posture scanner and an identity governance platform can all claim to handle service accounts and AI agents, yet each is built to answer a different question about those identities. This guide sorts non-human identity governance tools into the categories buyers actually meet, explains what each category is built to do, and shows why Citadel Identity360 is our lead pick for enterprises that need ownership, tool-level control and audit evidence in one product.
If you already know the category you want, our buyer checklist for NHI governance covers individual requirements, and the Citadel vs SailPoint NHI comparison goes vendor to vendor. For object-by-object guidance, see the non-human identity governance guide. This article starts earlier, with which kind of tool belongs on the list.
Five Tool Families That Claim the Machine Identity Problem
Machine and agent access shows up in five product categories, and each answers a different question.
Secrets managers and credential vaults
These tools store, issue and rotate passwords, keys and certificates so that credentials stop living in code and configuration files. They answer the question “where is this credential kept, and is it current?” Governance questions such as who owns the account behind the credential, or whether the access is still justified, belong to a different layer.
Cloud-native IAM consoles
Every major cloud ships its own console for roles, policies and workload identities. These consoles enforce access inside one provider. Hybrid estates spread service accounts across directories, databases, SaaS tenants and on-premises applications, and each provider console is built around its own slice.
NHI security and posture point tools
This newer category scans environments for exposed secrets, overprivileged machine identities and risky configurations. Larger suites are absorbing point tools too. SailPoint finalised the Entro Security deal on 29 June 2026. Its closing announcement says SailPoint customers can use Entro’s NHI and credential security products as standalone offerings, with native integration into the SailPoint platform still in progress.
Privileged access management
PAM products vault and broker high-risk administrative sessions and credentials. They matter for the most sensitive service accounts, and they sit beside governance rather than replacing it. Our explainer on how IAM, IGA and PAM divide the work maps those boundaries.
IGA platforms with NHI governance built in
The fifth family treats service accounts, API keys and AI agents as governed identities, with owners, lifecycle events, reviews, risk scoring and retirement in the same engine used for employees and contractors. Citadel Identity360 belongs here, and it is the category this guide recommends as the anchor of any NHI program.
Vocabulary for Machine and Agent Access
- Non-human identity (NHI): Any principal that is not a person, including service accounts, API clients, bots, workloads and AI agents. Our human vs non-human identities explainer sets out the contrast.
- Service account: An account created for an application, job or integration rather than a named employee.
- API key: A credential that lets a client call an interface; the key is a credential, not the identity that holds it.
- AI agent: Software that plans and takes actions through tools for people or business processes.
- MCP server: A Model Context Protocol service that exposes tools to agents. It is a governed service, not automatically an identity principal.
- Tool-level authorization: Granting an agent named tools on a server rather than every tool that server exposes.
- Accountable owner: The named person answerable for an identity across its whole life.
What This Shortlist Measures and Leaves Aside
Measured: ownership assignment and handover; inventory across hybrid sources; agent discovery from central cloud registries; MCP registration and tool-level authorization; lifecycle and dependency-aware retirement; certification campaigns and reviewer context; risk scoring and SoD; contractor offboarding and ownership handover; connector reach; audit evidence; and included customization.
Left aside: credential storage and rotation engines, runtime threat detection, privileged session brokering, model safety and prompt filtering, and licensing models. Each warrants its own evaluation track next to governance.
Scoring NHI Governance Tools on One Grid
Bring this grid to every vendor workshop. Citadel Identity360 is scored on built-in capability; the other columns name the evidence to demand and the question to put to every tool on the list.
| Criterion | Citadel Identity360 | Pilot proof to request | Question for every shortlisted tool |
|---|---|---|---|
| Accountable ownership | A named owner on every service account, API key and machine identity for its full life | An owner leaves and the identity moves to a successor with the change logged | Where is the owner of this account recorded, and what happens when that person leaves? |
| Agent discovery | Pulls agents from the Google Cloud, AWS and Microsoft Entra central registries into a single owned inventory | Agents from at least two of those registries shown with owners | Which agent registries feed your inventory today? |
| MCP and tool control | MCP servers registered with owners; each agent authorized for specific tools | An agent granted read tools while a delete tool stays unassigned | Can access be scoped below the level of a whole MCP server? |
| Agent usage | Organizational OAuth gates each agent, and an optional allowlist narrows it to chosen members | An employee outside the allowlist blocked from an agent | Who approves the staff allowed to call each agent? |
| Containment | A kill switch for AI agents, used to intervene and contain | A test agent contained with the kill switch during the pilot | How is an agent contained when it needs to be stopped? |
| Connector reach | REST and SOAP APIs, SCIM, LDAP, JDBC, SFTP, file feeds, batch, mainframe and custom builds, plus RPA for screen-only applications | A service account read from a database and one from an interface-only application | Which of our systems hosting service accounts would sit outside your reach? |
| Contractor lifecycle | Contractor sponsors and engagement windows, extension and validation steps, and offboarding | A contractor offboarded at the engagement end, with ownership of any automation they ran reassigned | What happens to bots a contractor created once the engagement ends? |
| SoD and risk scoring | Identity risk scores, SoD policy and live detection of toxic entitlement pairs | A machine identity holding a conflicting entitlement pair surfaced | Are machine identities scored with the same risk model as staff? |
| Reviews and retirement | Scheduled certification campaigns with AI-assisted recommendations and risk context for each access item; machine identities retired with an accountable owner through decommissioning | A revoked service account entitlement confirmed absent on the next read | What proves the entitlement left the target, beyond a closed ticket? |
| Customization | 400 customization hours come with the plan | Ownership workflows and reports mapped to those hours | Which tailoring work is covered, and when do extra charges begin? |
The Citadel products overview lists the full capability set.
Our Lead Pick Among the Five Families: Citadel Identity360
In Citadel Identity360, agent discovery, NHI detection and lifecycle control, and AI governance ship inside the product that already runs lifecycle, certification and SoD. Machine identities, agents and people share one identity graph, so access path discovery can trace how a service account or agent reached a sensitive resource.
Integration accounts and keys kept under a named owner
Each integration account, API key and machine identity in Citadel keeps a named owner from the day it is created until the day it is decommissioned. Ownership lives in the platform rather than in a spreadsheet, and Citadel’s risk view tracks orphaned account exposure, the accounts without active owners, so they are detected instead of drifting. Plan retirement in stages: the owning team confirms dependencies before the change is routed, and the pilot record should show separately whether each change was approved, tried, completed and then confirmed. Dependency-aware retirement beats blind deletion every time.
Some service accounts live in applications that offer no provisioning interface at all. Citadel reaches them with RPA: a file export or JDBC query supplies the account list, policy makes the call, and a configured robot carries the approved change through the application screens.
Agents, MCP servers and the tools between them
Under Citadel agent governance, each MCP server enters the registry with a named owner, every agent gets an accountable owner of its own, and each agent links only to registered servers, with individual tools authorized one by one. For the people who use those agents, Citadel generates a configuration file that MCP clients on Claude, OpenAI, Cursor and other compatible agent platforms can use to reach the governed MCP services. The file holds no secrets, so no token or key travels with it. Our post on controlling agent access over MCP walks through the policy model, and our piece on reviews of MCP tool access covers how to review those grants.
Containment when an agent steps outside policy
For an agent that must be stopped, Citadel provides a kill switch for AI agents, built for intervention and containment. Ask every shortlisted tool how it contains an agent that has stepped outside policy.
Commercial and hosting fit
A block of 400 customization hours is part of Citadel Identity360, and teams can spend it on ownership workflows, retirement approvals, reports and integration adaptations specific to their machine estate. Hosting follows your policy: run it in your own data centre, inside a private cloud, or consume it as SaaS.
Illustrative Example: An Orphaned Integration Account and a Support Agent
This scenario is illustrative and does not describe a specific customer.
- Discovery: A finance integration account appears in a nightly database read with no active owner, and a support agent appears in the AWS agent registry.
- Ownership: Orphaned-account detection flags the integration account, and the application owner adopts it; the support agent is assigned to the service desk lead.
- Authorization: The agent is connected to a knowledge MCP server and granted search and read tools, while the delete tool stays unassigned.
- Review: The owners review each grant in a scheduled certification, with risk context and an AI-assisted recommendation beside it.
- Retirement: The integration account is retired after its dependency is moved, and the next read confirms the account is disabled.
A Pilot Script for Your NHI Shortlist
- Pick five real identities: two service accounts, one API key, one agent from a cloud registry and one automation built by a contractor.
- Record each identity’s current owner, entitlements and credential location before any vendor session.
- Ask every vendor to assign owners, scope access, run a review and retire one identity using the same five.
- Score the evidence each tool produces, not the narrative in the demonstration.
- Map the workflows and reports you need to the 400 customization hours included with Citadel.
Questions to bring to each shortlisted vendor:
- Which of these five identities would your product leave without an owner?
- Can your tool authorize an agent for one tool on an MCP server and withhold another?
- How does an owner contain an agent that has stepped outside policy?
- Which records show a retired machine identity is actually gone?
- Do machine identities and agents enter the same certification campaigns as employees?
For outside reference points, OWASP’s Non-Human Identities Top 10 ranks the most common NHI risks, CISA’s Zero Trust Maturity Model treats identity as a core pillar that covers machine principals as well as people, and NIST’s AI Risk Management Framework supplies a governance vocabulary for agent programs.
NHI Tool Selection Questions Buyers Ask
Which NHI governance tools suit AI agents best?
The strongest choice is an IGA platform with NHI governance built in, because it ties each agent to an owner, specific tool grants, reviews and retirement. Citadel Identity360 leads our shortlist with agent discovery across the AWS, Google Cloud and Entra registries, MCP tool-level authorization and an AI-agent kill switch.
Is a secrets manager enough to govern service accounts?
A secrets manager keeps credentials stored and rotated. Ownership, justification, certification and retirement of the account itself need a governance platform such as Citadel Identity360 working beside the vault.
Can agents built on Claude, OpenAI or Cursor use Citadel governance?
Yes. Citadel produces a configuration file that MCP clients on those platforms load to reach governed MCP services, so tool-level grants and OAuth-gated usage still apply.
Which agent registries does Citadel discover from?
Discovery covers the central agent registries in AWS, Microsoft Entra and Google Cloud. Each agent found there lands in the Citadel inventory, where it is assigned an owner and governed like any other identity.
Are service accounts inside legacy applications in scope for Citadel?
Yes. Citadel reads accounts through connectors, databases and file exports, and uses RPA-based application integration to carry approved changes into applications administered only through their user interface.
Where does the governance layer run for an NHI program?
Citadel Identity360 can be hosted in your own data centre, in a private cloud or as SaaS, so the governance layer sits wherever your security policy places it.
Put One Ownerless Service Account in Front of Citadel
The quickest test of any NHI governance tool is an identity nobody currently claims. For a first look, the Citadel videos show the console at work; after that, bring that account, one cloud agent and the MCP servers it touches to a live session with our team. Request Demo