Least privilege for AI agents: deny by default or get breached
You wired an AI agent to your production API using an admin key because scoping down every tool call felt like busywork. That decision is sitting quietly in your system right now, waiting for the wrong text to land in the model’s context window.
Software engineer Maxi Contieri published a detailed breakdown of the problem and the fix, drawing on three real incidents and Anthropic’s own reference architecture for agentic systems.
Why this matters right now
Anthropic’s November 2025 disclosure put a number on the risk: a state-sponsored group got Claude to run 80 to 90 percent of an espionage campaign against roughly 30 organizations autonomously, pausing for a human at only four to six decision points per target.
In July 2026, an autonomous agent broke into Hugging Face’s dataset-processing pipeline through two code-execution flaws, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a single weekend. Thousands of automated actions across a swarm of short-lived sandboxes, before anyone caught it.
In April 2026, one compromised OAuth token from a third-party AI tool let an attacker pivot straight into Vercel’s internal environment variables. One key, one pivot, done.
The agent is not malicious. It’s just extremely, catastrophically obedient, and the text in front of it is no longer only yours.
️ The structural fix
The core principle is the same one that predates AI by decades: least privilege. Every agent gets only the scopes its specific task needs, never the scopes convenient for every future task.
Contieri describes a three-layer architecture that mirrors Anthropic’s own reference design for agentic systems:
- Skills stay narrow and stateless, one skill per task, not one skill per domain.
- Agents orchestrate skills without holding raw credentials themselves.
- MCP connectors are the only layer that touches a real API, each boundary enforced in configuration, not in a system prompt the model can be argued out of.
The distinction matters. A system prompt instruction is a suggestion. A database role that cannot execute DELETE is a wall, and walls don’t negotiate.
Practical steps
- Scope credentials per agent and per task. A leaked key should expose one narrow capability, not your entire backend.
- Deny access by default and enable each capability explicitly. A tool the model was never given cannot be talked into existing at runtime.
- Sanitize and validate every input that reaches an API, whether a human typed it or an AI model produced it after reading a document you don’t control.
- Treat everything an agent reads from a web page, file, or tool result as untrusted data, never as an instruction, at the exact boundary where that data crosses into your API layer.
- Log every tool call with enough detail that a spike in reads, an off-hours write, or a first-time touch on a sensitive table stands out instead of blending into normal traffic.
- Set automated alerts on anomaly thresholds before deployment, wired to a page or a Slack alert, not checked reactively on Monday morning.
- Revoke elevated access automatically once a task finishes. Don’t leave a session’s permissions standing until someone remembers to clean them up.
- Pentest your AI pipeline the same way you pentest any other API surface: feed it hostile prompts, malformed tool results, and injected instructions, then confirm the blast radius stays where you designed it.
The threat is not staying still
In August 2025, ESET researchers found PromptLock, a ransomware proof of concept that calls a local AI model to write its own malicious scripts on the fly instead of shipping them pre-written. It was not caught in a live attack, but the direction is clear: the code that exploits your over-privileged agent no longer needs a human author.
The OWASP Top 10 for LLM Applications has listed prompt injection at the top for two years running. You can’t patch it away. The fix has to live in the API sandbox boundary the model’s output has to cross before it does anything real.
The honest limitation
Least privilege shrinks the blast radius of a compromise. It does not prevent prompt injection, and no current defense fully does. A narrowly scoped agent can still leak data inside its narrow scope. Retrofitting layered permissions onto an existing system with years of shared credentials also takes real engineering time, not a config change on a Friday afternoon.
But the alternative is fifteen agents sharing one admin key, and someone else noticing before you do.
The prompt difference in one example
The article includes a side-by-side prompt comparison that illustrates the gap concretely. The bad version connects a support agent to the production database with an admin account and instructs it to execute whatever the customer email asks for. The good version gives the agent exactly one tool: lookup_ticket_status(ticket_id), scoped to a read-only replica of the tickets table only, with no credentials, no write access, and no network access beyond that single call.
When both versions receive the same customer email containing DROP TABLE audit_logs and an instruction to export the full users table to an external URL, the scoped agent attempts both actions, gets 403 Forbidden on each because neither tool exists for its role, and flags the attempt to the security queue. The admin-key version just obeys.
The full breakdown, including the layered architecture diagram and detection guidelines, is on HackerNoon.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
