Are AI Agents Safe for Enterprise Data? The Three Controls That Decide

Part 1 · The trust gap

The gap between shipping an agent and securing one

Connect it in week one. Ask who can see what in week six.

Agents are being wired into email, calendars, ticketing systems and document stores faster than anyone is writing the policy that governs them. That is not a criticism of the teams doing it. The value shows up immediately and the risk shows up quietly, which is the order in which things get skipped.

The 2026 numbers reward reading with their methodology attached. IBM's Cost of a Data Breach Report 2026, conducted by the Ponemon Institute across 602 organizations breached between March 2025 and February 2026, found more than 20% reported a breach targeting AI models or applications, and of those, 92% lacked proper AI access controls. The causes were not exotic. The two most common were compromised APIs, applications or plug-ins and cloud misconfigurations affecting AI workloads, at 27% each.

The number that makes the rest click sits further down the same report: fewer than half of organizations, 46%, actively secure the non-human identities their AI workflows run on. Every agent creates identities that talk to applications, APIs, data stores and cloud services, often with elevated privileges and no named owner. IBM's own recommendation, identity-based access controls, tightly scoped permissions enforced at runtime, and human attribution for every action, is a longer way of saying the three controls below.

Deloitte reaches the same place from the governance side. Its State of AI in the Enterprise 2026, a survey of 3,235 business and IT leaders across 24 countries, found 74% expect to be using AI agents at least moderately by 2027 while only 21% report a mature governance model for agentic AI today. Four in five lack the basics Deloitte lists: defined boundaries for what an agent may decide alone, real-time monitoring of its behaviour, and audit trails covering the full chain of actions.

The analysts land in the same spot. Gartner's Top Cybersecurity Trends for 2026 names identity and access management for AI agents as one of six forces reshaping the discipline, singling out identity registration and governance, credential automation and policy-driven authorization for machine actors as the unresolved gaps, and warning that leaving them open means more access-related incidents as agents spread. The pattern is consistent. Most organizations are not failing security review. They are shipping before it finishes, then discovering what the agent could reach the whole time.

Part 2 · Authentication

Who is actually making this request

A credential that never expires is a credential you have already lost track of.

Every request an agent makes should be tied to a verified identity, not to a static secret sitting in a config file since last spring. In practice that means short-lived signed access tokens, often valid for minutes rather than months, paired with a session on the server side that can be torn down at any moment. This is not a novel opinion. RFC 9700, the IETF's Best Current Practice for OAuth 2.0 Security published in January 2025, is explicit that access token lifetimes should be kept short and that authorization servers should be able to revoke all tokens issued from a compromised request.

That second half is the part people underrate. On a platform that can only wait for a compromised token to expire, you are exposed for whatever is left of its lifetime, with nothing to do but watch the clock. If every token is bound to a live session, access ends the instant somebody logs out, resets a password, or has their account disabled.

Take the boring version of the incident, because the boring version is the one that actually happens. An employee loses a laptop with a session still open. Without session-backed revocation, that token keeps working for hours. With it, disabling the account cuts access on the agent's very next request.

The large cloud providers have converged on the same principle with different hardware. Google Cloud's Agent Identity issues every agent a SPIFFE identity and an X.509 certificate valid for 24 hours, auto-rotated, and bound with mTLS and DPoP so a stolen token cannot be replayed outside the runtime it was issued to. Microsoft's Entra Agent ID tells teams to scope any managed identity behind a federated credential and rotate agent certificates on a schedule even where long-lived ones are permitted. The mechanisms differ, but all three requirements survive: the credential is short-lived, bound to something, and revocable.

Part 3 · Tenant isolation

Where your data stops and somebody else's begins

Shared infrastructure is fine. Shared query results are not.

Most AI agent platforms are multi-tenant, meaning many organizations run on the same underlying infrastructure. That is a sensible way to keep cost and complexity down, and it only works if the isolation is genuinely airtight.

The control that matters is scoping every record, so every document, conversation and connected account, to a specific organization at the database layer itself, not inside application logic alone. Application checks are written by people, and people write bugs. AWS makes the same argument in its guidance on multi-tenant data isolation with row-level security: in a shared database, the alternative is relying on developers to write the right check into every single SQL statement, forever. The Well-Architected SaaS Lens puts it more bluntly still, calling a crossed tenant boundary potentially unrecoverable for a SaaS business. A database-enforced boundary is a second, independent layer that has to fail in a completely different way before anything crosses.

