How should organisations govern AI agents that act as business units of work?

Why This Matters for Security Teams

AI agents that act as business units of work are not just another application tier. They make decisions, chain tools, move data, and sometimes initiate changes without a human in the loop for each step. That changes the governance problem from simple access control to runtime accountability, because a static role does not describe an agent’s real behaviour once it starts executing tasks. Current guidance suggests treating these systems as first-class non-human identities, not as “smart users.”

The risk is visible in live deployments. NHIMG research on AI Agents: The New Attack Surface report found that 80% of organisations report AI agents have already performed actions beyond their intended scope, while only 44% have implemented any policies to govern them. That gap matters because business-unit agents often touch customer data, finance workflows, and internal systems faster than governance teams can review them. External guidance from the NIST AI Risk Management Framework reinforces the need for structured mapping of responsibilities, but it does not replace agent-specific operational controls.

In practice, many security teams encounter agent overreach only after a workflow has already published, modified, or exposed something it should never have touched.

How It Works in Practice

Effective governance starts by defining the agent’s business purpose, permitted actions, and explicit boundaries before production approval. That means assigning named ownership, documenting which systems the agent may read or write, and separating duties so one agent can propose while another human or control plane publishes. The governance model should also specify revocation conditions, escalation paths, and audit requirements up front.

For runtime control, best practice is evolving toward intent-based authorisation: the decision is made at the moment the agent requests an action, using context such as task type, data sensitivity, destination system, and current risk posture. Static RBAC alone is too blunt for this model because an agent’s access pattern changes by objective. Organisations are increasingly pairing policy-as-code with short-lived credentials so the agent receives only the access needed for a single task, then loses it automatically.

• Use workload identity as the primary identity primitive, with cryptographic proof of what the agent is, not just a shared secret.
• Issue JIT credentials per task, with short TTLs and automatic revocation on completion.
• Evaluate policy at request time using a central decision engine, not only during onboarding.
• Log intent, prompt context, tool calls, data targets, approvals, and revocations in an immutable trail.

NHIMG’s OWASP Agentic Applications Top 10 and the CSA MAESTRO agentic AI threat modeling framework both reflect this shift toward runtime control and task-scoped trust. These controls tend to break down when an agent is wired directly into legacy systems that only support broad service accounts and coarse permissions.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, requiring organisations to balance autonomy against approval latency and integration complexity. That tradeoff becomes sharper in high-volume environments where agents perform many small actions per hour, because overly heavy approval gates can erase the productivity benefit that justified the agent in the first place.

There is no universal standard for this yet, but current guidance suggests using stricter controls for agents that can move money, alter records, or access regulated data, while allowing lighter controls for low-risk internal summarisation or routing tasks. A second edge case is delegation chains: one agent calling another agent, or calling tools that themselves carry authority. That is where many designs fail, because trust is inherited faster than policy is updated.

Another common mistake is assuming observability alone is governance. Logs help after the fact, but they do not prevent an agent from taking an inappropriate action in the first place. For that reason, security teams should pair logging with pre-execution policy checks and revocation paths. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Regulatory and Audit Perspectives are useful references when building these controls into procurement and audit requirements.

Related resources from NHI Mgmt Group

• How should organizations approach the governance of AI agents?
• How should security teams govern API keys used for generative AI access?
• How can organisations govern AI agents that use service accounts and tokens?
• How can organisations govern AI agents without slowing operations?