A Buyer's Checklist for Evaluating Non-Human Identity Governance Platforms

Most non-human identity tools can show you a dashboard of service accounts, API keys, workload identities, and AI agents. Far fewer can prove that each of those identities has an accountable owner, a justified purpose, permissions that match that purpose, and a retirement path that actually removes access. Visibility is where non-human identity governance starts. It is not where it ends.

That difference is the point of this buyer's checklist. Non-human identities (NHIs) now outnumber people in most enterprises, and they rarely leave through an HR event. A service account created for a 2019 migration, a CI/CD token with broad write access, or an AI agent wired into three MCP servers can stay active for years after anyone remembers why it exists. A platform that only finds them leaves your team with a longer list of risks and no closed loop.

Citadel Identity360, from Astranova Labs, is built to meet the full checklist below. Citadel governs non-human identities and AI agents in the same model it uses for employees and contractors: correlated inventory, ownership at registration, policy-based lifecycle, effective-access analysis through an identity graph, SoD and risk scoring, AI-assisted reviews, verified remediation, and exportable evidence. It is no-code-first, includes about 400 hours of customization along with installation, deployment, and hypercare, and connects to cloud, SaaS, on-premises, and mainframe systems through REST, SOAP, SCIM, LDAP, JDBC, flat files, SFTP, batch, and custom connectors. Use Citadel as the reference standard, and hold every other platform on your shortlist to the same proof.

The NHI governance evaluation checklist

Use this table to turn vendor claims into testable requirements. The middle column is the question every vendor must answer with a live demonstration. The right column is the standard Citadel Identity360 already meets.

Criterion	What the platform must prove	How Citadel Identity360 meets it
Inventory	Discovers and correlates service accounts, workload identities, keys, tokens, and agents across cloud, SaaS, and on-premises systems	Connector-driven aggregation and correlation across REST, SOAP, SCIM, LDAP, JDBC, file, SFTP, batch, mainframe, and custom sources, plus agent discovery from Microsoft Entra, AWS, and Google Cloud registries
Ownership	Every NHI has a named human owner, a purpose, and a review date	Ownership and purpose captured at registration; orphaned identities flagged and routed for reassignment
Lifecycle	Creation, change, rotation, and retirement are governed, not just employee offboarding	Policy-based NHI lifecycle with owner-departure triggers, expiry dates, and retirement workflows
Permissions	Shows effective access, not only assigned roles	Identity graph that traces each NHI through accounts, groups, roles, and entitlements to the resource
Monitoring	Detects unused, over-privileged, or risky NHIs	SoD and risk scoring that ranks write-capable, privileged, and cross-system grants
Reviews	Review decisions close the loop with completed revocation	AI-assisted certifications with verified remediation that rereads the target state after each change
Audit	Decisions, approvals, and changes retained as exportable evidence	Evidence export tying owner, approval, change, and verification into one record
AI-agent governance	Agents are governed, not just discovered	MCP server and agent registration, ownership, tool-level authorization, and a kill switch
Enterprise operation	Fits your operating model, connectors, and team capacity	No-code-first configuration, about 400 hours of included customization, SaaS, on-premises, or hybrid deployment

If a vendor answers any row with a roadmap slide, a partner integration still to be scoped, or "the cloud console handles that," treat the row as unmet.

Inventory is only useful when it is correlated and owned

An inventory of 40,000 service accounts is not governance. It is a backlog. The checklist question is whether the platform can correlate each NHI to the application it serves, the human or team accountable for it, and the purpose that justifies its access.

That means correlation across systems that rarely agree with each other. A cloud service account, the Kubernetes workload that uses it, the API key stored in a pipeline, and the database login it ultimately reaches are often four records in four places. A platform that cannot link them leaves reviewers guessing.

Citadel Identity360 aggregates NHIs through its connector framework and uses account correlation to tie related accounts into one governed record. Ownership is not an afterthought added after discovery. When an NHI or agent is registered, Citadel records the owner, the purpose, the environment, and the review date from the start. When discovery finds an identity with no owner, Citadel flags it as orphaned and routes it for assignment, so the inventory becomes a governed list instead of a growing pile.

What to verify in any platform:

• Discovery covers cloud, SaaS, on-premises directories, databases, and legacy or mainframe targets, not only one cloud provider
• Each NHI is linked to an accountable owner, with a workflow when that owner leaves or changes role
• Orphaned and shared identities are surfaced as findings with a remediation path, not just a count

NHI lifecycle is not employee offboarding

Employees join, move, and leave through HR. Non-human identities do not. Nobody files a termination ticket for a service account. That is why NHI lifecycle needs its own triggers: owner departure, project end, expiry dates, purpose change, and inactivity.

Retirement is also more complicated than disabling a login. Cloud platforms make this clear. In Google Cloud, disabling a single service account key stops that key, but the service account, its other keys, and its role bindings remain. Disabling the service account blocks authentication but does not by itself remove its IAM bindings. A platform that marks the identity "retired" after one of those steps is reporting a state that is not true.

