Who allowed your AI agent to see that data?

The first major enterprise AI-agent incident might not be the result of an agent going rogue; it could instead be the case of an agent behaving precisely as it was designed to do – yet being given access to something it should never have been allowed to see.

Consider an agent deployed to help a salesperson prepare for a customer meeting. It searches the CRM, retrieves the relevant records and produces a useful briefing. No prompt injection. No hallucination. No malicious behaviour.

The problem is that the service account behind the agent has access to the entire CRM, including records the salesperson themselves would never be authorised to open.

The model hasn't failed. The authorisation has.

That distinction matters as organisations move AI agents from pilots into production. Much of the conversation about agent security focuses on controlling what agents do. Enterprises also need to ask a more fundamental question: who authorised this agent to see that data in the first place?

Enterprises have spent nearly two decades refining that answer for human users, implementing single sign-on, role-based access control, joiner-mover-leaver processes and robust audit trails. Agents are now entering those same systems, often without the same identity and access controls.

In the integration work I see across partners and customers, the pattern is consistent. The agent is wired up with a static API key or a shared service account holding broad, persistent permissions because that is the fastest way to get it working. The scoping is left for later. Later tends not to arrive, and the agent goes to production with more access than the person it was built to assist.

It is rarely a decision anyone remembers making. The permissions were provisional, and then the pilot succeeded.

Although this may look like a new AI security problem, it is fundamentally an identity and access management challenge that predates agents. The necessary tools largely exist. The gap is applying them to this new class of user. 

AI agents - a new class of user?

Most organisations have not deliberately selected a model for agent authority, although two options are available.

The first is delegated authority, where the agent acts on behalf of a signed-in human and can never exceed what that person is entitled to, using established OAuth 2.0 token exchange. Its strength is accountability: the audit record reads as a human acting through an agent, so someone is always answerable. This should be the default. Anything that can be done in a human's session should be, and the burden of proof belongs on the exception. 

The second option is for the agent to act as its own principal, with a distinct identity and lifecycle. This approach is necessary for autonomous or scheduled agents that operate without human involvement at the time of action. It is harder to govern, as the agent requires provisioning, review, and revocation similar to an employee. But "similar to an employee" is where the comparison breaks down. An employee has a manager, a start date and a leaving date. An agent-as-principal usually has none of these, and when it accesses something it should not have, there is no human in the audit record to ask why. 

That does not make the model avoidable. Scheduled and autonomous agents have no human present at the moment of action, so there is no session to borrow authority from. What they need instead is a ceiling and an owner. The ceiling is a defined role with the entitlements the task requires and nothing more, reviewed like any other role rather than assembled ad hoc at deployment. The owner is a named person who answers for it - not the team that built it, an individual, recorded where an auditor can find them. An autonomous agent without a named owner is an unowned credential with a schedule attached. 

Prompt guardrails are not security controls

A system prompt instructing an agent to avoid certain data operates at the same level as any input an attacker could provide, which is why prompt injection is a significant risk. Indirect injection worsens this issue, as instructions may be hidden in documents the agent retrieves, emails it summarises, or web pages it reads.

A useful comparison is asking an employee not to open a salary spreadsheet versus removing their access to the file entirely. The first approach relies on compliance, while the second does not.

Security controls must remain effective regardless of model input. Checks should be implemented below the model, at the API, platform and data layers, verifying each request against the user's entitlements before returning data. The model itself should not determine its own permissions.

Developers will recognise this pattern as analogous to client-side versus server-side validation, now applied to AI. 

What happens when an agent crosses systems

A useful agent rarely operates within a single system. It interacts with content repositories, CRMs, ticketing platforms and email, each with distinct permission models and identity concepts. Standardised tool integration has simplified connecting agents to multiple systems, but consistent authorisation across these systems remains challenging.

Permission amplification is a significant risk. If one agent delegates a task to another agent with broader access than the original human user, this results in privilege escalation, similar to the confused deputy problem in agent-to-agent workflows.

Aggregation presents another challenge. An agent may have legitimate access to multiple sources individually, but the combined output could reveal information that no single user is authorised to assemble. System-specific permissions may not address this risk. 

The next identity sprawl problem

Non-human identities, such as service accounts, API keys and machine credentials, already make up a significant portion of the enterprise identity estate and are often difficult to govern consistently. Agents risk accelerating this issue, as creating a new agent is often low-friction and may bypass established identity governance.

Provisioning agents is straightforward, but deprovisioning is often overlooked. An agent created for a project that ended eighteen months ago may still retain active credentials, with no one assigned to review them. Persistent access without an accountable owner introduces unmanaged risk.

The solutions are straightforward: use scoped, short-lived tokens instead of static keys, implement just-in-time access, assign a named owner to each agent and include agents in existing access review cycles. This approach primarily involves extending established IAM practices to a new group. 

Accountability starts with the audit trail

When an agent makes an error, an organisation must be able to answer four questions: what was the agent asked to do, what did it access, what actions did it take and in which systems, and under whose authority did it act?

If a deployment cannot answer these questions confidently, the organisation faces more than a simple model error. Without adequate records, it is difficult to scope incidents, demonstrate compliance or assign accountability. The distinction is important: "the AI made a mistake" is a model-quality issue, while "we cannot reconstruct what happened" is a governance issue.

Regulatory requirements are increasing in urgency. New obligations under the EU AI Act, such as record-keeping, traceability and human oversight for higher-risk systems, will be difficult to meet for organisations unable to track agent activity.

UK GDPR presents another challenge. Principles such as data minimisation and purpose limitation are difficult to demonstrate if an agent operates with broad, persistent access to enterprise data. Standards such as ISO/IEC 42001 are also moving AI governance towards demonstrable compliance rather than simple description. 

The timing matters. In 2026, agent pilots are moving into production, but security models haven't necessarily kept pace.

Not complicated, but it needs doing

None of this requires new technology. It requires deciding that agents are subject to the same discipline as everyone else with a login.

• Give every agent a named owner. A person, not a team. Recorded where an auditor can find it.

• Make delegated authority the default. If a task can run inside a human's session, it should. Agent-as-principal is the exception, and the burden of proof sits with whoever wants it.

• Enforce authorisation below the model. At the API, platform and data layers, checked against the user's entitlements before data is returned. Never in a system prompt.

• Issue scoped, short-lived credentials. Just-in-time access rather than static keys with permanent scope.

• Log every interaction against an identity. What was requested, what was accessed, what was done, and under whose authority.

• Put agents in your existing access reviews. They are already in the estate whether or not anyone is reviewing them.

• Make delegation narrow, never wider. When one agent hands work to another, permissions tighten at each hop. An agent must never be able to reach something by asking another agent to fetch it.

Every agent should have a named owner. A person, not a team. If you cannot produce a name for an agent running in your environment today, you have already found the answer to the question in the title - and you are not going to like it.