As AI agents gain access to business systems, organisations need enforceable access limits and reliable records showing who authorised each action.
An AI assistant that summarises a document has a different risk profile from an agent that can change customer records, deploy software or grant access to another account.
The difference lies partly in permissions. Once an agent can act across connected applications, a mistaken instruction or compromised workflow can have consequences beyond an inaccurate answer.
Research published by identity-management vendor JumpCloud highlights the governance challenge. Its report landing page says 72% of organisations surveyed report a moderate-to-large gap between what AI is permitted to access and what they can prove it accessed. It also says 59% have not fully incorporated agents into the IAM policies used for human users. These are vendor-reported survey findings, not a measurement of every organisation.
The security question extends beyond whether an agent has permission to connect. Teams also need to establish whether a particular operation is authorised—and preserve enough evidence to investigate it afterwards.
A changing task should not create unrestricted access
Least privilege means limiting access to what a task requires. For agents, that boundary needs to account for the systems, records and operations involved.
Consider a hypothetical customer-support agent. Reading an assigned ticket, retrieving the relevant order and drafting a response may be appropriate. Exporting the entire customer database or changing payment details would require a different justification.
Connecting all those capabilities to one broad credential creates unnecessary exposure.
NIST’s zero-trust architecture provides a useful foundation: network location or ownership alone should not confer trust, and authentication and authorisation are distinct controls. An authenticated identity still needs permission to access a resource.
For agents, successful login should therefore be the beginning of an access decision—not permission to perform every available operation.
Enforce permissions outside the model
Instructions such as “only change approved records” can describe intended behaviour. They do not replace an access-control system.
A model can misunderstand a request or encounter malicious instructions embedded in retrieved content. The component executing a tool call must independently check whether the action is allowed.
OWASP’s AI Agent Security guidance recommends restricting tools and resources, separating read and write access, and enforcing authorisation in the execution component outside the agent’s context. It also recommends explicit authorisation for sensitive operations.
This distinction is practical. A support agent should be unable to export unrelated customer records even if its generated tool request asks to do so.
What scoped access looks like in practice
The following examples illustrate possible control designs. They are not reports of deployments or universal compliance requirements.
| Agent task | Appropriate starting boundary | Additional control for higher-impact actions |
|---|---|---|
| Summarise internal documents | Read selected documents | Deny access to unrelated folders |
| Draft a customer response | Read the assigned ticket and relevant order | Separate drafting from sending |
| Investigate a service incident | Read approved logs and metrics | Restrict production changes |
| Prepare an invoice | Access the relevant transaction | Separately authorise payment |
| Suggest an access change | Read the request and applicable policy | Independently approve privileged access |
The purpose is to make permitted actions specific enough to enforce. A broad job label such as “finance assistant” does not adequately describe which accounts, records or transactions an agent should reach.
Give each agent an accountable identity
A useful agent inventory should record its purpose, owner, connected systems and permitted operations.
Where the platform supports it, a distinct workload identity helps distinguish one agent’s activity from another’s. It should also be possible to identify the user on whose behalf an agent acted.
These are separate relationships. The person responsible for maintaining an agent may not be the person authorising a particular transaction.
Credential lifetime matters too. Short-lived credentials can reduce the duration of exposure, but a temporary token with excessive permissions still grants excessive access. Scope, expiration and revocation need to work together.
Build an audit trail that explains the action
A list of tool calls may show activity without establishing whether that activity was appropriate.
For a consequential operation, a useful event record could connect:
- The agent identity and relevant version.
- The initiating user or authorised workflow.
- The target resource and requested operation.
- The policy decision and policy version.
- Any required approval.
- The result and a correlation identifier.
This is a proposed evidence checklist, not a legal retention standard.
Logs also need protection. Recording passwords, access tokens or complete confidential documents can create another security problem. OWASP advises against placing sensitive data and credentials in plain-text logs.
An agent’s own explanation of its behaviour is not a substitute for records from the systems that authorised and executed the action.
Review changes when they happen
Scheduled access reviews remain useful for checking ownership and business purpose. However, a newly connected tool can change an agent’s capabilities between review dates.
Useful review triggers include adding an integration, enabling write operations, changing an owner or modifying an approval requirement.
Teams should also test denial behaviour. For example, can a document-reading agent reach an unrelated folder? Does a write operation fail when its approval is missing? Can access actually be disabled during an incident?
A control is more convincing when its boundary has been tested than when it exists only in a policy document.
Start with a workflow that can be verified
Organisations do not need to give every agent the same level of autonomy.
A practical starting point is one narrowly defined workflow with a named owner, limited resources, enforceable permissions and a tested shutdown procedure. Higher-impact operations can receive additional oversight as capabilities expand.
The central test is whether the organisation can answer three questions: what could the agent do, what did it do, and what authorised that action?
Those answers turn least privilege from a configuration intention into a control that can be checked.
