How should security teams govern agent actions when locally runnable models can execute multi-step tasks across enterprise systems?

Security teams should treat the model as only one part of the control stack. The important layer is execution governance: which identity the agent uses, what permissions it inherits, what policy gates each action, and when a human must approve a sensitive step. As models get cheaper and easier to deploy, governance, auditability, and least privilege become the real differentiators.

How to govern agent actions, not just model output

Locally runnable models lower the barrier to deployment, but they do not define the control problem. Once an agent can take actions across enterprise systems, security teams must govern the execution path: who the agent acts as, what it can reach, which steps require policy evaluation, and where the workflow must pause for review before the next side effect is allowed.

The practical shift is from content governance to action governance. A model can propose a plan, but the security boundary should sit around identity, authorization, and the transaction boundaries of the systems it touches. That is what keeps a fast local model from becoming a broad, unaudited operator.

For teams deciding where to start, the most useful question is not whether the model is local, cloud-hosted, or open source. It is whether the agent can create, modify, approve, or trigger real business effects without a fresh control decision. If the answer is yes, the agent needs policy-bound execution, not just prompt rules.

Where identity, privilege, and approval gates belong

An agent should not inherit a broad user session by default. It should operate through a dedicated identity, scoped to the task, with permissions that are narrow enough to limit blast radius but sufficient for the intended workflow. That identity should be traceable back to the owning service, environment, and business function, so action attribution survives handoffs and retries.

Authorization should happen per action, not just at session start. A reasonable pattern is to allow low-risk steps to proceed automatically, while sensitive steps such as external payments, policy changes, bulk data movement, or privilege changes require a separate decision point. That decision can be policy-driven, human-approved, or both, but it must be explicit.

Short-lived credentials, step-up approval, and revocation paths matter more as agents chain tasks across systems. If an agent can call several enterprise tools in sequence, the team should apply least privilege to AI agents with task-scoped access, per-action policy decisions, and human approval for sensitive steps. For identity design, the agent identity lifecycle should cover registration, delegation, ownership, and retirement from the beginning, not as an afterthought.

What good agent governance looks like in practice

Good governance makes each agent action observable, bounded, and reversible. Security teams should be able to answer three questions for any action: which principal executed it, why the policy allowed it, and what system state changed. Without that chain, incident response becomes guesswork and post-incident containment is slower than the workflow itself.

Multi-step tasks also create compound risk. A harmless first action can set up a later one, so the control should not only inspect the final output. It should also watch for sequence abuse, unexpected tool selection, and escalation from read-only work into write or approval paths. That is especially important when the agent can cross SaaS, internal APIs, ticketing systems, and administrative consoles.

For broad agent governance, agent observability and auditability should capture action logs, attribution, and kill-switch readiness, while zero trust for AI agents is the right lens for continuously verifying the principal, the request, and the standing privilege behind it. If the agent can touch enterprise workflows at scale, a security policy template for agentic systems helps turn those rules into repeatable operating standards.

Risk and Threat Considerations

When locally runnable models can execute multi-step tasks, the main risk is not model quality alone, but uncontrolled execution across trusted systems. A well-phrased instruction can become a sequence of authenticated actions, and once the agent has inherited too much privilege, every downstream system starts to look like an extension of the same trust boundary.

Failure mechanism: Overbroad permissions, reused credentials, weak action scoping, or missing approval gates let the agent move from one low-risk step to a later high-impact step without fresh review. If a prompt is manipulated, or if the task is simply mis-specified, the agent may still be able to carry out harmful changes because the control stack did not separate intent from authority.

Impact: The result can be unauthorized data exposure, destructive changes, privilege abuse, or difficult-to-detect business process manipulation. In the worst case, the agent becomes a fast, repeatable operator for mistakes and abuse, because it can chain legitimate access into an outcome the organisation never intended.

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 surface, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Agent authority and privilege are central to governed multi-step actions.
	ASI02 — Tool Misuse	Multi-step enterprise actions can be abused through unsafe tool sequencing.
	ASI10 — Rogue Agents	Uncontrolled autonomous actions create rogue-agent risk across systems.
Recommendation — Enforce per-action authorization and keep agent privilege narrowly scoped. Constrain tool access and validate each step before execution. Register, monitor, and revoke any agent that operates outside policy.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Execution governance depends on minimizing the permissions an agent inherits.
	IA-5 — Authenticator Management	Agent actions depend on credential lifecycle, rotation, and revocation.
	AU-2 — Event Logging	Auditability is required to attribute agent actions and investigate misuse.
Recommendation — Assign only the permissions each agent task needs and nothing more. Use short-lived credentials and revoke them as soon as the task ends. Log each agent action with principal, policy decision, and affected system.
NIST Zero Trust (SP 800-207)	SP 800-207 — Zero Trust Architecture	Continuous verification fits agents that repeatedly cross trust boundaries.
Recommendation — Verify the agent, request, and context before each sensitive action.
ISO/IEC 27001:2022	A.5.15 — Access control	Agent access must be governed as part of the ISMS access-control policy.
	A.8.15 — Logging	Agent execution needs logs to support accountability and incident review.
Recommendation — Define and enforce policy for agent identities, approvals, and permissions. Record agent actions and retain evidence for review and response.

Practitioner Guidance

What to prioritise: Start by classifying every agent action into low, medium, or high impact, then require a distinct control for each class. If a step can mutate records, approve transactions, change policy, or expand access, treat it as a separate authorization event rather than just another tool call.

What to verify: Confirm that each agent has its own accountable identity, that credentials are short lived, and that logs can reconstruct the full action path end to end. If you cannot attribute a change to a specific agent run and policy decision, the governance model is too weak for production use.

Practitioner takeaway: The right control objective is not to stop agents from acting, but to ensure that every meaningful action is deliberately granted, narrowly scoped, and fully attributable before it can affect enterprise systems.