Shadow agents, vendor-supplied agents, and remote agents stay outside the control set even when they reach the same sensitive data. That produces false confidence in governance coverage, weakens access review quality, and makes containment harder because operators do not know the full agent fleet. Discovery must follow the traffic and the source inventory, not just internal approvals.
Why This Matters for Security Teams
Limiting discovery to one platform creates a governance blind spot, not a complete inventory. Agents can be deployed through CI/CD, SaaS automation, browser extensions, vendor workflows, and remote toolchains that never pass through the chosen control plane. That means approvals, access reviews, and containment decisions are all based on partial data. The result is not just weaker visibility, but a false sense of control that persists until an incident forces a broader search.
This risk is especially acute for non-human identities because service accounts, API keys, and automation tokens often outnumber human identities by a wide margin, and NHIMG’s Ultimate Guide to NHIs — 2025 Outlook and Predictions notes that only 5.7% of organisations have full visibility into their service accounts. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point to the same practical issue: if discovery does not follow actual execution and data movement, governance cannot be trusted.
In practice, many security teams discover the missing agents only after a data access review, incident response, or vendor audit exposes them.
How It Works in Practice
Effective discovery starts with the traffic and the source inventory, not the platform approval list. For agentic systems, that means correlating identity data, runtime telemetry, secret usage, and tool invocation logs across every execution environment. The goal is to identify what exists, what can act, and what can reach sensitive data, even when the agent is outside the primary platform.
A practical discovery model usually combines four inputs:
- Identity sources such as IAM, cloud roles, service accounts, and workload identities.
- Runtime signals such as API calls, tool access, browser automation, and outbound network paths.
- Secret inventory from vaults, code repositories, CI/CD systems, and endpoint stores.
- Business ownership metadata so each agent can be assigned to a team and a purpose.
This approach aligns with CSA MAESTRO agentic AI threat modeling framework, which treats agent behaviour as a runtime security problem, and with NHIMG’s Analysis of Claude Code Security, which shows why developer-facing agent activity can blur the boundary between normal automation and unauthorized execution. Discovery also needs to account for third-party and remote agents because vendor-supplied automation can inherit access paths that internal teams never explicitly approved.
Once discovery is broadened, security teams can compare what is discovered against what is formally approved, then close gaps through offboarding, key rotation, containment policies, and segmented trust boundaries. These controls tend to break down when agents are spawned dynamically by users, copilots, or vendors because their identities are short-lived, distributed, and not registered in a single authoritative system.
Common Variations and Edge Cases
Tighter discovery often increases operational overhead, requiring organisations to balance completeness against the cost of continuous telemetry collection and identity correlation. That tradeoff matters because not every environment exposes the same signals, and some agent fleets live in places where full inspection is difficult or politically sensitive.
Best practice is evolving for hybrid and multi-vendor estates. A single platform may still be useful as a control anchor, but it should not be treated as the system of record. In practice, some agents will be invisible to platform-native discovery until they interact with a downstream service, a browser session, or an external API. Guidance from the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026 is clear that governance should be risk-based, but there is no universal standard for full agent discovery yet.
Where the environment includes shadow IT, vendor-managed automations, or rapidly changing agent toolchains, discovery must be repeated continuously rather than assumed from a one-time approval process. That is why NHIMG’s broader NHI research remains useful: discovery failures are often an access problem first and a tooling problem second.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Discovery gaps create unseen agent access paths and shadow execution. |
| CSA MAESTRO | TM-1 | MAESTRO centers runtime threat modeling for autonomous agent behavior. |
| NIST AI RMF | GOVERN | AI RMF governance requires accountable visibility into AI system operation. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Undiscovered agents are unmanaged NHIs with hidden credentials and privileges. |
| NIST CSF 2.0 | DE.CM-1 | Continuous monitoring is required to detect assets outside the approved platform. |
Continuously discover service accounts, API keys, and workload identities across all platforms.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
