AI Agent and MCP Access Governance: What IGA Must Control

AI agents change the access question from “who can log in” to “what can this agent invoke, through which MCP server, and under whose authority?” For anyone responsible for identity governance, that is the question that matters. MCP access management has to follow the full path from person to agent to server to tool to downstream resource. Anything less gives you visibility without control. AI agent governance is not a side topic. It is an identity governance problem, and it needs registration, ownership, approval, enforcement, and auditability.

Citadel Identity360, from Astranova Labs, governs that full path. Citadel registers MCP servers and AI agents with accountable owners, authorizes each agent at the level of individual tools, controls which people may use each agent, and keeps a kill switch ready to revoke access instantly. Citadel’s AI governance produces a governed MCP access configuration file that agent platforms and MCP clients can consume, so every agent’s tool access flows through Citadel registration, ownership, and tool-level policy, with no tokens, keys, or secrets embedded in what is distributed. Agents sit in the same identity graph as employees, contractors, and service accounts, under the same certification, SoD, and risk-scoring model, administered no-code-first.

Why MCP changes the governance model

MCP is not just another integration layer. The Model Context Protocol is the path that lets an AI application connect to capabilities exposed by servers, and those capabilities include tools, resources, and prompts. For governance, reachability is not the issue. The issue is whether a specific agent, acting in an approved context, is permitted to invoke a specific tool and reach a specific downstream resource.

That distinction matters because several things are easy to confuse:

• Discovery is not authorization.
• Human access to an agent is not the same as agent access to a tool.
• A tool grant is not downstream application authorization.
• Authentication is not approval.

A token establishes a valid transport context. It does not replace business justification, named ownership, duration, or review. Treat those as the same thing and MCP access management becomes a blind spot instead of a control point.

The practical implication is simple: you need governance at each layer, not just at the front door. The agent is allowed to start. The server is registered. A specific tool is still blocked. The downstream system still rejects an action outside its entitlements. Good AI agent governance respects each boundary, and Citadel Identity360 models each one explicitly: person to agent, agent to server, agent to tool, and identity to downstream entitlement.

Registration and ownership are the starting control

If you cannot name what exists and who owns it, you cannot govern it. That is true for human identities, and it is just as true for agents and MCP servers. A usable enterprise record identifies the agent or server, its purpose, the responsible human or team, the environment, connected servers, approved tools, downstream applications or datasets, credentials or credential owner, deployment or change status, and a review or expiry date. Where a third-party vendor is involved, that is recorded too.

The control principle is straightforward: registration creates accountability before deployment. Ownership tells reviewers who is responsible for the decision. Purpose tells you why the access exists. Approved tools tell you what the agent may actually do. Review dates tell you when the access must be rechecked.

That is also why shared or generic identities are a problem. An agent running under an undocumented administrator token with no named sponsor is not governed access. It is operational debt with an access path attached. Where child agents act separately, treat them as distinct identities so attribution holds.

Citadel Identity360 makes registration the entry point. You register MCP servers and map ownership at registration, create agents with their owners recorded from the start, and connect each agent to one or more registered servers. Citadel also discovers AI agents from the central registries of Microsoft Entra, AWS, and Google Cloud and brings them into one governed inventory, so agents created outside the governance process are pulled into it rather than left in the shadows. Because Citadel’s identity graph links every agent to its human sponsor, servers, tools, and downstream entitlements, the ownership chain stays visible even when the sponsor is a contractor on a fixed end date: Citadel’s contractor lifecycle flags the agent for reassignment or retirement when that sponsor leaves.

Approval workflows decide whether access should exist

Registration alone does not answer the real governance question. You still have to decide whether the access should exist at all. That is where approval workflows and lifecycle control come in.

The sequence Citadel Identity360 runs is:

• Request. Register the agent with its business purpose, owner, proposed servers, exact tools, affected data, and intended lifespan.
• Evaluate. Route the request to the agent owner and the relevant application or data owner for decision.
• Approve and provision. Grant only the agent identity, the allowed server relationship, the tool allowlist, and the required downstream entitlements.
• Reassess. Recheck when the agent changes purpose, the server adds tools, the downstream application changes privileges, or the human sponsor leaves.
• Retire. Suspend and retire the agent by removing grants, revoking or rotating credentials, and preserving the records required by policy.

That sequence is what makes governance hold up. A connection to a server is not a blanket approval for everything exposed on that server. Read-only access deserves a different threshold from write or delete capabilities. Privileged or cross-system actions need stronger justification. Separation-of-duties conflicts still matter.

