Shadow AI Governance: Registry Boundaries That Matter

Shadow AI governance is the work of finding where artificial intelligence is used outside the inventory an organisation owns and bringing the parts that matter under accountable control. Teams adopt assistants, agents and connected tools faster than central programmes can catalogue them. The result is not only a software list problem. It is an identity and access problem whenever an AI system can reach enterprise data or act through tools. Citadel Identity360 helps with one bounded slice of that problem: agents found in Microsoft Entra, AWS and Google Cloud agent registries can be brought into ownership, access paths, reviews and containment. Finding AI use outside those sources remains a wider programme responsibility.

Shadow AI is a visibility gap before it is a product gap

Shadow AI describes AI systems and practices that operate without a clear owner, purpose record or governance path. The label is useful when it points to missing accountability. It is unhelpful when it is treated as a single product category that one console can fully inventory.

Three situations often get mixed together:

• A worker uses a consumer AI assistant in a browser for drafting, with no enterprise agent registration.
• A team adopts a hosted AI application whose contract and administrators sit outside the usual intake process.
• An AI agent appears in a cloud or directory agent registry and can be connected to tools, yet nobody has assigned an owner or limited what it may invoke.

Only the third case sits inside Citadel’s agent-discovery boundary as stated on the products page. The first two still need programme attention. They are not solved by claiming that an identity platform sees every GenAI click or every unsanctioned SaaS AI subscription.

This article therefore separates the wider mapping problem from the registry-to-governance handoff. For how registered agents and MCP access are controlled once they are in scope, see Astranova’s posts on AI agent and MCP access governance and governing agents beyond a login. Those explain the control model. Here the question is how shadow use becomes visible enough to enter that model without overstating discovery.

Why identity teams inherit the shadow AI conversation

When an AI system can retrieve files, call APIs or change records, access questions apply. Who authorised the agent. Which identity it acts under. Which tools it may use. What happens when the sponsoring team leaves. Those are familiar IGA concerns in a new shape.

Identity programmes already track people, service accounts and application roles. Agents add another principal that can inherit permissions and initiate actions. Leaving them unnamed creates the same class of residue described in the identity sprawl article: access continues while ownership fades.

Shadow AI becomes urgent for identity teams when:

• An agent can reach sensitive resources through registered tools.
• A cloud agent inventory exists, but governance never consumed it.
• Reviews cover human roles while agent tool grants go unexamined.
• Containment is unclear if an agent behaves unexpectedly.

None of those points require a claim that every unofficial chatbot has been discovered. They require a clear boundary between what the organisation will map through programme methods and what registry-based agent governance can bring under ownership next.

Use NIST AI RMF to frame the wider programme

NIST’s AI Risk Management Framework organises AI risk activities into four functions: govern, map, measure and manage. The framework is voluntary guidance for managing AI risks across the lifecycle. It is not a product specification for shadow-AI scanners.

The MAP function is especially relevant to shadow AI. NIST describes MAP as establishing context to frame risks related to an AI system, including intended purposes, actors, business use and risks involving third-party software and data. After mapping, organisations should have enough contextual knowledge to inform whether to proceed and how to manage risks as context evolves.

In practice, that supports a programme inventory of AI systems and uses that may never appear in Entra, AWS or Google Cloud agent registries. Examples include departmental GenAI subscriptions, embedded model features in business applications and informal browser use policies. Those entries need owners, purpose statements and risk context. They do not automatically become Citadel agent records.

GOVERN outcomes in the AI RMF emphasise policies, roles and engagement with relevant AI actors, including attention to third-party AI. That governance layer should decide who may adopt AI tools, how intake works and when an AI use must be registered as an agent in the identity programme. Citadel then operates on agents that enter the governed inventory through supported discovery and registration paths.

Draw a hard line around what Citadel discovers

On the products page, Citadel Identity360 states that AI agent discovery covers the central registries of Microsoft Entra, AWS and Google Cloud, then places those agents in a governed inventory. Keep that product boundary intact in operating plans.

What that means for shadow AI work:

• In scope for registry discovery: agents present in those cloud and directory registries that the organisation chooses to govern.
• Out of scope for that discovery claim: unsanctioned SaaS AI applications that never register agents there, browser-only GenAI use, network traffic analysis and general shadow-IT scanning.

Teams can still reduce shadow AI risk outside those registries through procurement intake, acceptable-use policy, data-loss controls and application inventory processes. Present those as complementary controls. Do not present Citadel as the system that found the browser session or the unknown SaaS chat tool.

Once an agent is in the governed inventory, Citadel’s agent-governance capabilities apply: accountable owners, connections to registered MCP servers, tool-level authorisation rather than every tool on a server, controlled who-can-use rules, and a configuration file generated in Citadel for compatible MCP clients without embedding tokens, keys or secrets in that shared file. A kill switch provides intervention or containment. Those controls are for governed agents, not a substitute for finding every AI touchpoint in the enterprise.

Build a two-track operating model

Track A: map AI uses the registries will not show

Create a lightweight AI-use register owned by the AI or digital programme, aligned to NIST MAP context questions: purpose, users, data classes, third parties and oversight. Feed it from intake forms, application owners and periodic attestations. Escalate high-impact uses into formal risk review.

This track answers whether the organisation even knows which AI systems it is encouraging. It will miss some informal use. It still creates a durable place for decisions that identity tooling alone cannot invent.

Track B: govern agents the registries can surface

