AI Agent Governance Starts With Access Control: Who Gave It Access to That Data?

In many deployments, nobody decides what data the AI agent can access. Access should trace to a named person: the user the agent acts for, or the owner of an autonomous agent with its own scoped identity.

Gartner expects that by 2027, 40% of enterprises that deployed autonomous AI agents will scale them back or shut them down entirely (Gartner, 2026) — and not because the models underperformed.

In our work with Liferay customers, the pattern is consistent: pilots look controlled, then production reveals access that was never consciously signed off. Shared accounts, broad scopes, and unclear ownership turn a useful assistant into a risk that security teams discover only after something has gone wrong.

You will find the same thing across different deployments; the biggest risk in deploying AI agents is who the agent is allowed to be and what it is allowed to access. This piece sets out how we think about that problem and what IT leaders should check before any agent reaches production.

What is AI agent access control?

AI agent access control is the set of rules that determines which data, systems, and actions an agent is allowed to reach and under whose authority it acts when it does. It is the difference between an agent that behaves predictably in production and one your security team only discovers after an incident.

Enterprise software has decades of access control conventions behind it: role‑based permissions, approval workflows, and audit logs that record who did what and when. AI agents have arrived faster than those conventions can catch up.

In many organisations, an agent connected to a CRM, document store, or ERP is still given access the way a developer would provision a quick internal tool: a shared account, broad scope, and minimal review. That approach works for a demo. It does not work once the agent is making real decisions against real data for real users every day.

At Liferay, we treat agent access control as an extension of the same identity and permission model that governs human users. An agent should be subject to the same checks, boundaries, and audit requirements as any other actor in the system.

Why AI agents fail governance after launch

Agents fail governance after launch because they carry the same shared access and ambiguous ownership from the pilot straight into production, at the exact point supervision drops away. Forrester's 2026 agentic AI research found governance gaps persisting at most enterprises even where a formal risk framework like NIST's AI RMF is already in place, because a written policy cannot constrain a system that is already acting autonomously (Forrester, June 2026).

The pattern is consistent. An agent keeps the same shared service account and broad permissions it had in the pilot, except it is now running continuously, across more users, with less supervision. Access that was harmless in a controlled test becomes the thing that lets an agent reach data it was never meant to touch, simply because nobody went back and narrowed it.

Ownership blurs at the same time. The team that built the pilot is rarely the team accountable for what it does in production, and when something goes wrong, there is no clean answer for who approved the access in the first place.

Should an AI agent inherit a user’s permissions?

For most enterprise use cases, yes. When an agent acts on behalf of a specific person, it should see exactly what that person is authorised to see and nothing more. This is delegated authority; the default most platforms, Liferay included, build around the agent authenticating as the user and operating strictly within their existing permissions.

As Bernard Mc Closkey, Liferay's Director of Technology Partnerships, put it, “The model hasn't failed. The authorisation has.” (CFOtech UK, September 2026) His example agent did exactly what it was built to do. The access it had was the problem.

Autonomous agents break this model. One running overnight batch jobs or taking scheduled actions isn't acting for any one person, so borrowing a human identity just to get it working leaves an agent running under someone's account long after they've left the business. These agents need their own scoped identity and a named owner; the gap OWASP's 2026 Top 10 for Agentic Applications flags as identity and privilege abuse, one of its leading risk categories (OWASP GenAI Security Project).

Prompt instructions aren't enforcement. Telling an agent not to touch certain data is a request the model can be talked out of. Liferay checks permissions at the data layer instead, against the object the agent is trying to reach, regardless of what its prompt says.

Guardrails sit outside the model, filtering output rather than data access, closer to a firewall than a permission system. They can catch a harmful response. They can't confirm the agent was authorised to access what produced it. Permissions answer that. Guardrails don't.

What are the governance challenges when AI agents cross multiple enterprise systems?

Each hand-off between systems can widen an agent's access. An agent that reads from a CRM and updates a finance platform has to satisfy two permission models, each with its own idea of what "authorised" means.

Escalation. When one agent hands part of a task to another with broader access than the request needed, an ordinary hand-off becomes privilege escalation. It's the confused deputy problem distributed systems have faced for decades, now running through agent-to-agent calls.

Aggregation. An agent with legitimate access to three sources can assemble a combined picture that no single person was ever authorised to see in full. Neither risk appears in any one system's logs, because no single system did anything wrong on its own.

How should MCP tool connections be permissioned?

