Subscribe to the Non-Human & AI Identity Journal

Should organisations treat agent discovery as part of IAM or platform operations?

They should treat it as both, but with identity governance ownership. IAM defines the policy logic, platform teams maintain the registries, and security teams validate coverage. If the work sits only in operations, it becomes an asset inventory. If it sits only in IAM, it misses the runtime changes that matter.

Why This Matters for Security Teams

agent discovery is not just a catalogue problem. For autonomous and semi-autonomous workloads, discovery determines what can be governed, what can be monitored, and what can be revoked when behaviour changes. If an agent registry is stale, IAM policy may be technically correct and still miss the real attack surface. That is why NHI Management Group treats discovery as a governance control, not a one-time inventory exercise, as reinforced by the Ultimate Guide to NHIs — Key Challenges and Risks.

The operational risk is straightforward: undiscovered agents cannot be assigned ownership, bounded privileges, or lifecycle rules. Once a workload starts chaining tools, calling APIs, or spawning downstream identities, the absence of discovery becomes an access-control failure. Current guidance from the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026 points to continuous visibility and runtime accountability, not static registries alone. In practice, many security teams discover missing agents only after a secret leak, a tool-chain abuse incident, or an ownership dispute has already slowed containment.

How It Works in Practice

In mature environments, agent discovery is shared work with clear boundaries. Platform teams maintain the source registries where agents are deployed, IAM defines the policy logic for who or what may act, and security validates that the discovered set matches runtime reality. Discovery should capture more than a name and owner. It should capture the workload identity, execution environment, tool permissions, secret dependencies, and the systems an agent can invoke.

That is where runtime evidence matters. Discovery workflows often combine cloud inventory, service mesh telemetry, CI/CD metadata, and identity signals from workload identity systems such as SPIFFE-based attestations or OIDC-backed tokens. The point is to prove what the agent is at the moment it requests access, not merely what someone recorded at deployment time. This aligns with the governance direction described in the Ultimate Guide to NHIs and the implementation risks highlighted in the OWASP NHI Top 10.

  • Keep a canonical agent registry, but tie each entry to live telemetry and ownership metadata.
  • Require every discovered agent to map to a workload identity and an approved policy set.
  • Trigger review when an agent gains a new tool, API scope, environment, or downstream identity.
  • Reconcile IAM entitlements against the registry on a schedule and after major releases.

Discovery should also feed lifecycle controls, because undocumented agents cannot be rotated, offboarded, or investigated reliably. The model is most effective when it is continuous and policy-driven, not when it is a periodic spreadsheet cleanup. These controls tend to break down in highly dynamic CI/CD environments because ephemeral agents appear and disappear faster than manual registry updates can keep pace.

Common Variations and Edge Cases

Tighter discovery often increases operational overhead, requiring organisations to balance visibility against delivery speed. That tradeoff is real, especially in platform teams supporting multiple clouds, short-lived build agents, or autonomous workflows that spawn temporary sub-agents. Current guidance suggests treating those environments as higher-risk, not as exceptions to governance.

One common edge case is a developer-created agent that runs outside the approved platform path. Another is a vendor-managed agent embedded in a SaaS integration, where discovery may rely on contractual metadata and API logs rather than internal deployment records. There is no universal standard for this yet, but the emerging best practice is to distinguish between registration, verification, and runtime discovery. Registration says the agent exists. Verification says it is approved. Runtime discovery says it is still there and still doing what was approved.

Security teams should also assume discovery gaps will be exposed first in incident response, not in audits. The Ultimate Guide to NHIs — 2025 Outlook and Predictions and the CSA MAESTRO agentic AI threat modeling framework both reflect the same operational reality: if discovery is not continuous, every downstream control becomes weaker.

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 Agent discovery supports visibility into autonomous agent attack surfaces.
CSA MAESTRO MAESTRO emphasizes modeling and tracking agent behavior across workflows.
NIST AI RMF GOVERN AI RMF governance requires accountability and traceable system inventory.

Continuously enumerate agents, their tools, and their runtime permissions.