Security teams should treat policy as the starting point, not the control. If agentic AI is already in use, governance needs enforcement through access boundaries, auditability, and approval workflows. The practical test is whether teams can prove what the system accessed, what it changed, and who approved the action. Without enforcement, policy becomes documentation rather than risk reduction.
Why This Matters for Security Teams
Policy text does not stop an AI agent from acting; enforcement does. When governance exists only as documentation, agents can still access tools, chain actions, and create changes faster than human review can catch up. That is why security teams need controls that prove the actual decision path, not just the intended one, using auditability, approvals, and runtime boundaries aligned to frameworks such as the NIST AI Risk Management Framework.
NHIMG research shows the gap is operational, not theoretical: in The 2024 ESG Report: Managing Non-Human Identities, 72% of organisations said they have experienced or suspect a breach of non-human identities. That matters here because weak compliance usually means policy was never translated into credential boundaries, workflow gates, or revocation paths. For AI governance, the control objective is not policy existence, but proof that the system could not act outside approved scope.
In practice, many security teams discover that governance was bypassed only after an agent has already accessed a sensitive system, rather than through intentional enforcement design.
How It Works in Practice
Enforcement starts by converting policy into runtime rules that can be evaluated at the moment an agent asks to do something. For agentic AI, static role-based access is usually too blunt because the agent’s behaviour is goal-driven and changes with context. A better pattern is context-aware authorisation with short-lived permissions, task-scoped secrets, and logged approval checkpoints. Current guidance suggests treating the agent as a workload identity, not a human user, and binding actions to cryptographic proof of what the agent is through approaches such as workload identity and ephemeral tokens.
Teams usually need three layers working together:
- Identity proof: issue workload identity for the agent and avoid shared static secrets where possible.
- Policy evaluation: check the request at runtime against data sensitivity, tool risk, and approval status.
- Execution control: limit what the agent can call, record what changed, and revoke access when the task ends.
This is where the details matter. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful because weak lifecycle management often creates the exact gap between policy and practice. On the standards side, the NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control structure to map approvals, logging, and least privilege into enforceable requirements, while the NIST AI 600-1 GenAI Profile helps translate AI-specific risks into governance activities.
These controls tend to break down when agents have direct network reach to multiple internal systems and can chain tool calls across environments because approval boundaries become too fragmented to enforce consistently.
Common Variations and Edge Cases
Tighter governance often increases operational overhead, requiring organisations to balance stronger control with delivery speed. That tradeoff is real, especially where teams rely on automated pipelines, third-party copilots, or multi-agent workflows. Current guidance suggests that the right answer is not to remove automation, but to constrain high-risk actions with step-up approval, short TTL credentials, and immutable logging. The Top 10 NHI Issues is a useful reference point when teams need to prioritise where compliance failures most often surface.
There is no universal standard for this yet, but practical edge cases are becoming clear. Read-only agents still need controls if they can exfiltrate sensitive data. Tools that trigger external side effects need stronger approval than internal search tools. Highly regulated environments may require human sign-off for every material change, while lower-risk workflows may use policy-as-code and post-action review. The NIST AI Risk Management Framework and the EU AI Act both reinforce that governance should be measurable, not aspirational, but neither removes the need for environment-specific enforcement design.
Compliance usually remains weak where approvals live in one system, agent execution happens in another, and no one owns the full audit trail end to end.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A03 | Runtime access control is central when agent actions are dynamic and hard to pre-approve. |
| CSA MAESTRO | GOV-2 | Governance must convert AI policy into enforceable controls and auditability. |
| NIST AI RMF | The AI RMF governs how to manage and measure AI risk when compliance is weak. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Weak secret rotation and overlong credentials undermine policy enforcement. |
| NIST CSF 2.0 | PR.AA-01 | Identity proof and authorization enforcement align with access control expectations. |
Map policy to approvals, logs, and revocation so AI governance is measurable in production.
Related resources from NHI Mgmt Group
- How should security teams govern AI-driven authorization when policy rules have to satisfy both business needs and machine-generated decisions?
- How can security teams measure whether agentic AI is improving identity governance rather than just speeding up requests?
- How should security teams evaluate AI governance certifications when adopting security platforms?
- How should security teams build an AI governance community that keeps improving throughout the year?