Citadel Identity360 runs NHI retirement as a governed sequence: narrow or remove the underlying entitlements, disable the identity, revoke or rotate surviving credentials through the systems that enforce them, and then reread the target state to confirm access is gone. The same identity lifecycle engine that runs joiner, mover, and leaver events for employees and contractors runs these NHI events, so a contractor's departure can also trigger review of the service accounts and agents that contractor sponsored.

What to verify:

• Owner departure automatically triggers reassignment or retirement of that owner's NHIs
• Retirement removes permissions and credentials, not just a status flag
• The platform confirms completion by checking the target system, not by trusting the ticket

Policy and effective access, not just assigned roles

Assigned access is what a role definition says. Effective access is what the identity can actually reach once group nesting, inherited permissions, resource policies, and cross-account trust are combined. For NHIs, the gap between the two is often where the risk lives.

Cloud-native tools help, but they are scoped to their own platform. Google Cloud's Policy Analyzer, for example, answers access questions based on IAM allow policies within the scope you query, and it has documented limits. It does not show how the same workload identity reaches an on-premises database or a SaaS application through another path.

Citadel Identity360 builds an identity graph that links each NHI across accounts, groups, roles, and entitlements to the resource, across cloud, SaaS, on-premises, and mainframe systems. That graph is what lets Citadel apply segregation of duties and risk scoring to non-human identities, flagging, for example, an automation account that can both create a vendor record and approve payment to it, or a pipeline token with write access to production it never uses.

What to verify:

• The platform shows effective access across platforms, not just inside one cloud console
• SoD and risk policies apply to NHIs and agents, not only to people
• Over-privileged and unused grants are ranked so reviewers start with the riskiest

Monitoring and reviews must close the loop

Most NHI programs fail at the same point. A finding is raised, a reviewer clicks "revoke," a ticket is opened, and nobody checks whether the change actually happened. Months later the auditor finds the same access still active.

The checklist question is simple: after a review decision or monitoring finding, does the platform prove that access was removed?

Citadel Identity360 is built around that closed loop. AI-assisted access certifications put each NHI and agent grant in front of its owner with usage, risk, and purpose context, so reviewers decide quickly and confidently. When a reviewer revokes, Citadel executes the change through the connector, or through tracked fulfillment for disconnected applications, and then runs verified remediation: it rereads the target system and records whether the access is actually gone. A revocation is not closed until it is verified.

What to verify:

• Reviewers see why the NHI exists, who owns it, and when it was last used
• Revocations execute automatically where connectors exist and are tracked where they do not
• Completion is verified against the target state and recorded as evidence

Audit trails that outlive default log windows

Auditors do not ask whether a service account was reviewed. They ask who owned it, who approved its access, when it changed, and how you know the revocation completed. That evidence has to exist long after the event.

Default platform logs are not built for that. AWS CloudTrail Event history, for example, covers the last 90 days of management events. Longer retention requires configuring a trail to Amazon S3 or using CloudTrail Lake. Raw activity logs also do not record business ownership, approvals, or review decisions.

Citadel Identity360 keeps governance evidence as part of the workflow itself. Each NHI record ties together the owner, purpose, approval, entitlement change, review decision, and verification result, and Citadel exports that chain as audit evidence your auditors can use without stitching together screenshots from five consoles. See how this supports audit readiness across frameworks.

What to verify:

• Evidence links ownership, approval, change, and verification for each NHI
• Retention is governed by your policy, not a platform's default window
• Evidence can be exported per identity, per application, and per review campaign

AI agents need governance, not just discovery

AI agents are the fastest-growing class of non-human identity, and they extend the access path. The question is no longer only "what can this account reach." It is "which agent can invoke which tool, through which MCP server, on whose behalf, and how do we stop it."

Cloud providers are adding agent identity features. Microsoft Entra, for example, now provides agent identities and lets organizations assign access to agents through access packages. That is useful plumbing, but on its own it does not decide whether an agent should exist, who sponsors it, which MCP tools it may call, or what happens when its sponsor leaves.

Practical MCP questions every platform must answer:

• Is every MCP server and agent registered with an accountable owner before use?
• Is authorization granted at the level of individual tools, or only whole servers?
• Who may use each agent, and how is that enforced?
• What happens when a server adds a new tool?
• How fast can access be stopped when an agent misbehaves?

Citadel Identity360 answers each of these in one model. Citadel registers MCP servers and AI agents with ownership mapped at registration, authorizes each agent at the level of individual tools, controls which people may use each agent, and keeps a kill switch ready to revoke an agent's access immediately. Citadel also discovers agents from the central registries of Microsoft Entra, AWS, and Google Cloud and pulls them into the same governed inventory. Citadel produces an MCP access configuration file that platforms such as Claude, OpenAI, and Cursor can use for governed MCP access, so agent tool access flows through Citadel registration, ownership, and tool-level policy rather than shared secrets.

The platform has to fit your operating model

A strong feature list fails if your team cannot run it. NHI governance touches cloud engineering, platform teams, application owners, security operations, and audit. The platform has to work with the systems you already have and the people who already own them.

