Citadel vs Saviynt for non-human identity governance is a question CIOs now ask as service accounts, API keys, cloud workloads and AI agents multiply across hybrid estates. This guide follows one illustrative service account and one illustrative AI agent through six lifecycle checkpoints: discovery, ownership, authorization, review, containment and retirement. At each checkpoint you will see what Citadel Identity360 does, the evidence a pilot should capture, and a matching request for Saviynt, so both vendors face identical tests.
The wider platform contest is covered in our seven-criterion Citadel and Saviynt head-to-head and our earlier long-form Saviynt comparison essay. This page goes deep on machines and agents only.
Vocabulary for machines, agents and MCP
- Non-human identity (NHI): A credentialed actor with no human at the keyboard, for example a workload identity, a bot, an AI agent, an API key or a service account. Our knowledge center explains how human and non-human identities differ.
- Accountable owner: The employee who justifies a machine identity, signs off its reach and decides its end date.
- MCP server: An endpoint speaking the Model Context Protocol that offers callable tools to agents. Citadel governs it as a resource with an owner, not as a principal.
- Tool-level authorization: Granting an agent specific tools on an MCP server rather than the full set it exposes.
- Orphaned identity: A machine account whose owner has left or was never recorded.
- Verified retirement: Proof that an account is gone, taken by checking the target itself rather than trusting an approved request or an attempted task.
Boundaries of this NHI comparison
In scope: the six checkpoints above, judged on what an evaluation team can observe on its own estate. That covers how machine and agent identities enter the inventory, who answers for them, how their permissions are granted, how they are certified, how a risky agent is contained, and how retirement is checked.
Out of scope: password vaults, automated key rotation, threat detection at runtime, privileged session recording, staff login policy and licensing. Evaluate those separately.
The Six NHI Tests, Scored Side by Side
| NHI checkpoint | Citadel Identity360 | Evidence to collect in the pilot | Ask Saviynt |
|---|---|---|---|
| Discovery | Agent discovery via the Google Cloud, AWS and Microsoft Entra central registries, in the platform that governs keys and service accounts | One list showing agents and service accounts together, each with its source | How are agents and service accounts shown together in one inventory? |
| Ownership | Ownership mapped when each MCP server and agent is registered; a named owner for each machine identity through its whole life | The owner recorded on a new agent at registration | What happens to a machine identity whose owner leaves the company? |
| Authorization | Per-tool grants on each registered MCP server, with OAuth plus an optional allowlist setting who may use each agent | An agent holding one tool on a server while sibling tools stay unassigned | Can we grant a single tool on one MCP server and show the rest withheld? |
| Review | Campaigns where each item carries an AI-assisted suggestion plus risk context | A pilot campaign item for a service account, and who reviews it | Who receives the review item for a service account, and what context do they see? |
| Containment | Kill switch to intervene on and contain an agent | A demonstration of the kill switch on a test agent | What containment control exists for a governed agent, and where is its use recorded? |
| Retirement | Identity graph to trace what an account reaches, then deprovisioning through connectors or RPA on applications without APIs | Your team inspects the target and finds the account gone | How is removal of a machine account confirmed on a legacy application with no API? |
| SoD and risk | Live toxic-combination monitoring plus a per-identity risk score | How an over-privileged service account shows up in the pilot | Where do conflicts on a machine account surface for the approver? |
Ask for every item in the Citadel column to be shown on your own systems during a scoped pilot. Give Saviynt each request in the same week and mark both vendors only on demonstrated results.
Checkpoint one: building a single inventory of agents and accounts
Governance starts with an accurate list. The 2025 OWASP NHI Top 10 project ranks improper offboarding of NHIs first and also lists overprivileged NHIs, and neither risk can be managed for identities nobody has counted. Citadel Identity360 discovers agents through the central registries that AWS, Microsoft Entra and Google Cloud keep, and governs them in the platform that already holds your keys, machine credentials and service accounts. Because governance of NHIs and agents is built into Citadel itself, the team running workforce IGA works with machines and agents in the same product.
Pilot evidence: discover agents from one of those central registries and show them listed beside your service accounts, each tagged with its source. Ask Saviynt: to produce that combined list too, naming each product involved.
Checkpoint two: putting a name against every service account
An unowned service account is a common audit finding. In Citadel, ownership is mapped at registration for each MCP server and agent, and API keys, service accounts and other machine identities are governed across their whole life, from first creation to final decommissioning, each with a named accountable person. The Citadel dashboard reports orphaned account exposure, meaning accounts without active owners, and dormant privileged accounts as risk signals. In the pilot, agree how an account whose owner has left should be reassigned.
Pilot evidence: register a test agent and show the owner recorded at registration. Ask Saviynt: to register that agent as well, then show where the owner is stored and how a departure is handled.
Checkpoint three: authorizing tools, not whole servers
Agents are only as safe as the tools they can call. Citadel maps an owner for each MCP server at registration, links each agent only to the servers its job requires, and grants named tools instead of a whole server. An agent that may search and read documents never inherits a delete tool just because it sits on the same server. Organisational OAuth decides who in your company can invoke an agent, and an optional allowlist narrows it to named people. Staff connect through a shared configuration using their organisational sign-in, and Citadel AI governance generates the config file that MCP clients such as Claude, OpenAI and Cursor load to reach governed services. The agent governance page walks through the access model step by step.
Pilot evidence: assign an agent two tools on a server and show the remaining tools as not assigned. Ask Saviynt: to grant a single tool on one MCP server and prove the others stay withheld.
Checkpoint four: certifying machine access with the people who own it
Machine identities need review as much as staff accounts do. In a Citadel certification campaign, every access item arrives with an AI-assisted suggestion and its risk context, and the identity graph traces the path by which access was granted and the person who signed it off, which helps a business owner make sense of a cryptic technical account. Ask for service accounts and agents to be included in the pilot campaign so you can see exactly how machine items are presented and who reviews them. Our piece on MCP tool access reviews covers how tool grants appear in a campaign.
Pilot evidence: launch a short campaign that includes one service account and one agent, and record who reviews each item. Ask Saviynt: to run an equivalent campaign and show which reviewer gets each machine item, with what supporting detail.
Checkpoint five: containing an agent that drifts
Some agent problems cannot wait for the next campaign. Citadel includes a kill switch for AI agents, so your team can intervene and contain an agent that strays from its approved purpose. Because it sits in the same platform as ownership and tool grants, the agent owner and its assigned tools are already on record. This fits the identity-first posture in the CISA zero trust maturity model, where identity is the first pillar.
Pilot evidence: have the kill switch demonstrated on a test agent and agree what record the pilot should keep. Ask Saviynt: to demonstrate its containment control for a governed agent and the record that use leaves.
Checkpoint six: retiring service accounts and checking the result
Retirement needs care. Production service accounts should not be deleted blindly, so use the Citadel identity graph to trace what the account reaches and involve its owner before decommissioning. The removal then runs through the right fulfilment path: a connector over REST, SOAP, SCIM, LDAP or JDBC, a file or batch exchange, or an RPA workflow that carries out the approved change through the screens of an application lacking any API. A completed task or RPA run does not by itself prove the resulting permissions, so check the target separately and keep the request, attempt, fulfilment and confirmation as distinct states in your evidence. Control AC-2 of NIST’s SP 800-53 catalogue covers disabling and removing accounts.
Pilot evidence: retire a test service account on your most stubborn legacy application and have your team inspect the target afterwards to confirm it is gone. Ask Saviynt: to retire that account too and show how removal on that application is confirmed.
Illustrative scenario: one agent and one service account in Citadel
The following is illustrative, not a customer result. A finance operations team builds an invoice-matching agent and registers it in Citadel with the finance systems lead as owner. Citadel authorizes two tools on the finance MCP server, read invoices and read purchase orders, and leaves the payment-approval tool unassigned. Analysts named on an allowlist receive a setup with no credentials inside. A long-standing batch service account that feeds the same ledger shows up without an active owner, is assigned to the finance systems lead and is included in the next certification campaign. When the agent later starts calling tools outside its normal pattern, the kill switch is used to contain it, and the team inspects the ledger directly to confirm the old batch account is retired. Both identities end up in one console, under one owner, with a shared record.
How Citadel treats NHI governance as part of core IGA
Citadel Identity360 handles joiner-mover-leaver, access requests, certification, SoD rules, identity risk, the machine identity lifecycle and agent governance over a single identity graph governed by shared policy. That design lets a service account, a contractor and an AI agent be traced to the resources they reach in one place. Deploy Citadel on-premises, in your own private cloud or as SaaS: Astranova handles releases for SaaS customers, while self-hosted customers decide when upgrades are applied. One Citadel plan, scoped by agreement, spans human, machine and agent identities and includes setup, hypercare and 400 customization hours, usable for NHI-specific approval logic, owner reassignment rules, reports for auditors or a connector for an in-house platform. For a longer question list, use our NHI buying checklist and the NHI governance tools guide.
FAQ: Citadel and Saviynt for machine identities
Does Citadel Identity360 govern machine identities in the same product as people?
Yes. Citadel governs keys, machine credentials, agents and service accounts alongside employees and contractors in one product, with agent discovery, MCP registration, per-tool grants and a kill switch for containing agents built in.
Where does Citadel discover AI agents from?
Discovery is scoped to the central registries run by Microsoft Entra, Google Cloud and AWS. Agents found there are governed alongside your other machine identities.
Do Claude, Cursor and OpenAI MCP clients work with tools Citadel governs?
Yes. Citadel AI governance generates a config file for those clients to load, while organisational OAuth and an optional allowlist control which staff may invoke each agent.
What happens to a service account when its owner leaves?
Citadel detects accounts without active owners as an orphaned account risk signal. Assign a new owner, include the account in certification and retire it when it is no longer needed, checking the target afterwards.
Can Citadel retire machine accounts on applications without APIs?
Yes. Beyond connectors and file or batch exchanges, Citadel can drive configured removal workflows through RPA. Check the application afterwards to confirm the account is gone.
Which tests belong in an NHI pilot of Citadel against Saviynt?
Use the six checkpoints in this guide: one discovered agent, one owner change, one per-tool grant, one machine certification item, one kill switch demonstration and one retirement checked at the target.
Put your riskiest machine identities through Citadel
Choose the service account nobody wants to touch and the agent your teams rely on most, and run them through all six checkpoints in a defined pilot. Use Request Demo to book a working session on those two identities, and watch the product walkthroughs on our videos page beforehand.