What do organisations get wrong when they focus only on discovering AI agents?

Why Discovery Alone Misleads Security Teams

Discovery answers a narrow question: what agents exist right now. It does not answer the harder security questions that determine exposure, such as who approved the agent, which systems it can reach, what secrets it can use, or whether its current behaviour still matches policy. That is why discovery has to be treated as inventory, not governance. The gap is especially visible in agentic systems that can chain tools, move laterally, and change behaviour as prompts, data, and tasks change.

NHIMG research shows the scale of the problem in practice: in AI Agents: The New Attack Surface, SailPoint reports that 80% of organisations say their AI agents have already acted beyond intended scope. That is a lifecycle and control failure, not a discovery failure. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward ongoing oversight, not one-time visibility. In practice, many security teams encounter unauthorised agent behaviour only after data has already moved or credentials have already been reused.

How Mature Programmes Move from Discovery to Control

Discovery becomes useful only when it feeds an operating model for ownership, authorisation, and revocation. For AI agents, that means treating the agent as a workload identity with a defined lifecycle, not as a static app entry in a spreadsheet. Best practice is evolving toward runtime controls that decide access based on intent, context, and task scope rather than a fixed RBAC role assigned at build time.

Practitioners typically layer the following controls:

• Assign an accountable owner for each agent, including business purpose, data scope, and approved tool access.
• Issue short-lived credentials or tokens per task, then revoke them automatically after completion or timeout.
• Use workload identity mechanisms such as SPIFFE or OIDC so the agent proves what it is, not just what secret it holds.
• Evaluate policy at request time with policy-as-code rather than relying on pre-approved access lists.
• Review agent activity continuously for scope drift, unusual tool chaining, and access to secrets or sensitive data.

This is where frameworks like the CSA MAESTRO agentic AI threat modeling framework help, because they force teams to model agent behaviour, tool use, and trust boundaries together. NHIMG’s OWASP NHI Top 10 also reflects the reality that the security issue is not just presence, but privilege, persistence, and misuse potential. These controls tend to break down when agents share credentials across environments, because revocation and attribution become impossible once access is reused outside the original task.

Common Edge Cases and Operational Tradeoffs

Tighter discovery and control often increases operational overhead, requiring organisations to balance faster agent adoption against stronger ownership, review, and revocation discipline. That tradeoff is real, especially in fast-moving product teams where agents are created, cloned, or embedded into workflows without central security review. There is no universal standard for this yet, so current guidance suggests starting with high-risk agents rather than trying to normalise every workload at once.

Edge cases usually appear in environments with shared service accounts, long-lived API keys, or agents that act on behalf of multiple teams. In those settings, discovery may show a small number of agents while the real risk sits in the credentials and connectors they reuse. Secrets sprawl makes that worse, which is why NHIMG’s The State of Secrets in AppSec is relevant here: fragmented secrets management undermines any attempt to tie discovery to accountability. Teams should also watch for shadow agents created in automation platforms, where the agent may be visible to operations but invisible to compliance or legal review.

Discovery is still necessary, but it is only the first control plane. Without periodic access certification, short-lived credentials, and a clear revocation path, discovered agents can remain functionally unmanaged even when they are fully visible.

Related resources from NHI Mgmt Group

• Why do AI agents create more risk when they reuse existing credentials?
• How can organisations prevent AI agents from becoming overprivileged?
• How can organisations govern AI agents that use service accounts and tokens?
• What do organisations get wrong when they secure AI only at the model layer?