Concretely: two unrelated companies are on the platform at once. Company A's agent queries its knowledge base for a contract clause. Even if the query is built wrong, database-level isolation means it cannot return a row belonging to Company B. The row was never reachable, which is a stronger guarantee than filtering it out afterwards.

Part 4 · Access control

Logged in is not the same as allowed

Authentication answers who. Access control answers how far.

A platform can verify identity perfectly and still hand over far too much, because being authenticated says nothing about what you are entitled to do next. Role-based access control is what draws that second line, and it needs to operate at two levels.

• Inside an organization: admins manage settings, licences and connected accounts, while members work within their own workspace and nothing beyond it.
• Across the platform: ordinary users are separated from system administrators, so routine agent activity never runs with elevated privileges just because it is convenient.

Here is the practical shape. Someone in marketing asks an agent to pull data from a connected project tracker and draft a summary. Under proper RBAC, that action is scoped to exactly what the employee is already permitted to see. The agent cannot wander into HR records or another department's workspace on the grounds that it is "an AI" and therefore special. It is not special. It is a caller with somebody else's permissions.

The standards got here first. NIST SP 800-53 control AC-6 defines least privilege as authorizing only the access necessary for the task, and applies it explicitly to "processes acting on behalf of users" running at privilege levels no higher than needed. An agent is exactly that, a process acting on behalf of a user, named in a control written long before anyone called it an agent, and it still describes the requirement exactly.

There is a live disagreement worth naming. Google Cloud and Microsoft both now issue an agent its own first-class identity, Agent Identity and Entra Agent ID, rather than having it borrow a user's, then constrain that identity hard. Entra refuses to let anyone grant an agent many high-privilege roles at all. Google logs the agent's identity alongside the user's whenever it acts on someone's behalf. The disagreement is about where the permission is stored. The ceiling is the same either way: borrowed or held, an agent must not reach anything the person who asked could not reach themselves.

The hard case is the agent that runs when nobody is watching. A scheduled report, a long job that finishes after its owner has gone home, a workflow triggered by an inbound email rather than a human click. Borrowing the caller's permissions is clean while the caller is present and gets murky the moment the authorising session ends. Most platforms resolve this quietly by handing the background job a service identity of its own, which is precisely what the rest of this article argues against.

A defensible answer looks like this: the background job carries a delegation issued the moment a human asked for it, scoped to that one task, with its own expiry, and it dies when the underlying account is disabled. If the person who scheduled it is offboarded, the job stops. That is stricter than most platforms manage, and it does mean overnight work fails the morning after somebody leaves. A job that fails loudly is easier to live with than one quietly reading a departed employee's inbox for a month.

Part 5 · The vendor conversation

Five questions worth asking before you connect anything

"We take security seriously" is not an architecture.

Most security reviews stall at certifications and marketing language, which is proof a vendor passed an audit rather than proof of how the system behaves at three in the morning. These five questions get to the behaviour, and each has a specific answer if the controls exist.

• Are access tokens short-lived, and can sessions be revoked immediately on logout or account disable?
• Is tenant data isolated at the database level, or only filtered inside application code?
• Does your RBAC model separate organization-level roles from platform-level roles, and does an agent ever exceed the caller's permissions?
• What happens, concretely, in the first minute after we disable a compromised account?
• What happens to a scheduled or long-running agent job when the person who started it is offboarded?

A vendor who answers all five specifically is having a different conversation from one who answers with a compliance badge. Vagueness here is itself a finding.

Three controls are necessary, not sufficient

Be blunt about the limits here. Authentication, tenant isolation and access control are the foundation, but they are baseline expectations for any multi-tenant platform, not something unique to AI. The agent-specific risks sit on top, untouched by getting permissions right. OWASP's Top 10 for Agentic Applications 2026 names goal hijacking, context poisoning and rogue agents as separate categories. An agent with perfectly scoped permissions can still be redirected by instructions hidden in a document it was asked to read.

