How do teams discover unmanaged AI agents across the enterprise?

Why unmanaged AI agents are hard to see in the first place

Unmanaged agents rarely present as a single, obvious asset. They often look like ordinary cloud workloads, browser automation, SaaS integrations, API clients, or developer tools until you trace what they launch, authenticate with, and control. The practical discovery problem is to separate a normal application component from software that can plan, call tools, and act without a current business owner watching it.

That means inventory has to go beyond installed software. Teams need to correlate runtime behavior, identity artifacts, network calls, and orchestration footprints, then ask whether the system is capable of independent action rather than just scheduled execution.

One useful starting point is to compare what you believe exists with what agentic systems actually look like in operation, especially where autonomy, delegated authority, and tool use blur the line between application and actor. NHIMG’s AI Agents vs Agentic AI is helpful here because it clarifies why some systems are easier to classify as ordinary automation while others behave like agents with real execution authority.

Which signals usually reveal an unmanaged agent?

The strongest signals come from places where autonomous behavior leaves an identity or control trail. Cloud and application inventory can show unregistered services, API gateways can show unusual tool-calling patterns, IAM and PAM records can reveal delegated access that has no named owner, and endpoint telemetry can expose local runtimes, browser-based automations, or CLI-driven agents that never passed through formal procurement.

Discovery becomes much more reliable when these signals are correlated. A single token or service account is only a clue, but a token plus a runtime process plus repeated API use against business systems is a much stronger indicator that an unmanaged agent exists and is active.

For teams building this detection capability, the Shadow AI and AI Agent Discovery Guide is directly relevant because it organizes discovery around the exact telemetry classes teams actually have to combine: OAuth grants, API keys, cloud, endpoint, and network signals.

What a complete inventory should record once you find one

Discovery is incomplete if it stops at naming the agent. A useful inventory has to describe who owns it, what data it can reach, what tools it can invoke, and what authority it is using to do that work. Without those fields, teams may know an agent exists but still be unable to judge whether it is safe, supported, or over-privileged.

The operational question is not just “does this agent exist?” but “what can it do if it is compromised, misconfigured, or left running after its sponsor forgets it?” That is why the inventory should include delegated permissions, secrets, connected systems, and the conditions under which access should be reviewed or revoked.

That ownership and permission picture is exactly the kind of control surface covered by NHIMG’s AI Agent Authorisation Guide, which is useful once discovery turns into a decision about least privilege and per-action policy.

How discovery turns into control, not just a spreadsheet

The goal of discovery is to produce an inventory that can drive governance and containment. If a team cannot map an agent back to a business owner, a valid use case, and a revocation path, the agent is effectively unmanaged even if it appears in a security dashboard. Discovery should therefore feed onboarding, approval, exception handling, and retirement workflows.

Teams also need a way to distinguish a legitimate but undeclared pilot from an agent that has silently accumulated more access over time. That is why the most valuable programs do not rely on one source of truth. They cross-check SaaS admin logs, cloud identities, endpoint activity, and API usage until a coherent picture emerges.

For the broader lifecycle and governance angle, the AI Agent Identity Security Buyer's Guide helps teams think in terms of capability areas, ownership, and evaluation criteria rather than treating discovery as a one-off hunt.

Risk and Threat Considerations

Unmanaged agents create hidden exposure because they can keep acting long after the team that created them has moved on, changed tools, or lost track of the credentials they use. The main risk is not simply inventory blind spots, it is unreviewed authority that can reach production data, external services, or administrative APIs without a clear business owner.

Failure mechanism: An agent may inherit broad tokens, service account permissions, or connected SaaS access, then continue operating as if it were sanctioned even after the original project is abandoned or repurposed.

Impact: That can lead to unauthorized data access, accidental destructive actions, unbounded API consumption, or a larger compromise blast radius if the agent credentials are stolen or misused.

Practitioner Guidance

What to prioritise: Start with the telemetry that is hardest for an unmanaged agent to hide, especially cloud identity events, API gateway logs, endpoint process telemetry, and software asset inventories. If those sources disagree, investigate the gap before trusting any single inventory view.

What to verify: For each suspected agent, confirm a human owner, the source of its credentials, the systems it can reach, and whether its permissions are still justified by an active business purpose. If any of those answers are missing, treat the agent as an exception pending review.

Practitioner takeaway: Discovery is only useful when it produces a defensible ownership and access picture, because unmanaged agents become a security problem the moment their runtime capability outruns their governance.

Related resources from NHI Mgmt Group

• AI Agents
• Unmanaged AI
• Why is single-provider AI agent governance not enough for enterprise security?
• How should organizations approach the governance of AI agents?