What should teams do first when AI agents are being used without IT approval?

Start by discovering which agents and AI applications are already in use, which users created them, and which credentials they can reach. You cannot govern shadow AI until you know where it exists, who is using it, and which secrets or systems are already exposed through it.

What to do first when AI agents are already in use without approval

The first move is discovery, not enforcement theatre. Teams need a current inventory of agents and AI applications, who created or connected them, what data and credentials they can reach, and which business systems they already touch. That gives you the real blast radius before you decide whether to block, absorb, or govern the use.

Shadow AI often grows through convenience, not malice, so the inventory has to include user-created tools, embedded AI features, and any sanctioned or unsanctioned integrations that can act on behalf of a person. A partial view, such as only scanning approved vendors or only looking at endpoint installs, usually misses the credentials, consent grants, and API access that make the risk material.

The practical question is not simply “what agents exist?” It is “what can they do if a user signs in, consents, or pastes a secret into them?” That is why the first pass should connect each discovered agent to its owner, its authentication path, its granted scopes, and the systems that would be affected if the agent were compromised or over-permissioned.

What discovery needs to capture before governance can start

A useful discovery process separates the agent itself from the access path it uses. For each AI application or agent, identify the creator, the sponsoring team if there is one, the underlying model or platform, the authentication method, the presence of delegated credentials, and whether the tool stores prompts, files, tokens, or session data.

Teams should also distinguish between visible usage and hidden dependency. An AI feature inside a SaaS product can be just as important as a standalone chatbot if it can read mail, documents, tickets, source code, or customer records. Discovery should therefore include browser usage, OAuth grants, app consent, API key exposure, and any internal workflow where an employee has connected an agent to enterprise systems.

Once the inventory exists, classify each item by business purpose and authority: personal productivity aid, team automation, development assistant, or action-taking agent. That classification matters because a read-only summariser and a workflow agent that can send messages, create records, or invoke systems do not carry the same control requirements.

How to turn shadow AI discovery into a control decision

Discovery only becomes useful when it informs an immediate decision about access. If an agent has no business owner, no approved use case, and broad credential reach, treat it as a containment candidate while you assess whether the same outcome can be delivered under managed controls. If it has a legitimate use case, the next step is to narrow scopes, remove standing access where possible, and assign a human owner who can be accountable for its behaviour.

For teams that need a practical model for this step, NHIMG’s Shadow AI and AI Agent Discovery Guide is a direct fit because the discovery phase should lead into governance, not stop at listing tools. Once the first inventory is complete, the control conversation can move to least privilege, delegated authority, and approval boundaries, as outlined in NHIMG’s AI Agent Authorisation Guide.

Teams also need to separate harmless experimentation from agents with real authority. The moment an agent can reach production systems, customer data, or reusable secrets, it should be handled as an access-governed entity rather than a novelty tool. That is the point where inventory becomes identity, privilege, and incident-response work.

Risk and Threat Considerations

Shadow AI is risky because the hidden part is not the model, it is the access. An unsanctioned agent can inherit a user’s credentials, OAuth consent, or API keys and then expose systems the organisation never intended to connect to AI tooling.

Failure mechanism: Users create or approve agents outside central control, then those agents retain broad access through shared logins, persistent tokens, or over-scoped permissions. That makes it easy for data to leak, for actions to be taken on behalf of a user, or for a compromised agent to become a shortcut into higher-value systems.

Impact: The likely outcomes are credential exposure, unauthorized system access, data leakage, and difficult-to-trace business actions. At scale, the main damage is not one rogue chatbot, it is the accumulation of many small, untracked access paths that expand attack surface and weaken accountability.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Shadow AI discovery must find exposed secrets and tokens tied to agents.
	NHI-05 — Overprivileged NHI	Unsanctioned agents often inherit excessive access and broad system reach.
Recommendation — Scan discovered agents for exposed secrets and revoke or rotate them immediately. Reduce each agent to the minimum permissions required for its approved task.
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Discovery must identify agents that can act with user credentials or excessive authority.
Recommendation — Map each agent’s authority path and remove any unnecessary delegated privileges.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Discovery should surface reusable credentials, tokens, and other authenticators in agent use.
	AC-6 — Least Privilege	Shadow AI governance begins by limiting agent access to only what is required.
Recommendation — Inventory authenticators used by agents and rotate those that are exposed or shared. Constrain every agent to the smallest access set needed for its function.

Practitioner Guidance

What to prioritise: Start with the agents that already have the most reach, especially anything connected to email, documents, code repositories, ticketing systems, CRM, finance, or production tools. Those are the cases where discovery has immediate containment value.

What to verify: Confirm who can approve or revoke the agent’s access, whether the agent uses a human’s identity or a dedicated service identity, and whether any secret or token can be rotated without breaking a critical process. If you cannot answer those three questions, you do not yet have control.

Decision rule: If the agent has no business owner or can reach sensitive systems with standing credentials, treat it as an urgent governance and access review. If it has a clear owner and a bounded use case, move it into managed onboarding rather than forcing a blanket ban that users will work around.

Practitioner takeaway: The first good response to shadow AI is not prohibition, it is attribution, scope mapping, and access containment, because you cannot govern what you have not inventoried.