Minimum permissions for AI agents: the principle of least authority applied

Methodology note: all cases described are composite patterns from real audits, modified to protect client confidentiality. No case identifies a single specific client.

February 2026, informal audit at a Turin software house, twenty-four people, development agency for Industry 4.0. The founder is showing me the agent they built to assist their PMs on client projects. (They call him Marco, because their clients like to think of him as a person.) The agent reads Jira tickets, Slack chats, email attachments, and produces weekly status reports.

Works fine, says the founder. I open the configuration.

Marco has a service account on Jira with admin permissions, on Slack with enterprise admin permissions, on Google Workspace with read access to every corporate mailbox. Why admin, I ask. Because in dev it worked. Marco has never written on Jira, never published on Slack, never sent emails. And yet if tomorrow an attacker manages to make him read a ticket the wrong way, Marco can delete everything.

This is the central pattern of ASI03 Identity & Privilege Abuse in the OWASP Top 10 Agentic 2026 (deepened in the cluster on OWASP Top 10 Agentic mapped to Italian SMBs). The risk is not an exotic vulnerability, it's the way most Italian SMBs assign permissions to their agents today.

What the principle of least authority is

There's a classic security principle called "least privilege" (POLP). Give a user only the permissions necessary for their role. The problem is POLP was designed for humans with stable roles and knowable identities.

For AI agents you need something tighter, called "least authority" (POLA), formally formulated by Mark Miller in his 2006 PhD thesis at Johns Hopkins University, "Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control", which originated the E programming language and the entire object-capability security tradition. The practical difference with POLP: POLP regulates permissions per identity (a user or service account has minimum permissions for their role), POLA regulates permissions per capability passed from action to action. For agents, where identity is fluid and every tool invocation is a potentially different action, POLA is the right model.

In concrete terms for an SMB: it's not enough to say "this agent is authorized as this service account". You must say "this agent, when executing this specific action chain, has capability X, Y, Z, scoped to this specific resource, valid for the next fifteen minutes". It's one of the seven operational principles collected in the pillar on agentic AI security for Italian SMBs.

Sounds like over-engineering. It is, only if you've never had an incident.

Three patterns of excessive authority I see always

In audits with Italian SMBs (direct experience not statistically published, take it as such), three patterns of excessive permissions always come back.

Admin everywhere. The Marco pattern above. The agent's service account has admin permissions on every system it's connected to, because in dev it was convenient, because the refactor seemed complicated, because "only the agent uses it anyway". OWASP in its officially documented attack scenarios explicitly cites caching of SSH keys in agent memory as a real vector: if the agent has access to admin credentials for any reason, sooner or later an attacker convinces the agent to exfiltrate them.

Leftover dev permissions. The agent was developed in a staging environment where it had relaxed permissions to allow fast iteration. When promoted to production, someone should have restricted those permissions to baseline minimum. It almost never happens. Production deploy inherits dev credentials, and no one notices until an audit.

Scope creep over time. The most subtle case. The agent was deployed in January with correct permissions. In March someone added a new tool requiring additional permissions, and out of haste added it to the same service account. In April another tool. By June the agent has four times the original permissions, no one tracked the progression, and "minimum necessary" of June is completely different from January's.

The three patterns share a cause: the IAM policy is not a living document. It was written once, never re-read.

How to design a service account for an agent, concretely

Four operational principles that work, based on OWASP Cheat Sheet Series Authorization plus direct practice from audits.

Separate identities. The agent doesn't inherit the identity of the user who invoked it and doesn't run as system root. It has its own technical identity, scopable, revocable independently, monitorable distinctly. OAuth 2.0 with client credentials flow is the modern standard pattern for this. Separation is the foundation of everything: without separate identity, you can't even think of scoping.

Short-lived credentials. Tokens expiring in minutes, not months. Ephemeral X.509 certificates, ephemeral SSH certificates, JWT with reduced TTL. The just-in-time access pattern means the agent doesn't have permanent credentials pre-loaded, it requests them at runtime when needed, loses them when the task finishes. Drastically reduces the blast radius of a compromised agent.

Capability scoping per action. When the agent asks to execute a tool, the capability it receives is strictly the one needed for that tool, not the union of permissions of all tools. If Marco needs to read a Jira ticket, he receives a token with read-only scope on that single project, valid for that session. Not a global admin token used to read that ticket.

Granular audit log. Every privilege use of the agent is logged: what it asked, why, with what scope, when, with what outcome. Five minimum fields. Allows answering questions like "three days ago Marco deleted a ticket, was it legitimate or exploitation?" in thirty seconds instead of three days of forensic. Complete operational pattern in the cluster on audit-ready agents: the logging that saves you.

The four principles together cost design time and zero money (they're patterns, not products). Implementing even just the first two radically changes the risk of an ASI03 attack.

How to test without breaking yourself

Four practical checks to verify if your effective IAM policy matches the documented one. No paid tools needed, just thirty minutes of discipline.

Periodic credentials audit. Once a month, list all service accounts associated with agents, for each enumerate current permissions, verify they match the IAM policy document. Almost always there's at least one agent with non-documented permissions. That finding is the month's fix.

Dry run mode in staging with locked permissions. Change staging configuration so Marco has only documented minimum permissions. Let it run for a week. See what breaks. If something breaks and in production it was seamless, it means production is using non-documented permissions that served some edge case. Most common pattern.

Penetration test targeted at privilege escalation. Once a quarter, ask someone (ideally external) to try privilege escalation via prompt injection or via cross-agent trust abuse. If they succeed, you're in the ASI03 perimeter without knowing. If they don't, your model held. Document the test, it's a DORA-useful artifact.

Quarterly scope drift review. Compare the IAM policy of the current quarter with the previous quarter. How many permissions were added? Were they necessary? Are they still necessary now? Almost always the answer is "someone was added and no one ever used it in production". Those permissions go away.

The four checks together require half a day per quarter. They're the differential between an SMB with production-ready agents and one with agents that work "until something happens".

The painful refactor that avoids the catastrophic incident

When you realize your current IAM policy is the Marco pattern, the temptation is to ignore the problem. Three days of refactor seems high investment against a theoretical risk.

The concrete way to think about it: if tomorrow an important client asks you a DORA-style RFP, and one standard clause is "document that your AI agent uses the principle of least privilege", how long does it take you to produce that documentation? If the answer is less than a day, you're fine. If the answer is "we'd have to refactor first", the refactor isn't theoretical, it's the blocker of the next sale.

The pragmatic starting point, in three steps. Step one: catalog every service account associated with an agent, for each list current permissions and minimum necessary ones. Step two: for each agent, identify the single broadest permission not strictly necessary, and remove or restrict it. Step three: deploy the restricted configuration in staging for a week, collect incident reports, fix if needed, deploy in prod.

Three steps, two weeks of distributed work, zero subsequent operational overhead.

The alternative is waiting for the incident and refactoring during the crisis. It's always more expensive.

Want an IAM policy audit on your production agent? My calendar is public, book an appointment and let's talk. Thirty minutes free, then if it makes sense we build it together. Danilo Lapegna · DL Solutions