Agent discovery tells you what exists and where it runs. Runtime enforcement tells you what it is allowed to do while it is active. Discovery without enforcement leaves visibility without control, while enforcement without discovery leaves unknown identities outside governance. Mature programmes need both because AI agent risk is both an inventory problem and a behaviour problem.
Why This Matters for Security Teams
Agent discovery and runtime enforcement solve different problems, and confusing them creates blind spots. Discovery is about inventory, lineage, and ownership: which agents exist, what credentials they use, and which tools they can reach. Enforcement is about active control: stopping an agent from taking an action that exceeds policy, context, or intent. That distinction matters more for autonomous software than for human users because agents can chain tools, switch tasks, and execute at machine speed. Current guidance in OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward governance that is continuous, not one-time.
NHIMG research shows why inventory alone is not enough: only 5.7% of organisations have full visibility into their service accounts, yet 97% of NHIs carry excessive privileges, according to the Ultimate Guide to NHIs — 2025 Outlook and Predictions. In practice, many security teams encounter abuse only after an agent has already overreached, rather than through intentional discovery and policy design.
How It Works in Practice
Discovery should build a live map of every agent identity, workload identity, secret source, and tool connection. That includes where the agent runs, which APIs it can call, and whether credentials are static, JIT-issued, or inherited from a broader workload. Enforcement then sits in the request path and checks the action, not just the identity. For agentic systems, that usually means policy-as-code, context-aware approvals, and short-lived credentials tied to a specific task. The emerging pattern is intent-based authorisation: the agent may be known and trusted for one goal, but still blocked from a different operation at runtime.
Practitioners should treat discovery as the control plane for visibility and enforcement as the guardrail for behaviour. A workable design often includes:
- workload identity for cryptographic proof of what the agent is, not just what token it holds
- JIT credential provisioning with tight TTLs for task-bound access
- runtime policy evaluation against tool, data, and destination context
- revocation and step-up checks when an agent changes scope or risk level
This aligns with CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix, which both emphasise behaviour, chaining, and abuse paths that static IAM does not catch. It also matches the control focus in OWASP NHI Top 10 and the operational lessons in Analysis of Claude Code Security.
These controls tend to break down when an agent can invoke unmanaged side channels, because policy engines only protect the paths they can observe.
Common Variations and Edge Cases
Tighter runtime enforcement often increases latency and operational overhead, requiring organisations to balance safety against developer velocity and agent usefulness. There is no universal standard for this yet, especially for multi-agent systems where one agent delegates to another or where tool use is highly dynamic.
One common edge case is read-only discovery data that looks clean while the agent still has dangerous downstream influence through prompts, webhooks, or chained tool calls. Another is environments that rely on long-lived secrets embedded in CI/CD or code, where discovery can identify the asset but cannot safely constrain the resulting behaviour. NHIMG research shows why this matters: 96% of organisations store secrets outside secrets managers, and 71% of NHIs are not rotated within recommended time frames, which makes runtime enforcement much harder to trust. For deeper background, see the Top 10 NHI Issues and Moltbook AI agent keys breach.
Best practice is evolving, but the practical rule is simple: discovery answers “what is here?”, while enforcement answers “what may it do right now?”. Organisations that only do discovery tend to build dashboards. Organisations that only do enforcement tend to miss hidden identities. Mature programmes need both, plus ownership, revocation, and continuous policy review.
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 | NHI-01 | Agent discovery and runtime control are core agentic identity risks. |
| CSA MAESTRO | MAESTRO focuses on agent threat modeling and runtime abuse paths. | |
| NIST AI RMF | AI RMF supports governance, mapping, and continuous monitoring of agent behaviour. |
Inventory every agent identity and enforce task-scoped policy at request time.
Related resources from NHI Mgmt Group
- What is the difference between human identity governance and AI agent governance?
- What is the difference between governing human access and governing AI agent access?
- What is the difference between prompt-based safety and hard runtime boundaries?
- What is the difference between managed identities and hardcoded secrets for AI agents?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
