Finding an agent tells you that it exists. Governing it requires ownership, approval status, credential visibility, access scope, and a review process that can remove or restrict it when conditions change. Discovery is the input; governance is the decision system that makes the discovery operational.
Why This Matters for Security Teams
Finding an AI agent is a cataloguing problem. Governing it is a security and operational control problem. That difference matters because autonomous systems can act faster than review cycles, chain tools, and expand access in ways traditional IAM never assumed. Current guidance suggests treating agents as workloads with execution authority, not as static users with a neat role profile. NIST’s NIST AI Risk Management Framework is useful here because it frames governance as a lifecycle discipline, not a one-time registration event.
NHIMG research shows why this distinction is urgent: in SailPoint’s AI Agents: The New Attack Surface report, 92% of respondents said governing AI agents is critical, yet only 44% had implemented policies. That gap is where discovery turns into exposure. If a team can list agents but cannot name owners, credentials, or permitted actions, it does not have governance, only visibility. In practice, many security teams encounter misuse only after an agent has already exceeded scope, rather than through intentional approval and review.
How It Works in Practice
Effective governance starts by attaching decision points to each agent: who owns it, what task it is allowed to perform, which data it can reach, and what evidence proves it should still exist. Discovery feeds the inventory; governance enforces the rules. That means the agent’s identity should be tied to workload identity rather than a human-style account, with cryptographic proof of what the agent is. In practice, this often means SPIFFE-style identities or OIDC-backed service tokens, paired with policy evaluated at request time rather than broad standing access.
For autonomous and goal-driven workloads, static RBAC is usually too blunt. An agent may need one permission for a single workflow step and none after it completes. That is why JIT credential provisioning and short-lived secrets matter. Credentials should be issued per task, scoped tightly, and revoked automatically when the job ends. The principle is simple: discovery tells you the agent exists; governance decides whether its current intent, context, and privileges still justify access.
- Use owner assignment and approval status as mandatory metadata for every agent.
- Map agent actions to explicit policy, not to broad human role assumptions.
- Prefer ephemeral secrets and JIT access over long-lived static credentials.
- Review tool use, data access, and external connections continuously.
For threat modelling, align the control model with OWASP Top 10 for Agentic Applications 2026 and NHIMG’s OWASP NHI Top 10, because both point to the same operational reality: agents can route around assumptions by chaining tools, persisting state, and reusing access in ways humans do not. These controls tend to break down when agents are given persistent credentials inside loosely segmented environments because privilege accumulates faster than review can remove it.
Common Variations and Edge Cases
Tighter governance often increases friction, requiring organisations to balance speed against control. That tradeoff is real, especially in research environments, developer sandboxes, and multi-agent pipelines where agents are spawned and retired frequently. Best practice is evolving, and there is no universal standard for how much autonomy should be allowed without human approval. For high-risk workflows, many teams now use policy-as-code and real-time authorisation decisions, but the exact policy engine is less important than the discipline of evaluating intent at request time.
Edge cases appear when an agent is partially autonomous, such as a copilot that can execute commands only after a human click, or when multiple agents share one orchestrator. In those cases, governance must separate the orchestrator’s privileges from each agent’s actual action scope. NHIMG’s AI LLM hijack breach and DeepSeek breach pages show why long-lived secrets and weak visibility create downstream abuse when access is reused outside its original purpose. External models like the CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework help structure that decision-making, but they do not replace a clear operational owner. The hard part is not finding the agent. It is proving, continuously, that the agent still deserves the access it has.
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 | A03 | Agentic apps need runtime authorization, not static roles. |
| CSA MAESTRO | MAESTRO-5 | MAESTRO addresses agent identity, tools, and dynamic control. |
| NIST AI RMF | GOVERN | AI RMF GOVERN covers ownership and accountability for agents. |
Enforce request-time policy checks for each agent action and revoke access when intent changes.
Related resources from NHI Mgmt Group
- What is the difference between governing human access and governing AI agent access?
- What is the difference between scanning AI-generated code and governing AI agent identity?
- What is the difference between human identity governance and AI agent governance?
- What is the difference between attack surface management and NHI governance?
