If you are running identity governance across a hybrid multi-cloud enterprise, the real problem is not whether people or machines need access. It is whether you can maintain one accountable view of who or what can reach each resource—then govern that access with the right lifecycle, policy, and review controls for each identity type.
That is the case for a shared identity governance and administration (IGA) model. You need one governance record that relates employees, contractors, service accounts, cloud workloads, API identities, and AI agents to the resources they touch, while still allowing different authentication methods, lifecycle triggers, and enforcement systems behind the scenes. Done well, this gives you faster employee access, accountable machine access, and a cleaner audit trail—without separate, contradictory programs.
Citadel Identity360, from Astranova Labs, is built as that shared control plane. Its identity graph connects workforce and non-human identities to entitlements, ownership, approvals, and risk signals so the same governance model covers joiner–mover–leaver automation, contractor lifecycle, NHI ownership, SoD checks, and AI agent / MCP registration—administered no-code-first, with broad connectors and included customization for the systems enterprises actually run.
Start with one inventory of identities and access paths
You cannot govern what you cannot see. The first step is a normalized inventory that combines workforce records, cloud principals, application registrations, service accounts, workload identities, and agent-to-tool relationships into one governance view.
For human identity, pull from the authoritative people source and include joining, transfer, and departure events. For non-human identities, collect groups, service principals, managed identities, workload principals, roles, resource permissions, and activity from directories, cloud services, and material SaaS or on-premises applications. Preserve each system’s native ID and also assign a stable governance ID so similarly named accounts are not conflated.
Your minimum record should include:
- Identity type and native ID
- Source system and environment
- Business purpose
- Accountable owner and backup or owning team
- Application, workload, or sponsoring person
- Resource and effective entitlement
- Privilege or data sensitivity
- Creation and last-use information when available
- Authentication mechanism and credential reference
- Approval and review history
- State
- Expiration or next-review trigger
Do not confuse an identity with a credential. A key or token authenticates an identity, but it is not the same object as the identity itself. Inventory both, but do not copy secrets into the IGA record.
This inventory should also expose indirect access: group membership, assumed roles, impersonation, third-party grants, and access inherited across projects or accounts. In practice, this is where a people-only review misses the real risk—an employee may lose direct database access but still control an automation identity that can reach the same data.
Citadel Identity360’s identity graph is designed for exactly that dual view. Broad connectors—REST, SOAP, SCIM, LDAP, JDBC, files, SFTP, batch, mainframe, and custom—bring workforce and technical sources into one model so you can relate an employee’s entitlements and a workload that employee’s team controls to the same sensitive resource. A useful readiness test is simple: if you cannot trace both paths, the inventory is not ready for governance.
Assign ownership before you assign permissions
Ownership is the basis of accountability. Every identity needs someone who can justify why it exists and why its access is still needed.
For workforce identities, the accountable reviewer is usually the manager or sponsor who can attest to business need. Their role changes as the employee changes roles, projects, or leaves. For non-human identities, the accountable owner is the business or application owner. The operator can implement access, but the operator is not the same thing as the owner.
For AI agents, record the sponsoring human or team and, where relevant, the human on whose behalf the agent acts. Do not let the agent itself be the only accountable owner of its own access. The same caution applies to shared mailboxes and other inherited constructs that can hide responsibility.
The lifecycle trigger also has to match the identity type:
- People and contractors: connect joiner, mover, contractor end date, and leaver events to access templates, approvals, changes, and revocation. When someone moves, calculate both the access to add and the obsolete access to remove. If you keep old entitlements by default, privilege creep follows. Citadel Identity360’s contractor lifecycle controls keep temporary and third-party identities from outliving their need.
- NHIs: tie lifecycle changes to deployment, service retirement, integration removal, ownership transfer, and sponsor changes. An owner leaving does not automatically mean disabling a critical production service. It means you reassign accountability, confirm dependencies, and then decide what to revoke safely.
One important policy choice is worth stating plainly. If you discover an ownerless, shared, or legacy account, assign an interim owner, document dependencies, set a review deadline, and migrate or retire it. If a privileged production identity cannot be removed promptly, require a formally approved exception. There is no universal review interval that fits every estate—risk scoring and ownership status in the graph should drive urgency.
Use common policy principles, but not identical workflows
One model does not mean one identical process. The governance layer should share the principles, then apply identity-specific controls.
Those common principles are straightforward:
- Known owner and purpose
- Least privilege
- Separation of duties
- Explicit approval for sensitive access
- Bounded exceptions
- Recorded decision and fulfillment
- Reassessment after material change
The important part is to assess effective access, not just labels. A service principal that can impersonate another identity, or an employee who can change that principal’s permissions, creates a cross-boundary escalation path even if the visible role looks harmless. SoD and risk scoring in Citadel Identity360 surface those conflicts and excessive grants so reviewers act on effective exposure, not on role names alone.
For people, initial access should come from a verified role or other approved attribute, with requests and approval used for deviations. For machines, grant only the resource actions needed in the intended environment. Cloud IAM and workload federation enforce access at runtime; the governance decision—and the evidence—still belong in IGA.
This is the right place to apply Zero Trust thinking. Identity and attributes are inputs to dynamic access decisions, but a central governance record does not continuously authorize every request by itself. Governance and runtime enforcement are separate layers.
For workloads, temporary credentials and IAM roles are preferable to long-lived secrets. Federation does not by itself create ownership, approve access, or complete the review process—Citadel Identity360 keeps those governance steps explicit even when the enforcement path uses short-lived credentials.
Extending the same principles to AI agents and MCP
For AI agents, the governance pattern needs one more layer of specificity. Record the agent and sponsor, bound which tools and resources it can use, define when human approval is required, and keep the agent-to-tool connection visible in the review process. Reviewing the fact that an agent was registered is not enough. You need to review the tool connection and the permissions behind it.
Citadel Identity360 treats agents and MCP (Model Context Protocol) registrations as governable NHIs: agent and MCP registration, clear ownership, tool-level authorization, and a kill switch when risk requires immediate revocation. Governance configuration produced by Citadel’s AI governance capabilities can be used by platforms such as Claude, OpenAI, and Cursor for MCP access—without treating those platforms as native Citadel connectors. The goal matches classic machine identity governance: know who owns the agent, what tools it may call, which resources those tools can reach, and how to shut the path down.
Connect governance decisions to provisioning and revocation
A policy that cannot change the target system is only paperwork. The governance workflow has to end in a confirmed change in the directory, application, cloud IAM service, or workload-identity mechanism that enforces access.
The clean flow is:
authoritative event → identity and owner record → policy and risk check → appropriate approver → change in the target system → read-back of the resulting entitlement → logged evidence and exception handling
That last step matters. An approved removal request is not the same thing as confirmed removal in every target system.
For applications that support SCIM, the protocol can carry user and group changes, including PATCH and DELETE. But you still need to test the specific application behavior. Group removal, account deactivation, and deletion can have different outcomes. SCIM support does not mean the application governs every machine identity or every entitlement the same way—which is why connector breadth beyond SCIM matters. Citadel Identity360 is built to provision and reconcile across REST, SOAP, SCIM, LDAP, JDBC, files, SFTP, batch, mainframe, and custom integrations so legacy and modern targets sit in the same evidence model.
Where a target system does not have a reliable API, use a controlled manual task with an owner, due date, completion evidence, and reconciliation. Do not let “manual” become a synonym for “untracked.” No-code-first administration in Citadel Identity360 lets IAM teams shape those workflows—and the roughly 400 hours of included customization helps map complex enterprise fulfillment without waiting on a separate engineering project for every edge case.
For NHIs, revocation often has two parts. First, narrow or remove the underlying cloud or application authorization. Second, disable the identity when the workload is retired and invalidate any surviving credentials or sessions through the systems that actually enforce them. If the identity is shared or legacy, test business continuity before removing it. For AI agents and MCP registrations, the kill switch is the equivalent control when tool access must stop immediately.
An IGA approval screen does not rotate secrets, end active sessions, or prove deprovisioning succeeded. Those actions must be confirmed in the target enforcement layer—and the governance platform must record the read-back.
Review effective access by risk and decision-maker
Access reviews are where many programs lose precision. The fix is not more review volume. It is better routing.
Do not put one giant mixed list in front of every reviewer. Organize campaigns by risk and by who is actually qualified to decide.
- Managers and sponsors should assess whether people still need business access.
- Application and workload owners should assess whether technical identities, tool connections, privileges, and deployments remain necessary.
- Cloud specialists should validate complex or inherited access.
- Orphaned identities should be routed for ownership resolution, not rubber-stamped.
The review should include the access patterns that matter most:
- Production privilege
- External trust
- Dormant access
- Cross-environment reuse
- Contractor expiration
- Segregation-of-duties conflicts
- Owner changes
- AI agent and MCP tool authorizations
For each decision, preserve the entitlement and resource reviewed, the owner, the usage and risk context, the reviewer, the decision, the rationale, the timestamp, the remediation assignment, the actual target-system result, and any approved exception. Verify that denied access was removed. Then revisit exceptions.
A practical review model for a hybrid multi-cloud enterprise is to align the campaign with the reviewer’s actual decision quality. High-impact production machine access deserves more scrutiny than low-risk standard workforce access. A workload retirement, contractor end date, or owner departure should trigger immediate review rather than waiting for a generic calendar cycle. Citadel Identity360’s certification workflows, SoD checks, and risk scoring support that routing—so high-risk NHI and agent findings do not get buried in a mixed workforce list.
What to measure for decision value
Measure outcomes, not campaign counts. Useful governance metrics include:
- Percentage of discovered identities with confirmed owners
- Percentage of material applications and cloud estates with reconciled entitlements
- Elapsed time from departure, contractor end, or workload retirement to verified revocation
- Outstanding orphaned privileged identities
- Review decisions completed and remediations actually closed
- Exceptions past expiry
- Access-request fulfillment time
- Number of AI agents and MCP registrations with ownership, tool-level auth, and a defined kill-switch path
- SoD and risk-score findings closed within the review window
If you do not define numerator, denominator, system scope, and measurement window, the metric will not help the CIO make a decision. An identity graph that already holds owners, entitlements, and certification evidence makes those measures operational rather than spreadsheet exercises.
Why Citadel Identity360 fits this IGA model
Once the process is clear, the platform question becomes much easier. The strongest architectural fit is a shared IGA control plane that connects people, services, applications, entitlements, approvals, and evidence in one governance model—without pretending to replace every identity provider, cloud IAM service, or runtime enforcement point.
Citadel Identity360 is Astranova Labs’ implementation of that approach. For CIOs evaluating platforms against the model above, the practical fit looks like this:
| Governance need | What Citadel Identity360 contributes |
|---|---|
| One inventory across people and machines | Identity graph linking workforce, contractors, NHIs, apps, entitlements, and ownership |
| Connector coverage for hybrid estates | REST, SOAP, SCIM, LDAP, JDBC, files, SFTP, batch, mainframe, and custom |
| Admin speed without custom engineering for every change | No-code-first administration, with ~400 hours of customization included |
| Distinct workflows, shared evidence | JML and contractor lifecycle alongside NHI ownership and review campaigns |
| Effective-access and conflict visibility | SoD controls and risk scoring on the same graph |
| AI agents and MCP | Registration, ownership, tool-level auth, kill switch; governance config usable by Claude, OpenAI, Cursor, and similar platforms for MCP access |
| Closed-loop change | Provisioning, revocation, and read-back into the audit trail |
That combination treats employee lifecycle, machine ownership, access relationships, and review evidence as one model rather than separate programs—the outcome this article argues for.
The governance outcome you should expect
The goal is not just stronger control. It is faster employee access and accountable machine access without separate governance records.
When the model is working, you should see fewer orphaned identities, faster deprovisioning, cleaner ownership, tighter least-privilege enforcement, and better audit readiness. You also reduce the operational drag that comes from spreadsheets, email follow-ups, and disconnected access records.
If you want to pressure-test the model, start with one employee-to-workload access path. Map the owner, the entitlement, the resource, the approval trail, and the revocation path. If that path cannot be traced end to end, the governance gap is already visible.
FAQ
Can employees and non-human identities really use one governance model?
Yes, for inventory relationships, accountable ownership, policy principles, decisions, exceptions, and evidence. No, not for an identical authentication mechanism or lifecycle trigger. Human identities and non-human identities need different operational controls, but Citadel Identity360 is built so they still sit in one identity graph, one SoD/risk model, and one audit trail.
Who approves an AI agent’s or service account’s access?
An accountable application, workload, or business owner should justify the purpose. Technical owners verify implementation. If the access includes sensitive delegated actions, an additional human decision may be needed. For agents and MCP registrations, Citadel Identity360 keeps ownership and tool-level authorization explicit so the approval is not reduced to “the agent was registered.”
Does an IGA platform replace cloud IAM or workload federation?
No. IGA governs the decisions and evidence. Cloud IAM, identity providers, and workload-identity services authenticate or enforce access. Integration and reconciliation—through Citadel Identity360’s connectors and read-back—determine whether the governance decision actually takes effect.
What happens when the employee who owns a production workload leaves?
Reassign accountability, inspect the workload and its entitlements, preserve necessary service continuity, revoke the former employee’s personal access, and remove unnecessary workload access after dependency checks. An owner departure is a governance event, not an automatic shutdown order. Citadel Identity360’s NHI and contractor lifecycle controls are aimed at making that reassignment and review a first-class workflow, not an after-the-fact scramble.
How should we include AI agents in the same IGA model?
Treat agents and MCP registrations as non-human identities: register them, assign owners, authorize at tool level, and keep a kill switch ready. Governance configuration from Citadel’s AI governance capabilities can be used by Claude, OpenAI, Cursor, and similar platforms for MCP access, so agent reach to sensitive resources stays inside the same ownership and review model as other NHIs.
Closing view
An inventory of employees in one system and machines in another will always produce gaps. A shared IGA model—ownership, effective access, lifecycle, SoD, and evidence on one graph—is what turns identity governance into operational control for the CIO.
If you want a practical next step, pick one role transfer, one owner departure, and one retired production workload, and trace each through permissions and verified remediation. That is the point where the model stops being theory.
To see how Citadel Identity360 runs that sequence—across workforce and contractor lifecycle, NHI ownership, identity-graph path visibility, SoD and risk scoring, and AI agent / MCP controls—request a demonstration against your HR source, cloud accounts, legacy applications, and agent estate.