Yes. If an agent can retrieve, transform, or transmit organisational data on behalf of a user, it should be governed as delegated access with scope limits, logging, and review. The same logic used for other non-human access paths applies, but the oversight must also cover prompt content and tool use.
What changes when an AI agent is treated as delegated access?
An AI agent is not just software that “helps” a user. When it can read, transform, or send organisational data, it is acting with borrowed authority, so the security question becomes who granted that authority, what it can touch, and how much of the user’s or system’s reach it inherits. That is why the right control model is delegated access, not informal convenience.
The practical implication is that agent permissions should be scoped to the smallest task set that still works, and that scope should be explicit enough to review later. If the agent can act across systems, it should be treated as a distinct access path with its own accountability, rather than as an invisible extension of the human who launched it.
That distinction matters because AI agents often combine retrieval, reasoning, and action in one workflow. A human may only intend “summarise this document,” but the agent may also query connected tools, compose outputs from multiple sources, or forward material outside the original context. The security model must therefore describe both the data plane and the action plane.
Why prompt content and tool use expand the oversight problem
Prompt text is part of the control surface because it can shape what the agent is asked to do, what data it may expose, and which tools it may invoke. Tool use is equally important because the risk is not only what the model says, but what downstream systems it is authorised to do on the user’s behalf.
That means review cannot stop at a basic permission check. Teams need to understand whether a workflow can be influenced into taking unintended actions, whether tool calls are constrained by policy, and whether the agent can be induced to combine benign inputs into an unsafe output. The more autonomous the workflow, the more important it is to separate instruction, retrieval, and execution.
This is also why log quality matters. If you cannot reconstruct what the agent was asked, what data it accessed, and which tool calls it made, you cannot reliably distinguish an expected delegated action from misuse, error, or abuse. For agent workflows, observability is part of access governance, not a separate afterthought.
One useful reference point is AI Agent Authorisation Guide, which focuses on task-scoped and just-in-time access, per-action policy decisions, and human approval where the action needs it.
What good governance looks like for agent workflows
Good governance starts by classifying the workflow according to the access it can exercise, then assigning controls that match that level of authority. A low-risk drafting assistant does not need the same controls as an agent that can query customer records, update tickets, or send messages to external parties.
At minimum, the workflow should have a defined owner, a bounded set of tools, and a reviewable record of the data it handled and the actions it attempted. If the agent can reach production systems, customer information, finance data, or privileged administrative functions, the governance bar should rise accordingly.
That is also where change management matters. Agent workflows should be reviewed when prompts, tools, connectors, or output destinations change, because those changes can alter risk even when the model itself has not changed. The control objective is not to freeze innovation, but to make each expansion of capability visible and deliberate.
For teams building broader AI governance, the Agentic AI Security Guide is a useful companion because it ties inputs, memory, tools, orchestration, and identity together in one threat model.
Risk and Threat Considerations
AI agents create risk when delegated authority exceeds the task actually intended, or when prompt influence and tool access let an attacker steer a trusted workflow into doing the wrong thing. The danger is usually not that the model “becomes malicious”, but that it is persuaded, misconfigured, or over-permitted into making harmful requests on behalf of a trusted user or process.
Failure mechanism: Overbroad scopes, weak approval gates, or poorly bounded tool permissions let an agent read more data than needed, transmit it to the wrong place, or take actions that were never explicitly authorised. Prompt injection, unsafe connector design, and weak logging make that misuse harder to detect and harder to unwind.
Impact: The result can be data exposure, unauthorised transactions, destructive changes, policy bypass, or a false sense of safety because the action appears to have come from a legitimate workflow. In practice, the blast radius can be much larger than a single model output because the agent may chain multiple tool calls and propagate trust across systems.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) 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 acting on behalf of users create privilege-abuse risk through excess authority. |
| Recommendation — Constrain each agent to least privilege and require action-level authorisation for sensitive tool use. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Delegated AI agents are non-human access paths when they retrieve or transmit data on a user's behalf. |
| Recommendation — Reduce agent scopes and remove unnecessary tool and data permissions before deployment. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agent workflows rely on non-human authentication to access tools and systems on behalf of users. |
| AU-2 — Audit Events | Agent governance depends on logging prompts, tool calls, and actions for review and attribution. | |
| Recommendation — Authenticate agent-to-service interactions with strong, traceable machine credentials. Define and record agent audit events for prompts, tool invocations, and data access. | ||
| NIST Zero Trust (SP 800-207) | PDP/PEP — Policy Decision Point / Policy Enforcement Point | Per-action policy enforcement is central when an agent requests tools or data on behalf of a user. |
| Recommendation — Enforce each agent action through policy checks before tools or data are released. | ||
Practitioner Guidance
What to prioritise: Treat any agent that can act outside its own interface as an access governance problem first and an AI problem second. Start by identifying which tools, systems, and data classes the agent can reach, then decide whether each capability needs to be allowed at all.
What to verify: Confirm that the workflow has explicit scope boundaries, that approvals are required for material actions, and that logs capture prompt content, tool calls, data access, and outcome. If any of those signals are missing, you do not have enough evidence to trust the workflow at scale.
Practitioner takeaway: Govern AI agents as delegated access whenever they can act on organisational data, and assume the security boundary is defined by the agent’s tools and authority, not by the chat interface alone.
Related resources from NHI Mgmt Group
- Should agent identity be governed like other non-human identities?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern access when bots and AI agents act like non-human identities?