97% of AI Breaches Trace Back to Missing Access Controls

By Harry Edwards, Head of Solutions Engineering at StudioX

Executive Summary

IBM's 2025 research found that 97% of organizations that suffered an AI-related security incident lacked proper AI access controls. That number is worth sitting with, because of what it does not say. It does not say the models were jailbroken, or that prompt injection was the root cause, or that a vendor's weights leaked. It says the controls that should have stood between an AI system and enterprise data were not there.

That is a familiar failure mode wearing new clothes. The reason it recurs with AI is structural: most AI deployments introduce a new identity — a service principal, an API key, an integration user — that reads across many systems on behalf of many people, and then answers questions without reference to who is asking. Once you have built that, you have built a permissions bypass, and no amount of model-layer safety work will fix it.

This article is about the specific controls that prevent it: identity that travels with the request, ACLs enforced at retrieval time rather than filtered afterwards, per-integration authorization, human approval on state-changing actions, and an audit trail detailed enough to answer a regulator. I will also be direct about the parts that remain your responsibility. Enterprise software has moved from automation, where machines follow instructions, through intelligence, where a human still decides, to autonomy, where a system decides and acts. Autonomy is where access control stops being a data-privacy concern and becomes an operational-authority concern.

The Problem

There are three distinct access-control failures in enterprise AI, and they need separate controls.

The retrieval bypass. A retrieval system indexes SharePoint, Confluence, Jira, Drive, shared mailboxes and a document store, using a service account with broad read rights. The index is now a flattened copy of your document estate with the permission model stripped off. Any user who can query it can, with the right phrasing, surface content they were never entitled to see. The classic proof is asking about compensation bands or an unannounced restructuring and getting a fluent answer sourced from an HR folder the user cannot open directly.

The action bypass. An AI system holds credentials to Salesforce, SAP, ServiceNow or a payment API. Those credentials are usually provisioned for convenience during a pilot, then never narrowed. The system can now write to systems of record with authority no individual user has, triggered by natural-language input that may have arrived from outside the organization — a customer email, a WhatsApp message, an inbound webhook.

The evidence gap. When an auditor asks why a specific decision was made, most deployments can produce a log line saying a request was served. They cannot produce the retrieved context, the identity in effect, the tools called, or the reasoning path. Under GDPR Article 22, the EU AI Act's obligations for high-risk systems, SOX ITGC testing, or HIPAA's minimum-necessary standard, "the model decided" is not an answer.

Gartner predicts more than 40% of agentic AI projects will be canceled by end of 2027. A meaningful share of those cancellations will happen at a security review, when someone finally asks which identity the system is acting as.

The Traditional Approach

Security teams have reached for four mitigations, and each addresses a real risk while leaving the core problem intact.

Post-retrieval filtering. Retrieve broadly, then remove results the user shouldn't see before generating an answer. The intent is right, but the sensitive content has already entered the pipeline. Anything that leaks — a cached embedding, a debug log, a summary generated before the filter applied, a prompt-injection path that alters filter behavior — leaks real data. You are relying on a subtraction step to enforce a boundary.

Isolated environments per sensitivity tier. Separate indexes and separate deployments for HR, legal, finance and general. It genuinely reduces blast radius. It also multiplies operational cost, and it fails at the boundary: most useful questions cross tiers, and users end up copying content between environments manually.

Prompt-level restrictions. System prompts telling the model not to disclose certain categories. This is not a control. It is a request to a probabilistic system, it is evaluated by the same component an attacker is manipulating, and it produces no audit evidence.

Read-only deployments. Forbid write actions entirely. Safe, and it caps value at the intelligence era — the system advises, a human still executes, and you have bought a faster search box.

A single shared service account. Not a mitigation so much as the default that emerges when nobody chooses. It is the direct cause of most of the 97%.

Why It Fails

All of these fail for one reason: the permission decision is made in the wrong place, at the wrong time, by the wrong component.