Citadel applies the same discipline it uses for people. SoD and risk scoring flag agents whose combined tool grants create a toxic combination, such as creating a supplier record and approving payment to it, and rank write-capable and cross-system grants for closer scrutiny. Scheduled certification campaigns put agent tool grants in front of their owners with AI-assisted recommendations and risk context, so reviewers approve with confidence and revoke what is no longer needed. All of it is configured no-code-first, and Citadel’s 400 hours of included customization cover the organization-specific approval routes and policies that agent programs need.

Policy enforcement has to happen at the tool boundary

Approvals only matter if something enforces them. For MCP access management, the question is where the unapproved action is blocked. If you cannot answer that, you do not have control.

Effective enforcement checks four boundaries:

• Whether the human may use the agent
• Whether the agent may connect to the server
• Whether the agent may invoke the specific tool
• Whether the downstream application identity has the right to act

That is why tool-level authorization matters so much. Whole-server grants are too broad when a server exposes multiple capabilities. Read and write tools are evaluated separately. New tools added to a server are reviewed before they become available to approved agents.

Citadel Identity360 enforces at each of those boundaries:

• Who may use the agent. An OAuth layer restricts agent use to people in your organization, and an additional allowlist narrows access to selected members.
• Which server and which tools. Each agent is mapped to the specific tool sets it needs from each registered MCP server. Authorization is granted per tool, never per whole server, so a document server can expose search and read to an agent while delete stays unassigned.
• How access is distributed. Citadel’s AI governance produces the governed MCP access configuration file that agent platforms and MCP clients consume. It carries no tokens, keys, or secrets. People sign in with their organizational identity, and usage is governed by Citadel’s access rules.
• How access stops. The kill switch revokes an agent’s access immediately when risk requires it, without waiting for a review cycle.
• What the downstream identity may do. Citadel’s broad connectors (REST, SOAP, SCIM, LDAP, JDBC/SQL, flat files, SFTP, scheduled batch, mainframe, and custom) govern the entitlements of the application identities behind each tool, so a tool grant never silently implies broad downstream rights.

The protocol layer matters here, and it is worth being precise about it. In the current MCP specification (revision 2026-07-28), authorization is optional. HTTP-based implementations that support it are expected to follow the specification’s OAuth 2.1–based flow, while STDIO implementations retrieve credentials from the environment instead. A compliant transport flow is not enterprise governance. It does not create ownership, approval, certification, or least privilege on its own. Citadel supplies that governance layer on top of whatever transport the agent uses.

Auditability must reconstruct both decision and action

If governance cannot be reconstructed later, it is incomplete. Audit readiness for AI agent governance means answering who requested the access, who owns the agent and server, who approved the grants, which human initiated the interaction, which agent identity and tool acted, what resource was reached, when it happened, under what policy and credential context, and whether the action was allowed or denied.

That requires correlation across multiple records:

• Governance approvals
• Identity-provider authentication
• Enforcement-point tool events
• Downstream application logs

The identifiers and timestamps need to line up. Otherwise you know that something happened somewhere, but not who did what under which authority. That is not enough for audit, incident review, or access recertification.

Citadel Identity360 anchors that chain. Because every agent’s tool access flows from a Citadel registration and policy, each event traces back to a registered agent, a named owner, an approved tool grant, and an organizational identity. Citadel captures registration, ownership, approvals, tool assignments, certification decisions, and revocations as audit-ready evidence with reporting and export, so the governance half of the record exists before the auditor asks for it.

The operational measure that proves the controls are real is time to revoke effective access: the time until the agent’s credential and underlying entitlement actually stop working. Citadel’s kill switch is built to collapse that number from a review cycle to an immediate action.

Which identity platform extends governance to agents and MCP?

Buying “AI security” does not give you identity governance. The selection test is whether the platform manages the identity path from registration through approval to enforcement and evidence. That means agent and server inventory, named ownership, per-tool entitlements, approvals and certifications, offboarding, a real enforcement point, integration with your identity providers and target applications, and reconstructable records.

Adjacent tools each cover a slice. IAM and SSO authenticate the person, but do not decide which tools an agent may invoke. Privileged access management vaults and brokers credentials, but does not own agent registration or certification. Secrets managers keep credentials out of code, but carry no business purpose or owner. API gateways enforce traffic rules, but do not know who approved the agent or when its access is due for review. Each is useful. None governs the whole path.

Citadel Identity360 does.

