Infrastructure. Documentation helps, but it does not enforce constraints, preserve state, or create an audit trail. If organisations rely on markdown alone, governance becomes fragile and person-dependent. The stronger model is to make identity, authorisation, and observability part of the platform layer itself.
Why this is an infrastructure question, not a document management question
agent governance only becomes durable when it changes system behaviour. That means the controls have to live in the platform layer, where identity, authorisation, policy enforcement, logging, and runtime checks can actually constrain what an agent can do. A document can describe the rules, but only infrastructure can apply them consistently when a workflow, tool call, or delegation event happens.
That distinction matters because agents are not static processes with fixed permissions. Their authority can change by task, context, and delegation chain, so governance has to be enforced at the point of action. When governance is embedded in the runtime, it can limit scope, block unsafe actions, and preserve evidence of who or what exercised authority.
Documentation still has value, but its value is interpretive rather than preventive. It helps teams define intent, explain policy, and record accountability, yet it cannot by itself stop privilege creep, detect abuse, or keep controls consistent across environments. For that reason, agent governance should be treated as an operational control plane, not a policy binder.
What has to sit in the platform layer for governance to work
The practical minimum is identity-aware enforcement. The system needs to know which agent is acting, which principal it is acting for, what it is allowed to do, and under what conditions approval is required. That includes per-action checks, scoped credentials, and a real audit trail that links requests to outcomes.
Observability is part of the same control model. If you cannot see tool use, delegated actions, or escalation events, you cannot prove that governance worked or reconstruct what happened after a failure. AI Agent Observability, Audit and Incident Response Guide is useful here because it treats logs, attribution, and kill switches as operational requirements rather than optional reporting.
Authorisation also has to be dynamic. For many agent workflows, standing access is too broad and too persistent. A better model is task-scoped access with explicit approval gates, which aligns governance to the action being requested instead of a static role definition. AI Agent Authorisation Guide covers that control model directly, including per-action policy decisions and least privilege.
What breaks when governance is only written down
Document-only governance usually fails at the first operational boundary. The document may say an agent should request approval, but the runtime may still hold broad tokens, reuse credentials, or invoke tools without a policy gate. In that case, the real control is whatever the platform allows, not what the policy says.
It also fails under scale. Once multiple teams, connectors, and environments are involved, markdown cannot reliably encode every exception, dependency, and approval path in a way that is both current and enforceable. Zero Trust for AI Agents is relevant because it frames the operational answer as continuous verification and removal of standing privilege, not policy aspiration.
Finally, document-only governance creates a false sense of control. Teams may believe they have a process because they have a document, but the meaningful question is whether the agent’s authority is bounded at runtime, whether the audit trail is complete, and whether exceptions are visible before damage occurs. If the answer to any of those is no, the governance model is still manual and fragile.
Risk and Threat Considerations
When governance depends on documentation alone, the main risk is that policy and execution drift apart. That creates hidden privilege, inconsistent approvals, and weak attribution, which are exactly the conditions that make agent abuse or accidental overreach hard to detect and contain.
Failure mechanism: The agent inherits or reuses access that was described in policy but never technically constrained, so tool calls, delegated actions, or cross-system requests can proceed outside the intended approval path.
Impact: Teams lose the ability to prove who authorised an action, what scope was in force, and whether a harmful action was preventable. At that point, incident response, auditability, and containment all become slower and less reliable.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent governance must prevent unauthorized authority growth at runtime. |
| ASI02 — Tool Misuse | Governance needs runtime control over agent tool use, not just written policy. | |
| ASI09 — Human-Agent Trust Exploitation | Document-only governance fails when humans trust agent actions without technical enforcement. | |
| Recommendation — Enforce per-action authorization and bounded agent privilege. Gate tool calls with policy checks and approval where needed. Require technical controls that validate agent actions before execution. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Agent permissions should be constrained to the minimum required authority. |
| AU-2 — Audit Events | Governance depends on a durable audit trail of significant agent actions. | |
| IA-5 — Authenticator Management | Agent governance depends on managing the secrets and tokens that enable access. | |
| Recommendation — Apply least privilege to all agent credentials and delegated access. Log agent actions and authorization decisions as required audit events. Rotate and bound agent authenticators used for delegated access. | ||
| NIST Zero Trust (SP 800-207) | N/A — Never Trust, Always Verify | Agent governance needs continuous verification of identity, request, and privilege. |
| Recommendation — Verify each agent request before granting access or action. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The question centers on making identity and authorisation part of the platform layer. |
| Recommendation — Embed identity and access control into the agent runtime. | ||
Practitioner Guidance
What to prioritise: Start with the controls that actually limit and evidence agent action, especially identity binding, per-action authorisation, and logging of every materially significant tool call. If those are not in place, governance is mostly narrative.
What to verify: Confirm that policy decisions are enforced by the platform, not just documented in a process repo. A good test is whether a denied action is technically impossible, not merely disallowed on paper.
Common mistake: Treating the governance document as the control. In practice, the document should describe the operating model, while the platform should carry the enforcement, state, and audit evidence.
Practitioner takeaway: If an agent can still act meaningfully after the documentation is wrong or stale, the real governance boundary is missing, because durable governance lives where authority is enforced and recorded.
Related resources from NHI Mgmt Group
- Why is single-provider AI agent governance not enough for enterprise security?
- When should organisations treat an NHI as a high-priority risk?
- How can organisations reduce the blast radius of compromised agent identities?
- Should organisations prioritise external exposure or internal credential governance first?