How do organisations decide whether agent governance should sit in process or in platform controls?

If the control is important enough to affect access, audit, or production behaviour, it belongs in the platform or an enforced workflow layer, not only in process. Process can support governance, but it should not be the only control. The more privileged the agent, the less acceptable manual-only enforcement becomes.

Why This Matters for Security Teams

agent governance decisions shape whether controls are merely documented or actually enforced when an agent can act, spend, or change production state. The practical risk is that process-only governance creates a gap between policy intent and machine execution. NIST Cybersecurity Framework 2.0 is useful here because it treats governance, risk, and control execution as connected capabilities rather than separate paperwork.

For agentic systems, the question is not whether process matters. It does. But process is a weak control when an agent has standing permissions, tool access, or the ability to trigger downstream automation. That is why the same decision often lands differently for low-risk copilots, high-privilege operational agents, and systems that can alter customer records or infrastructure. Guidance from the OWASP Agentic AI Top 10 reinforces the need to constrain tool use, permissions, and unsafe autonomy at the control layer.

Security teams often get this wrong by treating agent approval, review, and exception handling as sufficient even when the agent can already execute the risky action before anyone reviews the log. In practice, many security teams encounter control failure only after the agent has already used approved access in an unintended way, rather than through intentional governance design.

How It Works in Practice

The decision usually turns on enforceability, auditability, and blast radius. If a governance rule must be obeyed every time, it should live in the platform, identity, policy, or workflow layer where the system can block, throttle, or require step-up approval. If it is mainly about oversight, attestation, or exception management, process can support it, but not replace enforcement. This aligns with the NIST AI Risk Management Framework, which separates governance from operational control implementation and expects risk treatment to be traceable in system design.

A practical test is to ask whether a person can reliably stop the action after the agent starts. If the answer is no, the control belongs in platform logic. For example, permission boundaries, scoped tool credentials, approval gates, policy engines, and immutable audit logs are platform controls. Policy review, periodic sign-off, training, and incident playbooks are process controls. Both matter, but only one prevents execution.

• Use platform controls for actions that affect access, money, production, or regulated data.
• Use process controls for periodic review, exception handling, and governance reporting.
• Prefer enforced workflow gates where agents request, justify, and receive scoped approval before acting.
• Log agent intent, tool invocation, and outcome so reviewers can reconstruct decisions later.
• Map control ownership to existing governance domains, not just AI project teams.

For security operations, the strongest pattern is to pair policy with technical guardrails: constrained identities, zero standing privilege, bounded tools, and alerting for policy drift. The NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls are helpful when translating governance requirements into enforceable control objectives. These controls tend to break down when the agent spans multiple SaaS tools and custom scripts because enforcement becomes fragmented across systems with inconsistent logging and approval behaviour.

Common Variations and Edge Cases

Tighter platform control often increases implementation cost and operational friction, requiring organisations to balance safety against speed of delivery. That tradeoff is real, especially when teams are trying to move from experimentation to production without blocking legitimate automation.

There is no universal standard for this yet, so current guidance suggests using a risk threshold. Low-impact agents can often be governed through process, provided they do not touch sensitive data or privileged actions. High-impact agents should be governed through platform controls first, with process serving as oversight. The more autonomous the agent, the less credible manual review becomes as the primary control.

Edge cases usually appear in shared environments, outsourced operations, and hybrid stacks where one team owns the policy while another owns the execution platform. That split can create false confidence if approvals are documented but not enforced in the actual runtime. The same problem appears with temporary exceptions: if the exception process is faster than the control path, teams will route around governance. For deeper threat modelling of agent misuse and tool abuse, the MITRE ATLAS adversarial AI threat matrix and CSA MAESTRO agentic AI threat modeling framework are useful references. The practical rule is simple: if a failure would be hard to detect, hard to reverse, or costly to explain, it should not rely on process alone.

Related resources from NHI Mgmt Group

• How do organisations decide whether an AI agent needs NHI controls, AI controls, or both?
• How can organisations decide whether an AI agent belongs in PAM, IAM, or NHI governance?
• How should organisations decide whether AI agent access belongs in IAM or separate governance?
• How should organisations decide whether an identity platform supports NHI governance well enough?