The short answer: Least privilege for LLM agents means granting task-scoped, time-bounded, minimum-permission credentials — not the broad OAuth tokens most deployments use today. The threat model is different from traditional apps: because AI agents process untrusted content that can inject malicious instructions, their permissions determine how much damage a successful injection can cause. Design for minimal blast radius: even a fully compromised agent should only be able to cause bounded, recoverable harm.
You wouldn't hand a new intern the master key to every room in the building, root access to production, and the authority to send emails on behalf of the CEO. You'd give them a badge that opens the front door and a read-only account on the internal wiki. You'd have them shadow someone for a week before they touched anything real. You'd definitely not let them commit to business policy on live customer calls.
That's the standard. It's common sense. It's also completely inverted when most organizations deploy AI agents.
On day one, the typical enterprise AI agent gets: OAuth tokens scoped to an entire Google Workspace or Microsoft 365 tenant, read/write access to whatever database the developer had handy, unrestricted HTTP egress, and a system prompt that says "be helpful but don't do anything bad." Then everyone is surprised when it does something bad.
Least privilege is one of the oldest controls in security. The problem isn't that engineers don't know the phrase — they do. The problem is that the threat model for an LLM agent is fundamentally different from the threat model that shaped the original principle, and nobody has updated their mental model accordingly.
The Old Model Doesn't Map
When we designed least-privilege for human users and service accounts, we were solving for access control: limit who can read or write what. Scope credentials tightly. Audit access logs. Revoke what's not needed. The threat was a compromised account or a malicious insider taking direct action using permissions they held.
That model assumes the principal — the entity acting — has a stable, predictable intent. It might be malicious, but its goals are its own. A compromised service account tries to do what the attacker wants.
An LLM agent breaks this assumption entirely. Its intent at any given moment is a function of the input it's currently processing — which may include adversarial instructions from a web page it just read, a document it retrieved from your RAG pipeline, or an email in the inbox it's triaging. The agent isn't just a principal with permissions. It's a programmable proxy for whoever controls its context window.
This means "least privilege" for an LLM has to address three distinct surfaces simultaneously. Most teams address one and call it done.
Three Surfaces. Not One.
1. Data Access — What the Agent Can Read
This is the layer everyone thinks about. Scope the vector store. Control which documents land in the RAG context. Don't give the sales agent access to HR records.
It's necessary. It's not sufficient.
Consider what happens when an enterprise deploys a productivity assistant and connects it to all the Slack channels, SharePoint drives, and Jira projects the admin account has access to — rather than scoping retrieval to what the querying user is actually authorized to see. A junior engineer asks about "the Q3 roadmap" and the agent answers with context drawn from M&A planning documents, executive compensation discussions, and post-incident reviews that would never, under any normal circumstance, appear in their access grants. The agent launders privileged data through a natural language response, bypassing every access control the organization spent years building. This isn't a breach in the traditional sense — no audit log fires, no DLP rule triggers. The data just walks out through the chat interface.
Data access scoping matters. But it's table stakes, not the finish line.
2. Action Authority — What the Agent Can Do
This is where the real blast radius lives, and it's the surface most teams under-scope.
In 2024, Air Canada's support chatbot told a customer he could buy a full-price bereavement ticket and retroactively claim a discount within 90 days — a policy that does not exist. Air Canada attempted to disclaim liability for its own agent's statements. A Canadian small claims tribunal ruled against them: the agent's commitment was binding.
Nobody injected a malicious prompt. Nobody exploited a vulnerability. The agent simply hallucinated a policy and expressed it with the full conversational authority of the company. There was no structural gate between "the agent can talk to customers" and "the agent can make binding business commitments." That gate should have existed. It didn't. The tribunal didn't care that it was an LLM — the company deployed an agent with commitment authority, and it used that authority.
Action authority needs to be scoped at least as tightly as data access, and probably more tightly — because the consequences of an unauthorized action are often irreversible in ways that unauthorized reads are not. Sending an email can't be unsent. A database write can be rolled back, but only if you caught it. A refund can be reversed, but only after a customer service escalation that costs more than the original dispute.
The practice here is explicit: model your agent's possible actions as a set, define the subset required for this specific task, grant only that subset, and treat every action outside that subset as requiring a human approval token before execution. Not a prompt that says "ask before doing risky things." An actual signed token, issued by a human, that the agent cannot synthesize.
3. Exfiltration Surface — What Channels the Agent Can Use to Move Data Out
This is the surface almost nobody scopes, and it's the most dangerous oversight.
In 2023, researchers discovered that early Bing Chat would render markdown images in its responses. A prompt injection embedded in a web page could instruct the model to include an attacker-controlled image URL in its reply — and encode user session data into that URL as query parameters. When the response rendered, the browser fetched the image, and the data was gone. No "exfiltrate data" tool was involved. The agent used its rendering capability as an unintended egress channel. No behavioral policy, no matter how carefully written, could have anticipated that vector. The only effective control was blocking unapproved external resource loads at the infrastructure layer.
The general lesson: an agent with read access to sensitive data and unrestricted HTTP egress is not least-privileged. It's a staged exfiltration waiting for a trigger. The model doesn't need an "exfiltrate data" tool call to leak data — it just needs a way to reach attacker infrastructure. That's your outbound firewall problem, not your prompt problem.
The ChatGPT plugin architecture made this concrete at scale. When researchers (notably Johann Rehberger at Embrace the Red) demonstrated indirect prompt injection against plugins, the attack surface was exactly this gap: a plugin with email-read and email-send access had no structural firewall between its data ingestion and its outbound action authority. A malicious email could instruct the agent to forward inbox contents to an external address. The model didn't want to do this. It was instructed to, and it had the structural capability. That's all it took.
Egress filtering isn't optional for agents that handle sensitive data. Route all agent network traffic through a proxy that enforces an explicit allowlist. If the agent's legitimate operation requires calling three APIs, it should be able to reach exactly those three APIs and nothing else. Prompt injection is still a serious problem — but an injected instruction that says "send this data to evil.example.com" fails safely if evil.example.com isn't on the allowlist.
What Structural Least Privilege Actually Looks Like
The implementation is not exotic. Every component here has an analog in how we handle service accounts and temporary credentials for humans and automated systems.
Task-scoped credentials. Don't give agents standing access. Issue credentials at task initiation — analogous to AWS STS AssumeRole or a Kerberos service ticket — scoped to the permissions required for that specific task, with a TTL that expires at task completion. An agent triaging your support queue doesn't need persistent write access to your CRM. It needs write access for the duration of processing one ticket. This single change dramatically reduces the window of exposure when an agent is compromised mid-task.
Read/write phase separation. Structure complex agent workflows so that a read-only "planning" phase precedes any write-capable "execution" phase. The planning phase gathers context, proposes actions, and surfaces them for review. The execution phase holds write credentials only after a human or a trusted system has signed off on the plan. This isn't friction — it's an approval gate that happens to also produce an audit trail.
Egress allowlisting. Every agent deployment should have an explicit list of domains and IP ranges it's permitted to reach. Anything outside that list is blocked at the network layer, not at the model layer. If your agent legitimately needs to call Stripe, Salesforce, and your internal API, those three targets go on the allowlist. Attacker infrastructure does not.
Blast radius auditing. Before you deploy an agent, ask one question: if this agent is fully compromised for sixty seconds, what's the worst outcome? Be specific. Can it delete production data? Forward every email in an executive inbox? Commit contracts on your behalf? Make API calls that trigger financial transactions? If the answer to any of those is "yes," you have a structural problem that no system prompt will fix.
The Uncomfortable Truth
Most teams know they should do this. They ship behavioral controls instead — system prompts that say "don't access data outside your scope" and "confirm before taking irreversible actions" — because behavioral controls take an afternoon to write and structural controls take a sprint to architect.
The attacks that exploit this gap are already in the wild. Prompt injection against agents with standing write access isn't theoretical — it's been demonstrated repeatedly, in production systems, with real consequences. The Air Canada ruling established that organizations are liable for their agents' commitments. The Bing Chat exfiltration path showed that "we didn't intend that egress channel" is not a defense.
A behavioral constraint is a polite request to a probabilistic system. A structural constraint is a wall. Attackers — and edge cases, and hallucinations, and ambiguous instructions — can reason through polite requests. They cannot reason through walls.
The organizations that will get this right are the ones that treat an AI agent the way they'd treat a new employee with a known security clearance problem: verify everything, grant nothing in advance, and make the guardrails physical, not cultural.
The principle hasn't changed. The principal has.