Minimum permissions for AI agents: applying least authority

Take a typical case. An agent reads Jira, Slack and email attachments to prepare status reports. It does not post messages or send mail, yet it uses admin roles inherited from development. The problem is not what it usually does; it is what its credentials allow when input or workflow deviates.

This is the central pattern of ASI03 Identity & Privilege Abuse in the OWASP Top 10 Agentic 2026 (explained in the guide on OWASP Top 10 Agentic mapped to Italian SMBs). The risk is not exotic: it is confusing the agent's declared function with the effective authority of its credentials.

Start with a read-only report and request its actual permissions. A service account is the software's identity; scope describes permitted actions and resources; a capability grants specific authority. IAM means identity and access management.

What the principle of least authority is

Least privilege gives an identity only the permissions it needs. With an agent, however, the service account does not describe the whole risk: the individual tool, resource, duration and capability chain matter too.

Least authority carries the principle to the capability level: each action receives only the authority needed for that resource and time. It is useful for agents because two tools called by the same process can have completely different impact.

In concrete terms, “this agent uses this service account” is not enough. State which tool receives which capability, for which resource, for how long and with what revocation path. It is one of the principles in the agentic-security guide.

For a read-only flow over public data, the design can stay simple. When the system writes, sends or pays, this distinction becomes a concrete measure of maximum harm.

Three excessive-authority patterns to look for

Admin everywhere. The opening example. 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, the possible harm increases if the agent is compromised.

Development permissions left in production. Staging uses broad scopes to speed up testing and production inherits the same identity. Find this by comparing policies and credentials across environments, not by trusting role names.

Scope creep over time. The agent starts with suitable permissions, then each new tool adds scope to the same service account. Measure the delta between the approved baseline and current policy, with a reason for every addition.

The three patterns share one cause: the live configuration and documented policy are not reconciled after changes.

How to design a service account for an agent, concretely

Four operating principles based on the OWASP Authorization Cheat Sheet.

Separate identities. Do not let the agent inherit an administrative identity or run as root. Give it a revocable, observable technical identity through OAuth client credentials, workload identity or the platform equivalent.

Short-lived credentials. The tool-execution component receives a temporary credential valid for the required period. Ending the task requires actual revocation or service-enforced expiry. Duration and breadth are independent limits: a short-lived administrator token still has administrative powers while valid.

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 the agent needs to read a Jira ticket, it 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 use of privilege records identity, tool, scope, timestamp and outcome. The goal is to reconstruct an action without reading indiscriminate transcripts. The full pattern is in the audit-ready agents guide.

These principles do not necessarily require another product, but they carry design, migration and operating cost. The test is concrete: compromise a test tool and verify that access remains confined to the intended resource and duration.

How to test permissions safely

Four practical checks to verify whether the effective IAM policy matches the documented one. They do not necessarily require another product; they require an owner, a cadence and recorded outcomes.

Periodic credentials audit. At a cadence proportionate to the rate of change, list agent service accounts, enumerate permissions and compare them with the IAM policy. Every undocumented permission becomes a finding with an owner and due date.

Test restricted permissions in staging. In an isolated environment, reading a ticket from the allowed project should succeed; editing it should be denied by authorisation. If the service cannot enforce that scope, use a restricted intermediary or keep that step manual. A generic error is not proof of a permissions problem: verify the authorisation refusal in the logs.

Penetration test targeted at privilege escalation. At a cadence proportionate to risk and change frequency, ask someone other than the builder to attempt escalation through prompt injection or cross-agent trust abuse. Success reveals an ASI03 path; failure is evidence about that test, not an absolute guarantee. Preserve the scenario, result and fix.

Scope-drift review. Compare the current policy with the previous baseline. Which permissions were added? Which tool uses them? Are they still needed? Remove those without an active, verified use case.

The time required depends on the number of agents and permissions. This first review is complete when the inventory matches the actual system, each added permission has a reason and every broad permission still needed has a responsible person.

Choose the first change

Restricting an existing system takes work and can break legitimate operations if done blindly. Start with one specific permission and test its replacement before production.

The practical question is simpler: if a customer asks tomorrow for the agent's permissions, owners and controls, can you answer from the live system or must you reconstruct them first? In the second case, the refactor is not only about theoretical risk; it removes an operational and commercial blocker.

Start with an inventory: for each technical agent identity, record current permissions and those required by the task. Restrict the first excessive permission in the test environment, run allowed and denied cases, and retain results. Before production, prepare the previous configuration for restoration and assign someone to check the outcome.

The work is complete when the restricted configuration passes critical staging cases, removed permissions stay removed and someone owns the next review.

Waiting for an incident moves the refactor into the worst moment, when time is short and uncertainty is high.

To apply these checks, bring the workflow description, permissions and test results to the AI agent control and security service. Start with the first concrete gap and define how its correction will be tested.