Use identity and telemetry correlation to look for agents that authenticate, retrieve secrets, assume roles, or call APIs without a matching onboarding record. The goal is to identify active non-human identities before they become blind spots in governance. Every discovered agent should be assigned an owner, a scope, and a review path.
Why This Matters for Security Teams
Undeployed AI agents are not just an inventory problem. They are a governance gap: if an agent can authenticate, fetch secrets, assume roles, or invoke APIs without a matching onboarding record, then the organisation has already lost the ability to explain its own access posture. That is why discovery must focus on identity and telemetry correlation, not only CMDBs or procurement logs. Current guidance from the OWASP Agentic AI Top 10 and NHI research such as Top 10 NHI Issues points to the same operational reality: autonomous identities often emerge through toolchains, CI/CD, and secret sprawl rather than formal launch processes.
One useful benchmark comes from NHIMG research: the AI Agents: The New Attack Surface report found that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a compliance and breach-investigation blind spot. In practice, many security teams encounter rogue agents only after they have already touched sensitive systems, rather than through intentional asset discovery.
How It Works in Practice
Discovery starts by treating every AI agent as a non-human identity with observable behaviour. Security teams should correlate identity events, secret access, and runtime telemetry across identity providers, vaults, cloud logs, API gateways, and orchestration platforms. If a service principal, workload token, or key is active but no owner or approval record exists, that identity should be classified as an undocumented agent until proven otherwise.
The most effective searches look for patterns that humans rarely trigger at machine speed. For example, repeated short-lived token minting, access to model endpoints, retrieval from secret managers, role assumption chains, and bursty API calls across multiple services can indicate autonomous execution. This is where the difference between static IAM and workload identity matters: an agent is better discovered by what it proves it is, not by a name in a ticket. Standards such as the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework both support a runtime-first view of AI risk rather than a paper-only inventory.
- Match cloud service principals, workload identities, and API keys to procurement, change, or platform onboarding records.
- Flag identities that access secrets, model endpoints, or privileged APIs without an owner or a documented purpose.
- Review token issuance patterns, unusual TTLs, and role chaining to separate agents from normal service accounts.
- Require each discovered agent to receive an owner, an approved scope, and a review cadence before continued use.
NHIMG guidance in the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs — 2025 Outlook and Predictions reinforces that lifecycle ownership is the control point that turns discovery into governance. These controls tend to break down in multi-cloud environments with duplicated identities, unmanaged sandboxes, and shared automation accounts because telemetry is fragmented across too many control planes.
Common Variations and Edge Cases
Tighter discovery often increases operational overhead, requiring organisations to balance visibility against false positives and analyst fatigue. That tradeoff is real, especially where platform teams create ephemeral agents for testing, code generation, or incident response and forget to retire them. Current guidance suggests classifying first and deleting later, because immediate removal can break production workflows if the identity is actually tied to automation.
Edge cases usually appear when an agent is hidden inside a broader workload, such as a CI job, a browser automation runner, or a multi-agent pipeline. In those environments, no single login event proves “this is an AI agent.” Instead, teams should combine runtime clues: model API calls, secret fetches, tool invocation chains, and unusual delegation behaviour. The AI LLM hijack breach and DeepSeek breach illustrate why secret exposure and uncontrolled automation can quickly become identity problems.
There is no universal standard for agent discovery yet, so the practical approach is to build a repeatable triage loop: detect, enrich, assign, and review. Where teams already use the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework, the most durable pattern is to treat every unidentified autonomous identity as a governance exception until its provenance is established.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Addresses undiscovered agent behaviours and runtime abuse paths. |
| CSA MAESTRO | MT-1 | Supports threat modeling for autonomous agent identity and access paths. |
| NIST AI RMF | Governance and mapping functions fit undocumented agent discovery and ownership. |
Establish an inventory, assign accountable owners, and review undocumented agents through a formal risk process.
Related resources from NHI Mgmt Group
- How should security teams manage permissions for AI agents?
- How should security teams govern AI agents that use OAuth access?
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams govern AI agents that can access enterprise systems?