Control	What governance requires	How Citadel Identity360 delivers it
Registration and ownership	Agent and MCP server registration with named owners	MCP server and agent registration with ownership mapped at registration; agent discovery from Microsoft Entra, AWS, and Google Cloud registries
Per-tool governance	Read and write tools approved or denied separately	Tool-level authorization per agent, per server, never whole-server grants
Human access control	Which people may use the agent	OAuth-gated agent use limited to organization members, with an additional allowlist
Governed distribution	Agent platforms and MCP clients consume access from policy, not shared secrets	Governed MCP access configuration file with no tokens, keys, or secrets
Enforcement and revocation	Unapproved calls blocked; access stopped on demand	Tool-level policy plus a kill switch for immediate revocation
Lifecycle governance	Review, change, sponsor departure, and retirement	Same joiner–mover–leaver and contractor lifecycle used for people and NHIs
Risk and SoD	Toxic tool combinations and high-risk grants surfaced	SoD and risk scoring across agent tool grants and downstream entitlements
Audit evidence	Records from request to action	Identity graph linking agent, owner, approval, tool grant, and revocation, with audit-ready reporting and export

The decisive advantage is one governance model. Citadel covers human, machine, and AI identities across cloud, SaaS, on-premises, and hybrid environments, so agents are governed alongside the people who sponsor them and the systems they touch, not in another isolated tool. That is exactly the pattern CIOs and Heads of IT need when AI agents start touching real systems.

What Citadel demonstrates in a proof of concept

A slide deck does not prove control. A live workflow does. In a Citadel Identity360 proof of concept, you see the full path governed end to end:

• Register one agent and two MCP servers, each with a named owner
• Approve read-only tools for the agent and leave a write or delete tool unassigned
• Restrict agent use to organization members, then narrow it further with an allowlist
• Distribute the governed MCP access configuration and show that it carries no tokens, keys, or secrets
• Trigger a call to the unassigned tool, see it denied, and trace it to the policy and owner
• Add a new tool to a registered server and show that it stays unassigned until its owner authorizes it
• Run a certification on the agent’s tool grants with risk context and AI-assisted recommendations
• Remove the human sponsor through the contractor or leaver lifecycle and see the agent flagged for reassignment or retirement
• Hit the kill switch and show that effective access stops immediately

That sequence proves the platform governs real behavior rather than cataloging identities, and that your organization keeps control without multiplying manual administration.

The broader maturity lesson is clear. Inventory is not enough. Context is not enough. You need governance that reaches the point of action and leaves a trace you can trust. That is the standard for AI agent governance in the enterprise, and it is the standard Citadel Identity360 is built to.

FAQ

Does an agent need its own identity if a person starts it?

Yes. The person’s right to launch the agent is separate from the agent’s own permissions and accountability. Citadel Identity360 registers the agent as its own identity with a named owner, and governs who may use it separately through OAuth-gated access and allowlists.

Is connecting an MCP server enough to govern it?

No. Registration needs ownership, each agent needs explicit tool scope, and the downstream system still needs restricted entitlements. Citadel captures ownership at server registration, authorizes each agent per tool, and governs downstream entitlements through its connectors.

Does OAuth solve AI agent governance?

No. OAuth authenticates and authorizes a protected HTTP request, but it does not create ownership, approval records, certification workflows, or tool-level policy by itself. Citadel uses an OAuth layer to control who may use each agent and adds the registration, ownership, tool-level authorization, certification, and kill switch that turn authentication into governance.

How does Citadel’s policy reach the agents and MCP clients people actually use?

Citadel’s AI governance produces a governed MCP access configuration file that agent platforms and MCP clients consume. People sign in with their organizational identity, the configuration carries no tokens, keys, or secrets, and every agent’s tool access flows through Citadel registration, ownership, and tool-level policy.

How fast can we cut off an agent that misbehaves?

Immediately. Citadel’s kill switch revokes the agent’s access on demand, and the revocation is recorded alongside the agent’s registration, owner, and approvals as audit evidence.

Closing view

AI agents make the access path longer, and every hop from person to agent to server to tool to resource is a place where governance either holds or leaks. Citadel Identity360 governs every hop in one model: MCP server and agent registration, accountable ownership, tool-level authorization, OAuth-gated use, a governed MCP access configuration, a kill switch, and the same identity graph, SoD and risk scoring, certifications, and audit-ready evidence that cover your people and machines.

To see it in practice, request a Citadel Identity360 demonstration: one agent, two MCP servers, a denied tool call, a sponsor departure, and a kill switch, traced from registration to revoked access.