Check four things:

• Connector breadth. NHIs live in cloud IAM, Kubernetes, CI/CD, databases, directories, SaaS, and mainframes. Citadel connects through REST, SOAP, SCIM, LDAP, JDBC, flat files, SFTP, batch, mainframe, and custom connectors, so legacy targets are governed rather than excluded.
• Configuration effort. Citadel is no-code-first, so policies, workflows, and reviews are configured rather than coded.
• Included services. Citadel includes about 400 hours of customization along with installation, deployment, and hypercare, so organization-specific NHI policies are delivered in scope rather than as a separate services project.
• Deployment model. Citadel runs as SaaS, on-premises, or hybrid, which matters when NHIs sit in regulated or isolated environments.

A proof-of-concept test plan for NHI governance

Do not accept a slide-based demo. Use real identities from your estate and run each scenario end to end. Citadel Identity360 is designed to complete every step below in one trace:

1. Discover and correlate. Connect one cloud account, one on-premises directory or database, and one SaaS application. Show the correlated NHI inventory and the orphaned identities.
2. Assign ownership. Register a new service account and an AI agent with owner, purpose, and review date. Show what happens to an orphaned identity.
3. Trace effective access. Pick one high-risk workload identity and show its full path to a sensitive resource through the identity graph.
4. Apply SoD and risk. Show an NHI with a toxic combination or excess privilege flagged and ranked.
5. Review and revoke. Run a certification on a set of NHIs, revoke one grant, and show verified remediation against the target system.
6. Owner departure. Simulate the sponsor leaving and show reassignment or retirement of that sponsor's NHIs and agents.
7. Govern an agent. Register an MCP server, authorize one agent for specific tools, show a denied tool call, then hit the kill switch and show access stops.
8. Export evidence. Export the full chain of ownership, approval, change, and verification for one NHI.

Any platform that cannot run all eight against real identities is giving you visibility, not governance.

Citadel Identity360: the reference platform for this checklist

Citadel Identity360 does not treat non-human identity governance as a separate dashboard bolted onto an IGA suite. It applies the same governed lifecycle to service accounts, workload identities, API credentials, and AI agents that it applies to employees and contractors, and it closes the loop on every decision.

• Ownership at registration. Every NHI and agent enters Citadel with an owner, a purpose, and a review date, and orphaned identities are routed for assignment.
• Identity graph. Effective access is traced across cloud, SaaS, on-premises, and mainframe systems, so reviewers see real reach, not role names.
• SoD and risk scoring. Toxic combinations and excess privilege are flagged for NHIs and agents, not only for people.
• Verified remediation. Revocations are executed and then confirmed against the target system before they are closed.
• Agent governance. MCP server and agent registration, tool-level authorization, controlled human use, and a kill switch, with an MCP access configuration file that platforms such as Claude, OpenAI, and Cursor can use for governed MCP access.
• Evidence export. Ownership, approval, change, and verification are exported as one auditable chain.
• Enterprise fit. No-code-first configuration, about 400 hours of included customization with installation, deployment, and hypercare, broad connectors, and SaaS, on-premises, or hybrid deployment.

The best way to see it is with your own identities. Book a Citadel Identity360 demonstration and bring real service accounts, workloads, and agents. Astranova Labs will run the eight-step test plan above and show the closed loop from discovery to verified revocation and exported evidence.

FAQ

What is the difference between NHI discovery and NHI governance?

Discovery tells you which non-human identities exist. Governance proves each one has an owner, a justified purpose, appropriate permissions, a lifecycle, and a verified retirement path, with evidence. Citadel Identity360 covers both, from correlated inventory to verified remediation and evidence export.

Why can't we govern NHIs with our employee offboarding process?

NHIs do not leave through HR. They need their own triggers, such as owner departure, project end, expiry, and inactivity, and retirement must remove permissions and credentials, not just disable a login. Citadel runs NHI lifecycle events in the same engine as joiner, mover, and leaver events, with NHI-specific triggers.

Are cloud-native tools enough for NHI governance?

They are valuable inside their own platform, but they are scoped to it. Access analysis, log retention, and agent identity features each cover part of the problem. Citadel Identity360 connects those sources into one identity graph and adds ownership, reviews, verified remediation, and long-lived evidence across cloud, SaaS, on-premises, and mainframe systems.

How should AI agents be governed?

As non-human identities with their own lifecycle. Register each MCP server and agent with an owner, authorize at the level of individual tools, control which people may use each agent, review grants on a schedule, and keep a kill switch ready. Citadel does all of this and produces an MCP access configuration file that platforms such as Claude, OpenAI, and Cursor can use for governed MCP access.

What should we test first in an NHI governance proof of concept?

Start with one high-risk workload identity. Trace its effective access, confirm its owner, revoke an unneeded grant, verify the change in the target system, and export the evidence. Then add an AI agent with tool-level authorization and the kill switch. Citadel Identity360 runs that full sequence in one trace.