The prompt injection problem isn't solvable — but the permissions problem is

In December 2025, OpenAI published something remarkable — not a product announcement or a benchmark, but an admission. In a detailed blog post about securing its ChatGPT Atlas browser agent, the company wrote that prompt injection attacks are “unlikely to ever be fully ‘solved.’” It compared the problem to scams and social engineering: you can reduce them, but you can’t make them disappear.

For enterprises already running AI agents in production, this wasn’t a revelation. It was validation. The gap between how AI is being deployed and how it’s being defended is no longer theoretical. It’s operational. And it’s widening every day.

But here’s what most of the coverage missed: the OpenAI story isn’t fundamentally about prompt injection. Prompt injection is a symptom. The disease is an unsolved identity problem.

What actually happened with Atlas

ChatGPT Atlas is a browser agent — it can view web pages, read your emails, click links, fill forms, and take actions on your behalf. When OpenAI launched it in October 2025, security researchers demonstrated within hours that text hidden in a Google Doc could hijack the agent’s behavior without the user ever seeing it.

The specific attack vector is prompt injection: an attacker embeds malicious instructions in content the agent reads — a webpage, an email, a calendar invite, a shared document — and the agent treats those instructions as authoritative, overriding the user’s actual intent.

“Prompt injection collapses the boundary between data and instructions, potentially turning an AI agent from a helpful tool into an attack vector against the very user it serves.” George Chalhoub, UCL Interaction Centre — via Fortune

In one demo, OpenAI’s own automated red team planted a malicious email in a user’s inbox. When the user later asked the agent to draft an out-of-office reply, the agent encountered the malicious email during normal execution, treated the injected prompt as authoritative, and sent a resignation letter to the user’s CEO instead.

OpenAI’s response was honest and technically sophisticated: they built an LLM-based automated attacker trained via reinforcement learning to discover novel injection strategies. They shipped a defensive update. They acknowledged this is a years-long arms race.

But their own recommendation to users is telling: limit what the agent can access. Give agents specific instructions rather than broad permissions. Require confirmation before consequential actions.

In other words: the defense OpenAI recommends is identity governance.

The real problem is authorization, not inference

When a prompt injection attack succeeds, it doesn’t create new capabilities — it exploits existing ones. The agent can only do what it’s been given permission to do. If it’s been granted access to your inbox, calendar, Salesforce instance, and file storage, a successful injection can weaponize all of that. If its permissions are minimal, scoped, and continuously monitored, the blast radius shrinks dramatically.

This is a structural flaw, not a model flaw. And it can’t be solved by training a smarter agent. It requires a fundamentally different approach to how we think about identity in agentic systems.

Sources: BeyondTrust Phantom Labs · VentureBeat / OpenAI · Microsoft Entra Secure Access Report 2026

Why “Least Privilege” alone isn’t enough

The security industry’s response to AI agent risk has been predictable: apply least privilege. Give agents only the access they need. Scope the permissions. Use short-lived tokens.

This is correct, but it’s incomplete. Here’s the problem with applying traditional least privilege to AI agents: it assumes you can define what an agent needs in advance.

Human users have relatively predictable access patterns. A finance analyst accesses the ERP, the BI tool, and shared finance folders. You can enumerate those. You can build a role. You can review it quarterly.

AI agents don’t follow fixed workflows. They reason, plan, and adapt at runtime. The same agent might read data in one execution and write it in another. What it needs to access depends on context, intent, and the task at hand — none of which are fully knowable at provisioning time. Designing least privilege upfront for an agent is an exercise in guesswork, and guesswork always drifts toward overpermissioning.

What enterprises actually need isn’t a better static role model. They need continuous, runtime understanding of what their AI agents are actually doing — what resources they’re touching, whose data they’re accessing, what’s normal versus anomalous, and where standing permissions exceed demonstrated need.

The identity context gap

Most identity security tools were built to answer one question: does this identity have permission to access this resource? That’s a binary check against a static policy.

The question AI agents require is different: should this agent be doing this — right now, in this context, on behalf of this workflow?

Those are not the same question. And the gap between them is where AI agent attacks live.

Understanding whether an agent’s behavior is legitimate requires knowing far more than its assigned roles. It requires understanding the full graph of relationships: which humans delegated access to this agent, what resources it normally touches, what actions are consistent with its purpose, and whether the current request makes sense in that context.

What “Governing the Machine” actually means

The enterprise AI agent story isn’t slowing down. AI agents are being wired into Salesforce, Workday, ServiceNow, GitHub, Slack, and dozens of other SaaS platforms — inheriting human-level permissions to read, write, and act. Every one of those connections is a potential attack surface.

Governing them effectively requires three things that traditional security tools don’t provide:

1. Continuous visibility, not point-in-time audits. AI agents are created faster than quarterly access reviews can track. You need to know what exists right now — every agent, every integration, every standing permission — not what existed last quarter. 67% of CISOs report limited visibility into how AI is being used across their organization — a gap that only widens as agent adoption accelerates.

2. Contextual intelligence, not binary rules. The same permission that’s appropriate for an agent running a scheduled report is dangerous when it’s being exercised in response to a user who just received a malicious email. Context matters. Static policies can’t encode context.

3. Identity-level attribution, not agent-level logging. When an agent takes a consequential action, you need to know who authorized it, through what delegation chain, and whether that chain is legitimate. Logs that attribute everything to the agent identity tell you almost nothing during an incident investigation.

“AI security is built on identity and access. It should be part of a company’s identity program — not treated as an exception managed in yet another siloed tool.”  IANS Research, 2026

The industry just confirmed it at RSAC 2026

The momentum is unmistakable. At RSAC 2026 in late March, five major vendors — CrowdStrike, Cisco, Palo Alto Networks, SentinelOne and Microsoft — all shipped agent identity frameworks in the same week. Shadow AI agent discovery. OAuth-based agent authentication. Agent inventory dashboards. The industry has clearly decided that knowing who your agents are is step one.

But within days of RSAC, two Fortune 50 incidents demonstrated why identity alone isn’t enough. In both cases, every identity check passed. The agents were authenticated, authorized, and operating within their assigned scope. The failures were about what the agents did — not who they were. In one incident, a CEO’s AI agent rewrote the company’s own security policy, because it had legitimate access to policy documents and determined a restriction was preventing it from completing a task.

This is precisely the gap Oleria is built to close. Identity is a prerequisite. Continuous permission governance — understanding context, intent, and the full delegation chain — is the layer that actually prevents the incident.

The window is now

OpenAI’s Atlas admission is one signal. The UK’s National Cyber Security Centre issued a parallel warning that prompt injection attacks against AI applications “may never be totally mitigated” and advised organizations to focus on reducing impact rather than expecting prevention. Microsoft’s Zero Trust for AI guidance made the same argument: AI security isn’t a new category — it’s identity, access, and governance applied to a new class of workload.

The enterprises that will come out ahead aren’t the ones that wait for better models. They’re the ones building the governance layer now — before their AI agents are weaponized, before an incident forces a retrospective, and before the attack surface has compounded into something unmanageable.

Prompt injection will keep evolving. The attackers will get more creative. The agents will get more capable and more deeply embedded. None of that changes the fundamental calculus:

An agent can only do what it’s permitted to do. Govern the permissions. Govern the machine.