Treat AI agents as NHIs with scoped identities, explicit ownership, and continuous oversight. Give each agent least-privilege access through IAM, RBAC or ABAC, and JIT elevation for sensitive actions. Isolate tool use, code execution, and secrets access. Log every prompt, action, and tool call. Apply policy checks, human approval for high-risk changes, and periodic review of permissions, drift, and abuse patterns.
What governance needs to exist before an AI agent can act?
Teams should not treat an agent as an informal automation. It needs an explicit identity, a named owner, a defined purpose, and a written boundary for what it can and cannot do. That boundary should cover which systems it may reach, which actions require escalation, and what evidence proves the agent is operating inside policy.
Governance is strongest when the agent’s permissions are designed around the task rather than inherited from the human who configured it. That means separating the agent’s own authority from the operator’s, so approval, delegation, and accountability remain visible. For identity and delegation design, the most useful starting point is Agentic AI Identity Guide.
How should access, tools, and code execution be constrained?
An agent that can write code and use tools should receive the minimum access needed for the current task, not broad standing privilege. In practice, that usually means task-scoped permissions, per-action policy checks, and just-in-time elevation only when a sensitive step is actually required. Tool access, runtime execution, and secret retrieval should be isolated so one capability cannot silently expand into another.
This is where permission design becomes more than an IAM exercise. The safest pattern is to make access conditional on context, action, and risk, not on the mere fact that the agent exists. Teams can use the AI Agent Authorisation Guide to align least privilege with human approval gates and per-action authorization, and Zero Trust for AI Agents to structure verification around each request rather than around a trusted session.
When an agent uses external tools or APIs, the tool boundary itself must be treated as a control point. If the agent can invoke code, deploy changes, or touch production systems, its effective privilege is whatever those tools allow, not whatever the prompt says. That is why agent permissions, tool permissions, and environment permissions should be reviewed together.
What oversight and evidence should teams keep over time?
Governance only works if the organisation can see what the agent actually did. Every prompt, action, policy decision, tool call, and privileged change should be logged in a way that supports attribution and later review. The goal is not just auditability after the fact, but a live control loop that can detect drift, unusual tool chains, and repeatable abuse patterns before they become routine.
For teams building that control loop, the most valuable question is whether the logs answer “who allowed this, why was it allowed, and what changed because of it?” If the answer is unclear, the governance model is too weak to trust. AI Agent Observability, Audit and Incident Response Guide is the strongest internal reference for deciding what to record, how to attribute activity, and how to respond when an agent behaves outside expectations.
Risk and Threat Considerations
AI agents that can code and call tools create a real exposure surface because their mistakes can become executable changes, data access, or secret disclosure. The main failure mode is privilege amplification: a harmless-seeming request becomes dangerous once the agent can chain tools, reuse credentials, or apply changes faster than a reviewer can intervene.
Failure mechanism: An attacker, malicious prompt, poisoned tool result, or overly broad policy can steer the agent into unauthorized code execution, sensitive data access, or credential exposure, especially when tool trust and identity trust are mixed together.
Impact: Teams can end up with production change without meaningful human review, hidden exfiltration through external tools, or persistent access that survives the original task. That is why the boundary around prompts, tools, and secrets must be engineered as a security control, not just a workflow convenience.
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 and risk surface, while NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agents with tool and code access need bounded authority and approval gates. |
| ASI02 — Tool Misuse | The question centers on constraining tools, code execution, and agent action paths. | |
| ASI10 — Rogue Agents | Governance must detect and stop agents that drift outside intended authority. | |
| Recommendation — Enforce per-action authorization and human approval for high-risk agent actions. Isolate tools and restrict agent tool invocation to approved, task-scoped actions. Monitor agent behaviour for drift and disable agents that exceed their mandate. | ||
| NIST AI RMF | Govern | Agent governance depends on accountability, oversight, and documented responsibility. |
| Recommendation — Assign governance owners, define oversight processes, and track accountable decisions. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is central to limiting what AI agents can access or change. |
| AU-2 — Event Logging | Agent prompts, actions, and tool calls need auditable records. | |
| Recommendation — Limit agent permissions to the minimum needed for each task and review exceptions. Log agent actions and authorization decisions so behaviour can be reviewed and attributed. | ||
Practitioner Guidance
What to verify: Confirm that each agent has a named business owner, a unique identity, a documented purpose, and an approval path for high-risk actions. If the same permission set is reused across agents, the model is already too coarse.
What good looks like: The agent can complete ordinary work without standing privilege, but sensitive changes trigger policy checks, scoped elevation, and a reviewable trail. If you cannot explain why a tool was callable, the policy is not specific enough.
Common mistake: Teams often secure the prompt while leaving the tool chain and secret path broad. The safer pattern is to govern the action surface, not just the conversation surface.
Practitioner takeaway: Treat the agent as an active identity with bounded authority, then prove that the boundaries still hold as tools, models, and workflows change.