Each tool connection needs its own permission check. The Model Context Protocol (MCP) lets an agent call tools across connected systems through one standard interface, which makes it easy to connect an agent to more systems than its task needs. Liferay's MCP server (currently in beta), for example, authenticates the agent as a regular user and keeps it within that user's permissions.

For every call to an MCP, web service endpoint, or AI tool, access should only be granted on the basis of user context, their token, and the grants for which they are allowed, defined by an OAuth2.0 application.

Kris Patefield Principal Sales Engineer, EMEA, Liferay

Authority should narrow at every hand-off and never expand. For each one, ask what the receiving agent can reach that the original requester can't.

What does a permission check look like in practice?

On every tool call, a permission check compares the agent’s access with the signed-in user’s permissions and narrows it to the task. Take Sam, a sales manager. An agent acting as Sam can read and update Sam’s own CRM accounts and read finance data for Sam’s region and is denied payroll, which sits outside Sam’s role.

How should AI agent authority match its level of autonomy?

The more autonomously an agent acts, the tighter its controls should be: narrower scope and stronger approval rules. An agent that drafts a reply for a person to review needs read access and light oversight. One that sends the reply acts outside the system, so it needs limited write permissions and a human checkpoint before it sends. 

The test is reversibility: the harder an action is to undo, the more approval it should need. The EU AI Act applies the same logic, scaling obligations with the risk of each use case (EU AI Act, Regulation 2024/1689). Liferay's guide to matching AI authority to business risk sets out a five-level spectrum.

Where should human approval sit for an agent that publishes content?

Approval belongs at the publish step, because that's where an agent's work becomes visible to customers and hard to take back. Take an agent that can create, update and publish CMS content. Creating and editing drafts can run without sign-off, within the permissions of the user it works for, since both are easy to undo. Editing content that's already live counts as publishing. 

By default, publishing waits for an editor's approval. Low-risk content can go out without a gate, but a pricing page or legal notice always waits. An agent that publishes on a schedule has no requesting user, so its named owner decides who approves. Liferay's approval workflows can hold content for that review before it goes live.

What are the best practices for AI agent governance before deployment?

Before an agent goes into production, a short set of questions can surface the gaps that cause problems later. Use these as a pre‑deployment check for any agent that will access enterprise data or systems.
 

Identity

• Does this agent have its own scoped identity, or is it running on a shared service account?
• If it’s acting as its own principal, is there a named individual, not a team, who answers for it?

Access

• Does it hold the minimum access its task requires, or whatever was convenient to grant during development?
• Has anyone reviewed that access since the pilot, or has it just carried forward unchanged?

Oversight

• Is there a human checkpoint before any action with real consequences: publishing, sending, deleting, or approving?
• Can the agent be switched off quickly if something goes wrong, without taking dependent systems down with it?

Audit

• When this agent does something, can you reconstruct exactly what it was asked, what it touched, and what it did, without guessing?
   

A usable audit trail should record the request that triggered the action, the agent’s identity, the data or systems it touched, the action it took, and any required approvals. That level of detail is what lets an organisation investigate incidents and demonstrate how the agent operated under frameworks such as ISO 42001 and the EU AI Act.

How does Liferay AI Hub support governed AI agents?

Governance that only exists in a policy document gets tested the moment someone asks who approved a specific piece of access, and a document doesn't have an answer. An architecture does, if the controls were built into it from the start rather than retrofitted once something went wrong.

That's the premise AI Hub is built on: agents that operate within an enterprise's existing identity and permission structure, rather than introducing a parallel system with its own rules to govern separately.

If the question in this article's title sounds uncomfortably familiar for your own environment, that's the starting point worth acting on. Explore Liferay AI Hub's features for governed AI agents.

FAQ

What is agentic AI security?

Agentic AI security covers the practices and controls that keep autonomous AI agents from taking unauthorised actions or accessing data they shouldn't, spanning identity, permissions, monitoring and the guardrails placed around what an agent is allowed to do.

How do you enforce least privilege for AI agents?

By granting an agent only the specific data and system access its task requires, reviewing that access regularly, and narrowing it further whenever a workflow changes, rather than granting broad access upfront because it's easier to set up.

What regulations apply to AI agent security?

ISO 42001 sets out requirements for an AI management system, including accountability and risk controls. The EU AI Act introduces obligations that scale with how much risk a given AI use case carries. Neither replaces the need for enforced technical controls, but both expect an organisation to be able to demonstrate them.

Who owns an autonomous AI agent?

It should always be a named person or team, not a system. Autonomous agents, acting without a human principal behind each action, need a defined owner accountable for what they're permitted to do and answerable when something goes wrong.