In a correctly designed enterprise system, authorization happens at the resource, at the moment of access, using the identity of the requesting principal. In most AI deployments it happens in the application layer, after retrieval, using the identity of a service account — with a language model somewhere in the loop. That inverts every assumption your existing controls rest on. Your SharePoint ACLs are still correct; they are simply no longer consulted, because the service account is the one asking.

The second structural failure is that authority is granted at deployment time rather than derived at request time. A pilot is provisioned with generous credentials so it doesn't stall. Those credentials become permanent. Six months later the system can write to production systems of record, and nobody can articulate the ceiling on what it is allowed to do — which means there isn't one.

The third is that observability was designed for debugging, not for evidence. Logs capture latency and errors. They do not capture the retrieved chunks, the effective identity, the tool invocations with their parameters, or the decision path. When a regulator asks you to reconstruct a specific automated decision from eight months ago, you need a replayable record, not a metrics dashboard.

How StudioX Solves It

StudioX is an Enterprise AI Platform for building Autonomous AI Workers and Business Applications without writing code. The access-control model is built on the principle that the platform, not the builder and not the model, enforces the boundary.

Identity travels with the request. Enterprise Knowledge is a single permissions-aware retrieval substrate across SharePoint, Confluence, Jira, Drive, email, PDFs, tickets and tribal knowledge. ACLs travel with the data: permissions are carried into the index and evaluated against the requesting user at query time, so content the user cannot open is never retrieved — not retrieved and then hidden. If the source system revokes access, the next query reflects it.

Every answer is attributable. Enterprise Knowledge cites its source down to the paragraph and version. That matters for accuracy, and it matters for security review: a citation an auditor can open is also a permission assertion they can independently test.

Integrations are individually governed. Every connection runs through Model Context Protocol — 1,300+ pre-built connectors, plus Instant MCP for importing an OpenAPI, Swagger or Postman spec so every endpoint auto-maps to a callable tool. Each call is governed with per-server authentication, RBAC, audit logging and versioning, with AES-256 at rest and encryption in transit. Authorization is per server and per tool, so a Specialist Agent that needs to read ServiceNow incidents does not thereby gain the ability to close them.

Authority is scoped per Specialist Agent. Each Specialist Agent has a scoped knowledge base, a specific tool set, and defined authority. There is no single omniscient identity. The Reasoning Core routes work to the specialist whose remit covers it, and hands off with context — but not with expanded rights. The Generic Agent, which uses MCP discovery for novel requests, operates inside the same tool-level authorization.

State-changing actions can require approval. Human-in-the-loop is a first-class control, not a UI courtesy. Escalations carry full context and a pre-drafted recommended action, so the approver has enough to make a real judgment rather than rubber-stamping.

Everything is traced and replayable. Every decision the Reasoning Core makes is traced, and every trace can be replayed. Observations capture the inputs, state and relevant history the decision was based on. That is the evidence artifact your auditors need.

The perimeter is yours. Enterprise Deployment runs inside your own boundary — cloud, private cloud, on-prem, Kubernetes-native or air-gapped — with SSO, SCIM, audit and RBAC available from day one. The LLM Gateway is model-agnostic across Azure OpenAI, Claude, Gemini or a private model, so model choice is a governance decision you can revisit without touching applications. Agents never phone home.

Now the honest part. None of this makes an AI deployment secure on its own. If your source systems have wrong permissions today — an over-shared SharePoint site, a Confluence space open to all staff — a permissions-aware retrieval layer will faithfully honor those wrong permissions. AI does not create that exposure; it makes it discoverable at scale, which is why a permissions review of your source estate should precede rollout, not follow it. Prompt injection via untrusted inbound content remains an active risk area across the industry; the mitigation that holds is not model instruction but the authorization ceiling underneath it, which is exactly why write scopes should be minimal and approval gates real. And StudioX provides controls and evidence; it does not confer a certification on your deployment. Whether you meet SOC 2, ISO 27001, HIPAA or EU AI Act obligations depends on how you configure, operate and evidence the system.

Benefits