On a defined cadence, ingest agents surfaced from those Entra, AWS and Google Cloud registries into Citadel’s governed inventory. Assign owners. Decide which agents remain active. Connect only the MCP servers and tools each agent needs. Issue the generated configuration for client access. Include agents in access reviews. Use containment when an agent must be stopped.

Track B does not wait for a perfect enterprise-wide AI census. It closes the gap where agents already exist in platforms the organisation operates, yet remain outside identity governance.

Keep the tracks connected. When Track A finds a business team building agents in a supported cloud, require that those agents appear in Track B before production data access is approved. When Track B finds an ownerless registry agent, treat it as shadow AI that has already entered the cloud estate.

An illustrative path from unknown use to governed agent

Consider a department that prototypes an assistant using a cloud agent service tied to the organisation’s tenant. For weeks it helps draft internal notes. Later someone connects tools that can read a shared document library. No owner is recorded in the identity programme.

A browser-use policy would not have described this agent. A SaaS purchasing report might not either. The cloud agent registry, however, can show the agent once discovery runs. Citadel can bring that registry entry into the governed inventory, require an owner, limit tools and place the agent into review cycles.

If investigation shows the prototype should stop, containment can halt the governed agent while the business decides whether to rebuild under an approved pattern. If it should continue, the team follows the registration and configuration path described in the linked agent-governance articles rather than inventing a private trust model.

The example is illustrative. It shows why registry discovery matters for shadow AI without claiming Citadel observed the early browser experiments that never became registry agents.

What good looks like for identity teams

A workable shadow AI posture for identity operations includes:

• A written boundary stating which AI uses are programme-mapped versus registry-governed.
• Owners for every registry-ingested agent brought into Citadel.
• Tool authorisations that match the agent’s purpose, reviewed on a schedule.
• Access-path visibility from the agent identity to the resources and tools it can reach.
• A tested containment path for intervention when needed.
• Evidence that approved changes to agent access were followed through to completion.

Pair that with lifecycle discipline for related non-human identities, such as service accounts and API keys the agent depends on. Citadel’s non-human identity lifecycle management keeps accountable owners with those identities from creation through decommissioning. An agent review that ignores its supporting credentials leaves a residual path.

Risk-based access management and toxic-combination monitoring can focus attention when agent-related access patterns warrant investigation. They support prioritisation. They do not claim every unsafe AI action is prevented before it occurs.

Avoid two common overcorrections

The first overcorrection is to announce that the IGA platform will eliminate shadow AI. Registry discovery cannot see AI systems that never appear in those registries. Overpromising damages trust when a later audit finds browser or departmental tools outside the inventory.

The second overcorrection is to postpone all agent governance until a complete AI census exists. Agents already registered in cloud directories can accumulate tool access while the census continues. Start Track B on a bounded population, publish the Track A method, and connect the two at intake gates for production data.

For application-portfolio growth that accompanies AI adoption, the SaaS sprawl article covers the application-to-governance handoff. Shadow AI governance adds the agent and AI-use layer on top of that handoff.

Using Citadel Identity360 after an agent is found in a registry

When discovery returns agents from the supported registries, Citadel Identity360 provides the identity-governance layer:

• Owned inventory: registry-discovered agents enter a governed inventory with accountable owners.
• Relationship context: the identity graph and access-path discovery help explain how agent-related access reaches resources.
• Reviews: scheduled certifications present risk context and AI-generated recommendations so owners decide whether agent access and tool grants still fit.
• Containment: a kill switch supports intervention when an agent must be stopped.
• Client access: a configuration file generated in Citadel lets compatible MCP clients reach governed services without putting tokens, keys or secrets in that shared file.

Registration of MCP servers, tool-level authorisation and who-can-use controls belong in the operating design for governed agents. Use the linked deep-dive posts for that control sequence rather than treating this article as a second MCP implementation guide.

Keep demos focused on a registry-discovered agent with real tool access, not on a claim of full shadow-AI surveillance.

Questions that appear when AI adoption outruns ownership

Does shadow AI always mean malicious use?

No. Much of it is well-intended experimentation without an intake path. The risk is missing ownership and access control, not motive alone. Treat findings as governance debt unless evidence shows abuse.

Can Citadel list every GenAI tool staff open in a browser?

No. Agent discovery is limited to agents available through Microsoft Entra, AWS and Google Cloud central registries. Browser-only use and many SaaS AI tools require separate programme mapping, policy and application controls.

How does this differ from ordinary shadow IT?

Shadow IT often focuses on unsanctioned applications. Shadow AI includes those applications and agentic systems that can act through tools. When an agent can invoke enterprise capabilities, identity governance becomes part of the response, not only procurement.

Should we block all AI until mapping is complete?

Blocking decisions belong to organisational policy and risk tolerance. Identity teams can still govern registry-visible agents immediately while the wider AI map matures. A freeze is a business control, not a substitute for ownership of agents already present in cloud registries.

How do certifications apply to governed agents?

Reviews help owners reconfirm whether an agent, its tools and related non-human identities remain justified. Provide path and risk context. Follow revoke decisions through fulfilment so access actually changes.

Which agent scenario belongs in the first demo?

Pick one agent already present in a supported Entra, AWS or Google Cloud registry that can reach a sensitive tool or dataset. Assign an owner in Citadel, inspect the access path, run a review decision and show containment. Keep wider AI-use mapping on the programme track beside that demo.

Bring one registry agent out of the shadows

Select an AI agent that already appears in a supported cloud or directory registry and walk it into Citadel Identity360 ownership, path review and containment readiness. Use programme mapping for AI uses that registries cannot show. Request Demo with that boundary clear, or watch the product video preview before choosing the agent population.