How should teams inventory AI agents that are built outside central IT?

Why AI agent inventory starts with ownership, purpose, and scope

Inventorying externally built AI agents is not just an asset register exercise. Teams need enough context to decide whether an agent should exist, who can approve it, what it can touch, and whether it is already operating outside policy. Recording owner, purpose, tools, data sources, model version, and approval path turns a vague “AI app” into a governed subject that can be reviewed, constrained, or retired.

A useful inventory entry should answer three questions at once: what the agent is for, what it can access, and who is accountable when it behaves unexpectedly. If those fields are missing, the organisation usually cannot distinguish a sanctioned pilot from a shadow agent with production reach.

The strongest practical pattern is to treat the agent as a first-class identity subject rather than a software note. That means assigning a unique agent ID, linking it to a responsible owner, and keeping the register current as the agent’s tools, data paths, and approvals change. A central register is most valuable when it becomes the default lookup point for security, risk, and operations teams.

What belongs in the inventory record for an externally built agent?

The minimum record should capture the agent’s business role, technical dependencies, and access profile in one place. Useful fields include the owner, the intended use case, the model or service it uses, the tools it can invoke, the data sets or systems it can reach, the approval or exception path, and the credentials or tokens it uses to act.

That record should also describe whether the agent is interactive, autonomous, or event-driven, because review depth changes with autonomy. An agent that drafts text from benign inputs is not assessed the same way as one that can open tickets, change records, call external APIs, or move data between environments. The inventory should make those differences visible without forcing reviewers to reconstruct them from tickets or chat history.

Teams should also record the lifecycle state, including whether the agent is in testing, limited release, production, or pending retirement. That helps separate temporary experimentation from persistent service use and makes it easier to identify agents that have drifted beyond the original approval. When that happens, the inventory is the control that lets you discover and close the gap.

How central review, scoped credentials, and periodic recertification keep shadow agents contained

A register only works if it is tied to access control. Scoped credentials should be issued per agent and limited to the smallest practical set of tools, data, and actions. When the approval path is clear, reviewers can decide whether the requested access matches the use case rather than assuming the vendor’s default settings are acceptable.

Periodic review matters because externally built agents tend to change after initial approval. New connectors get added, model versions change, and teams often repurpose an agent for a broader workflow than the one originally approved. Without recertification, the register becomes a historical record instead of an operational control.

Discovery also needs a search path outside procurement and central IT. Shadow agents are often introduced by product teams, business units, or consultants, so inventorying them requires cross-checking OAuth grants, API keys, SaaS integrations, and any place where an agent can obtain credentials or call external tools. NHIMG’s Shadow AI and AI Agent Discovery Guide is useful here because the inventory only helps if hidden agents can actually be found.

Risk and Threat Considerations

Uninventoried agents create blind spots in access governance, data exposure, and incident response. The main risk is not the existence of the agent itself, but the fact that no one can reliably tell what it can reach, who approved it, or whether its credentials are still valid.

Failure mechanism: An unsanctioned or poorly documented agent accumulates permissions, tools, and data access outside normal review, then continues operating after its original owner, purpose, or vendor relationship has changed.

Impact: Teams lose control over blast radius, cannot quickly revoke access, and may miss misuse, exfiltration, or destructive actions until the agent is already embedded in business workflows.

Practitioner Guidance

What to prioritise: Start with agents that already have production data access, external tool access, or delegated authority to act on behalf of users. Those are the ones where inventory gaps most quickly become security gaps.

What to verify: Before trusting an entry, confirm that the listed owner can approve or revoke it, the recorded credentials match what is actually deployed, and the declared tool list reflects the live integration set. If any of those do not line up, treat the record as incomplete rather than authoritative.

Decision rule: If an agent cannot be uniquely identified, scoped, and recertified, do not treat it as a low-risk experiment. Either bring it under governance or remove the access path that lets it continue operating.

Practitioner takeaway: The inventory is not a catalogue of AI projects, it is the mechanism that lets teams decide which agents are trusted to act, which are temporarily tolerated, and which must be revoked.

Related resources from NHI Mgmt Group

• Guide: Red Teaming AI Agents for Identity Abuse
• How should organizations approach the governance of AI agents?
• What happens when AI agents are built outside the SDLC and CI/CD pipeline without extra controls?
• What should organisations do when AI agents are being built outside IT oversight?
• What makes agentic AI an NHI governance issue?