So the questions keep going: how does the platform treat instructions embedded in retrieved content, what gets logged about actions taken on someone's behalf, and what does the model provider retain? This is where the Deloitte finding bites, because four in five organizations lack the monitoring and audit trails to answer. These three controls are where the questions start, not where they end.

Part 6 · The takeaway

Safety is a property of the platform, not the category

What you need to know is one layer below the label on the box.

AI agents are not inherently risky and they are not inherently safe. The outcome turns on whether identity is verifiable and revocable, whether tenants are separated by something stronger than good intentions, and whether permissions actually narrow as they should.

The 2026 research keeps circling one thing: enterprises are not careless, they are fast, and verification has not kept pace. Before you connect an agent to real enterprise data, spend five minutes confirming these three controls are in place. It is a far shorter conversation than the one that follows an incident.

Part 7 · How we build it

How we handle this at Eerly

The version of this we had to build, and the places where it cost us something.

For context: I work on the authentication, multi-tenancy and access-control layer at Eerly, so these are not a framework I assembled for an article. They are the parts of the system I spend most of my week inside, and most of what is here I learned by getting an earlier version slightly wrong.

Eerly AI Studio is a connective layer over the systems an enterprise already runs, the ERP, the CRM, email, chat and shared drives, answering questions that span all of them rather than living inside any one. That is what forces the security posture. A tool that reads one system carries one blast radius. A tool that reads across everything inherits every permission model at once. The only defensible option is to inherit those models, not invent a new one.

What that looks like in the code, in the same order as the article:

• Every request carries a short-lived signed token bound to a server-side session, so logging out or disabling an account ends access on the next request rather than whenever the token happens to expire.
• Every document, conversation and connected account is scoped to one organization at the database layer, so cross-tenant rows are unreachable rather than filtered.
• An agent never gets a service account of its own. It acts as the person who asked, which means it cannot open anything they could not already open.
• Answers carry provenance: which system each fact came from and how fresh it is, so a reviewer can check the work instead of taking it on trust.

None of that is exotic. It is the unglamorous discipline of refusing the shortcuts that make a demo faster. We write it down because "does this platform enforce these three controls" is a fair question to point back at us, and it deserves a specific answer, not a compliance badge.

FAQ

Frequently Asked Questions

The questions security teams ask us most often, answered short. The reasoning behind each one is above.

Sources & further reading

Survey figures are cited with their sample sizes so you can weigh them accordingly. The standards and framework sources are independent.

• IBM and Ponemon Institute. Cost of a Data Breach Report 2026 (July 2026). Breaches at 602 organizations, March 2025 to February 2026. Source of the AI-breach share, the 92% without AI access controls, and the 46% securing non-human identities.
• Deloitte. State of AI in the Enterprise 2026: The untapped edge (January 2026). Survey of 3,235 business and IT leaders across 24 countries. Source of the 74% expecting moderate agent use by 2027 and the 21% with mature agentic governance.
• Google Cloud. Agent Identity, and the Secure AI Framework (SAIF 2.0). Per-agent SPIFFE identities, X.509 certificates rotated every 24 hours, and mTLS and DPoP token binding against replay.
• Microsoft. Least privilege for AI agents, and Microsoft Entra Agent ID documentation (2026). Scoped RBAC for agents, tool allowlists, credential rotation, and blocked high-privilege role grants.
• Gartner. Top Cybersecurity Trends for 2026 (5 February 2026). Names identity and access management for AI agents as a core trend.
• OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications 2026 (December 2025). Covers goal hijack, memory and context poisoning, and rogue agents.
• OWASP Agentic Security Initiative. Agentic AI: Threats and Mitigations. Threat-model reference for agent design, memory, tool use and deployment.
• IETF. RFC 9700: Best Current Practice for OAuth 2.0 Security (BCP 240, January 2025). Short token lifetimes, sender-constrained tokens, and revocation.
• NIST. SP 800-53 Rev. 5, control AC-6 (Least Privilege). Applies least privilege to processes acting on behalf of users.
• Amazon Web Services. Multi-tenant data isolation with PostgreSQL Row Level Security. On enforcing tenant isolation at the data layer rather than in every SQL statement.
• Amazon Web Services. Well-Architected Framework, SaaS Lens: tenant isolation. Treats a crossed tenant boundary as potentially unrecoverable.