If you cannot tell how many service accounts, secrets, or shadow agents exist, discovery is the first problem. If agents are already reaching production and nothing checks each call, runtime enforcement is the immediate gap. Many mature programmes need both, but the operational priority depends on whether the bigger failure is visibility or control.
How teams decide whether the gap is discovery or enforcement
The decision starts with observability. If you cannot answer basic inventory questions, such as how many service accounts, secrets, token paths, or shadow agents exist, then discovery is the limiting control because you do not yet know what must be governed. If the estate is already known and agents are executing production actions without call-level checks, runtime enforcement is the control gap.
That distinction matters because these two problems fail differently. Discovery reduces uncertainty about what exists and where it lives, while runtime enforcement reduces the chance that an approved agent can overreach, misuse credentials, or keep acting after its context changes. Teams that confuse the two often buy controls in the wrong order and still leave the bigger risk untouched.
For agentic AI programmes, discovery is usually about scope, ownership, and exposure: what identities exist, which ones are real, which are duplicated, and which ones were created faster than governance can track. Runtime enforcement is about whether each tool call, delegation, and action is checked against policy in the moment. Ultimate Guide to NHIs is the right conceptual anchor when the problem is still “what are we even managing?”
When discovery is the first control to fix
Discovery comes first when the team cannot produce a defensible inventory or ownership model. That includes unknown service accounts, unmanaged secrets, untracked agent identities, or environments where integrations have proliferated faster than approval and review processes. In that state, runtime enforcement may exist in theory, but it cannot be trusted because the control surface itself is incomplete.
Discovery also becomes the priority when the main failure mode is blind spots rather than misuse. If teams do not know where identities are embedded, they cannot assess lifecycle, rotate credentials, retire orphaned access, or determine whether an agent is operating under an approved or accidental identity. Service Account Security Guide and NHI Ownership and Accountability Guide both map to this stage because ownership and inventory are the first prerequisites to control.
A useful test is whether the team can answer three questions without guesswork: what exists, who owns it, and what depends on it. If any of those answers require log spelunking or tribal knowledge, discovery is not complete enough to support strong runtime policy.
When runtime enforcement is the immediate gap
Runtime enforcement is the priority when inventory is good enough to know the major actors, but the system still allows unrestricted or poorly bounded execution. That is common when agents already have access to production systems, call APIs, invoke tools, or use delegated credentials without per-action authorization, step-up checks, or policy decisions at the point of use.
This is the stronger signal that governance has moved past “find everything” and into “constrain what happens next.” It often shows up when the team can name the agent, the service account, and the integration path, yet cannot say who approves a tool call, what blocks sensitive actions, or how to stop a rogue sequence once it starts. Agentic AI Identity Guide is useful here because the issue is not discovery alone, but how agent identity, delegation, and retirement are controlled across the action lifecycle.
Runtime enforcement is also the right priority when the main risk is blast radius. If one compromised agent credential can fan out across systems, or if a single prompt-to-tool chain can trigger irreversible change, then the missing control is not more cataloging. It is bounded execution, explicit authorization, and narrow privilege at the moment of action.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Agent and service-account retirement is part of discovery and lifecycle control. |
| NHI-02 — Secret Leakage | Discovery is needed when secret sprawl prevents knowing what exists and where it lives. | |
| Recommendation — Inventory and retire obsolete NHIs before tightening runtime policy. Find exposed secrets first, then enforce narrower runtime use paths. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Runtime enforcement is needed when agents can act with excess authority at call time. |
| ASI02 — Tool Misuse | The question hinges on whether production tool calls are bounded or unchecked. | |
| Recommendation — Constrain agent privileges and require policy checks before sensitive tool use. Add runtime guardrails around tool invocation and sensitive actions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Discovery and enforcement both depend on knowing and managing secrets, tokens, and other authenticators. |
| AC-6 — Least Privilege | Runtime enforcement is about limiting what a known agent may do once it is authenticated. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Teams need evidence to confirm whether discovery gaps or runtime gaps are driving risk. | |
| Recommendation — Track authenticator lifecycle and revoke unmanaged credentials quickly. Restrict agent permissions to the minimum actions needed. Review logs to distinguish inventory blind spots from control failures. | ||
Practitioner Guidance
What to prioritise: Use the simplest indicator that separates the two cases. Unknown estate size, unknown ownership, or unknown secret sprawl points to discovery first. Known estate, known agents, but weak approval or checking at call time points to runtime enforcement first.
What to verify: Ask whether you can trace an agent from registration to retirement, and whether every production action has a policy check, owner, or approval boundary. If the answer is “partly” in both cases, treat the weaker side as the current constraint rather than assuming one control can compensate for the other.
Common mistake: Teams often buy enforcement tooling before they can inventory identities, then discover they cannot scope policy, measure coverage, or retire exceptions confidently. The better sequence is to stabilize the identity picture first when visibility is weak, then tighten runtime control where action risk is highest.
Practitioner takeaway: Discovery is the answer to “what do we have?”, runtime enforcement is the answer to “what may it do now?” If you cannot answer the first cleanly, start with inventory and ownership; if you can, but the agent can still act too freely, move immediately to policy at runtime.