The retrieval bypass closes structurally. Content outside a user's entitlement is never retrieved, so there is no filtered-out data to leak later.
Blast radius is bounded by design. Per-Specialist-Agent scoping means no identity in the system can do everything.
Audit questions have answers. A replayable trace showing identity, context, tools and decision path is a materially stronger artifact than a log line.
Data residency and sovereignty are answerable. Running on-prem or air-gapped, with agents that never phone home, makes the residency question a deployment fact.
Model risk is decoupled from application risk. The LLM Gateway lets you change or restrict models without rebuilding applications.
Existing investments are reused. Your identity provider, ACLs and SIEM stay authoritative rather than being duplicated.

Example Workflow

A concrete AI Mission for a security-sensitive process: triaging an inbound data subject access request under GDPR.

Trigger. A DSAR arrives at the privacy mailbox in Microsoft 365, or is submitted through a Business Application form on the customer portal.
Observations. The platform captures the request, the requester's asserted identity, submission channel and timestamp, and the statutory response deadline.
Identity verification specialist. Scoped to the CRM and the identity system. Confirms the requester matches a known data subject. If verification is ambiguous, the Mission stops immediately — no personal data is retrieved on an unverified request.
Discovery specialist. Queries Enterprise Knowledge and connected systems for records relating to that subject across Salesforce, ServiceNow, the support mailbox and document repositories. Retrieval runs under the privacy team's entitlements, and every located item is returned with a citation to its source, version and location.
Classification specialist. Separates data the subject is entitled to receive from material subject to legal privilege, third-party personal data, or an active investigation hold — checking the retention and legal-hold registers rather than inferring.
Human-in-the-loop. The Data Protection Officer receives a compiled package: every record found, its source citation, the proposed inclusion or exclusion decision, and the legal basis for each exclusion. Nothing is disclosed without explicit approval. This gate is not optional and should not be made optional.
Action on approval. The Mission assembles the response pack, logs the disclosure in the records-of-processing register, updates the ServiceNow case, and schedules deadline reminders.
Trace. The full run — including which records were found but excluded, and on what basis — is retained as a replayable trace. If the supervisory authority questions the response, the reconstruction is evidence, not recollection.

Note what the design does here: at no point does a service account with broad rights read personal data. Retrieval is scoped, verification precedes retrieval, and disclosure requires named human approval.

Related StudioX Capabilities

Enterprise Deployment covers deployment topologies — cloud, private cloud, on-prem, Kubernetes-native and air-gapped — plus SSO, SCIM, RBAC, audit configuration and the model-agnostic LLM Gateway. Enterprise Knowledge covers the permissions-aware retrieval substrate, how ACLs travel with indexed content, and how citation to paragraph and version works. The Enterprise AI Platform covers the Reasoning Core, Observations, Specialist Agent scoping, human-in-the-loop approval, and the MCP integration layer with its per-server auth, RBAC, audit logging and versioning.

Frequently Asked Questions

Does permissions-aware retrieval slow queries down? Filtering by entitlement at query time adds work, but it usually narrows the candidate set rather than widening it, so the practical impact is modest. The alternative — retrieve broadly, filter after — is faster and is the pattern that produces the incidents.

How do we handle permissions that change after indexing? Entitlements are evaluated against the requesting user at query time rather than baked in at index time, so a revocation in the source system takes effect on the next query. Content changes still depend on your sync cadence, which you configure per source.

Can we prevent AI systems from writing to production systems entirely? Yes — grant read-only scopes on those MCP servers. That is a legitimate starting posture. Just recognize that it keeps you in the intelligence era: the system advises, humans execute. Most organizations progress by allowing writes to low-risk record types first, with approval gates, and widening as the trace history justifies it.

What is the fastest way to find our exposure today? Ask which identity your current AI system authenticates as, and what that identity can read. If the answer is a service account with tenant-wide read access, you have the condition IBM's 97% describes, regardless of what your model-layer controls look like.

Call to Action

Access control is not a feature you add after a pilot proves value; it determines whether the pilot can ever go to production. If you are evaluating autonomous AI, run the identity question first: whose permissions apply, where are they evaluated, and what evidence survives the run. Review Enterprise Deployment for the perimeter and identity model, or see how Enterprise Knowledge enforces ACLs at retrieval time.