AI agents should be treated as governed actors with identity, access and monitoring requirements, not as a side feature of workforce risk. Once they can take action inside business workflows, their behaviour becomes an operational risk signal. Teams need separate ownership, scoped access and distinct visibility for those actions.
How should AI agents be governed inside human cyber risk programs?
AI agents should not sit outside the governance model just because they are software. Once an agent can act in business processes, it becomes a governed actor with defined ownership, scoped authority, and observable behaviour. The practical question is not whether the agent is “trusted”, but whether its actions are bounded, attributable, and reviewable like any other source of operational risk.
That is why agent governance belongs alongside risk, access, and control ownership. A useful starting point is to treat the agent as an authorised actor, not as a passive model output. If it can trigger payments, approvals, ticket changes, code execution, or customer-impacting workflow steps, those actions need explicit policy, not informal reliance on the surrounding application.
Governance also needs a clear decision boundary. Human teams decide the permitted scope, escalation thresholds, and exceptions; the agent executes within those limits. That is where zero trust for AI agents becomes operationally useful, because it forces continuous verification of the principal, the request, and the context of each action rather than assuming the agent remains safe after initial onboarding.
What visibility and accountability do agents need?
Agent activity should be traceable at the action level, not just logged as generic application noise. If an agent can take steps on behalf of people or systems, the organisation needs to know what it tried to do, what it was permitted to do, and where the workflow was altered by policy, human approval, or failed authorization checks.
That requirement makes identity and monitoring inseparable from governance. A mature model includes agent registration, lifecycle control, and distinct identity handling, as described in the agentic AI identity guide. Without that layer, teams often discover too late that an agent was acting through shared credentials, inherited permissions, or opaque service accounts.
Visibility also has to support incident response, not only auditing. The AI agent observability and incident response guide is relevant because it focuses on attribution, behavioural baselines, and kill-switch readiness. Those are the controls that tell you whether an agent’s actions are still within policy, or whether they have crossed into misuse, overreach, or failure.
How do AI agents change the human risk model?
The main governance shift is that the agent becomes part of the organisation’s operational attack surface and decision surface at the same time. human cyber risk programs usually monitor people, endpoints, and systems separately; agentic workflows collapse those layers because the same actor can interpret context, call tools, and execute changes. That makes over-privilege, misuse, and delegation failures materially more important than model quality alone.
A good control posture therefore starts with the agent’s actual authority, not with its capabilities in theory. The most useful guidance is the AI Agent Authorisation Guide, because it pushes task-scoped access, just-in-time privilege, and per-action policy decisions. Those are the controls that prevent an agent from becoming a standing-risk proxy for a human role or a hidden automation layer with broad business reach.
Teams also need to think about what happens when an agent is treated as “helpful” rather than accountable. The difference between benign assistance and governed action is often where problems begin: an agent may be useful for summarising, but unsafe for executing. The AI Agents vs Agentic AI resource helps separate low-risk assistance from higher-authority workflows, which is important because governance should scale with actionability, not branding.
Risk and Threat Considerations
Agent governance fails when organisations assume that an AI agent’s outputs are the only thing that matters. The real risk is actionability: once the agent can use business tools or inherited access, an attacker, a bad prompt, or a workflow defect can turn ordinary automation into unauthorised change, data exposure, or privilege abuse.
Failure mechanism: Excessive or poorly scoped agent permissions, weak delegation controls, and poor identity separation let an agent perform actions beyond the intended business task, often without a human noticing until after impact.
Impact: The result can be fraudulent transactions, workflow tampering, token theft, hidden lateral movement, or destructive changes that appear to come from legitimate automation rather than a clear attacker.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | AI agents with excess authority create the same privilege risk pattern. |
| NHI-10 — Human Use of NHI | Human governance over agent actions depends on clear delegation and oversight. | |
| Recommendation — Limit each agent to the minimum permissions needed for its task. Separate human approvals from agent-executed actions and keep both auditable. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent governance here is primarily about scoped identity and delegated authority. |
| ASI10 — Rogue Agents | Unowned or unmonitored agents become autonomous operational risk actors. | |
| Recommendation — Enforce per-action authorization and reject requests that exceed delegated privilege. Require ownership, monitoring, and revocation paths for every production agent. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Verify Explicitly | Zero trust is a strong fit for validating each agent request and context. |
| Recommendation — Verify the agent, request, and context before allowing any privileged action. | ||
| NIST AI RMF | GOVERN — Govern | AI agents need organisational governance, accountability, and oversight structures. |
| Recommendation — Assign governance, accountability, and review ownership to the agent program. | ||
| CSA MAESTRO | GOV — Governance | Agentic systems require governance over autonomy, roles, and escalation paths. |
| Recommendation — Define autonomy limits, escalation rules, and owner accountability for each agent. | ||
Practitioner Guidance
What to prioritise: Start with the agent’s authority model before debating model behaviour. If the agent can write, approve, deploy, or transfer value, scope those actions first and treat everything else as secondary.
What to verify: Confirm that each agent has an owner, a bounded purpose, a revocation path, and action-level logging. If any one of those is missing, the organisation does not yet have a defensible governance model for that agent.
Common mistake: Do not govern agents as if they were just another application feature. The moment the system can initiate real-world actions, it needs controls for identity, access, monitoring, and exception handling that match the business impact of those actions.
Practitioner takeaway: The right governance question is not “Can we use AI agents?” but “Which actions can we safely allow, under whose ownership, and with what evidence that the agent stayed inside its limits?”
Related resources from NHI Mgmt Group
- How should organizations approach the governance of AI agents?
- Should organisations include AI agents in human cyber risk programmes?
- Why do AI agents create more governance risk than human analysts when they consume enterprise data?
- How should security teams measure human cyber risk across employees and AI agents?