Which governance model should organisations use when humans and AI agents can both trigger security and compliance risk?

Why This Matters for Security Teams

A unified governance model matters because humans and AI agents can now exercise similar risk pathways: requesting access, moving data, triggering workflows, approving actions, and calling tools. When governance treats those actors separately, policy gaps appear at the exact point where accountability should be strongest. The right model aligns identity, privilege, monitoring, and escalation so risk decisions follow the action, not just the actor category. That is consistent with the direction of the NIST Cybersecurity Framework 2.0, which emphasises governance as an organising function rather than a side control.

For security leaders, the practical issue is not whether an AI agent is “trusted” in the abstract. It is whether the organisation can answer who or what initiated the action, what authority was used, what data was touched, and what should happen next if the action looks abnormal. That becomes especially important when agents are embedded in IT, SOC, finance, procurement, or customer operations, because a single workflow can carry both compliance and security risk. In practice, many security teams encounter this only after an agentic workflow has already triggered an unauthorised change, rather than through intentional governance design.

How It Works in Practice

A workable governance model starts by treating humans, service accounts, and AI agents as distinct identity classes under one control plane. The policy decision is unified, but the control treatment can differ. Humans may be subject to MFA, training, and attestation. AI agents may require workload identity, tool-scoped permissions, policy-bound prompts, approval gates, and immutable logs. The key is that all of them are evaluated against the same business risk framework and the same audit expectations.

Security teams usually implement this in four layers:

• Identity and authority: define who can create, delegate, or revoke agent capabilities, and bind that authority to the same governance structure used for privileged human access.
• Action controls: restrict what an agent can do by tool, data domain, environment, and time window, using least privilege and just-in-time access where feasible.
• Monitoring and evidence: log prompts, tool calls, approvals, policy violations, and downstream outcomes so investigations can reconstruct both intent and effect.
• Risk response: route anomalous agent behaviour into the same incident, fraud, or compliance workflow used for people, with escalation thresholds based on impact.

This approach aligns well with NIST AI Risk Management Framework because it separates governance, mapping, measuring, and managing risk rather than assuming the model itself is safe. It also fits the kinds of threats described in the OWASP Agentic AI Top 10, where tool misuse, prompt injection, and excessive agency are core concerns. For broader attack-pattern thinking, the MITRE ATLAS adversarial AI threat matrix helps teams model how AI systems are manipulated before the organisation sees a security incident.

Operationally, the governance workflow should also define decision ownership. A risk committee may set policy, but product owners, security operations, and compliance teams need clear thresholds for pause, rollback, or human review. These controls tend to break down in highly delegated environments where agents can chain actions across SaaS platforms and internal APIs without a single authoritative control point.

Common Variations and Edge Cases

Tighter governance often increases workflow friction, so organisations need to balance speed against assurance. That tradeoff becomes visible when agents are used for low-risk automation versus high-impact actions such as payments, privileged configuration, or regulatory submissions. Current guidance suggests that the stricter the downstream consequence, the more explicit the approval, logging, and revocation controls should be. There is no universal standard for this yet, especially for fully autonomous agents.

Edge cases usually arise in hybrid environments. A human may approve an action that an agent executes later, or an agent may act inside a broader human ticketing process. In those situations, governance should not ask only who clicked the button. It should determine who authorised the capability, who monitored the execution, and who is accountable if the resulting outcome violates policy. This is where identity governance and agent governance intersect most clearly.

Another common exception is vendor-managed or embedded AI features. If the organisation cannot inspect logs, constrain tools, or set policy thresholds, the governance model should treat the feature as a third-party risk issue rather than a standard internal agent. For practitioners, the cleanest test is simple: if the system can cause security or compliance impact, it belongs in the same risk register, even if its operator is not human. That principle is reinforced by the control direction in NIST SP 800-53 Rev 5 Security and Privacy Controls and by governance expectations in ISO/IEC 27001:2022 Information Security Management.

Related resources from NHI Mgmt Group

• Should organisations use the same access model for humans and AI agents?
• Should organisations use one governance workflow for humans, NHIs, and AI agents?
• Why do AI coding agents create security risk even when they use the same model?
• Why do AI agents using Model Context Protocol create new governance risk for compliance programmes?