Least privilege for agents: personas and job descriptions

The confused deputy, again

In October 1988, a three-page paper in an operating-systems journal described a bug from a time-sharing service. A compiler on that system was allowed to write files in its own home directory, where the service also kept a billing file. A user asked the compiler to write its debugging output to a file and gave it the billing file’s name. The compiler obliged, using authority the user never had, and the billing records were overwritten.[1]

The author called the compiler a confused deputy. It held two kinds of authority, its own and the authority its caller lent it, and it could not tell which one a request was using. The episode is a large part of why he argued that authority should travel with each request instead of sitting with the program.

Thirty-eight years later, most AI agents are confused deputies by construction.

Agents run on borrowed identity

Look at how agents reach production systems today. A coding agent runs with the developer’s source-control token. A support agent calls the ticketing system through a service account created for an integration three years ago. A research agent reads the document store with an API key someone pasted into a configuration file. In each case the agent inherits everything that identity can reach, for as long as the identity lasts, and the identity was sized for something else.

That would be manageable if identities were sized well. They are not. Microsoft’s 2023 report on cloud permissions found that identities used about 1 percent of the permissions granted to them, and that more than 60 percent of identities with cloud permissions were completely inactive.[2] Its report a year later put the share of permissions used at 2 percent.[3] Those figures describe people and workloads, before agents arrived to borrow their credentials.

Agents make the gap more dangerous in two ways. They act faster than people, on instructions that can come from content they read, so excess permission gets exercised by whoever writes the most persuasive document. And agents start other agents, so a borrowed identity spreads to processes no reviewer ever saw.

The security community has named the problem. OWASP’s list of top risks for agentic applications defines an agent’s identity as its persona together with the credentials that represent it, and warns that an agent without a governed identity of its own falls into an attribution gap where least privilege cannot be enforced.[4] OWASP’s list of non-human identity risks counts over-privileged identities among its ten.[5]

Give the agent a job

The principle is old. A 1975 paper on protecting information in computer systems listed least privilege among its eight design principles: every program and every user should operate with the least privilege the job requires.[6] NIST’s control catalog states the same rule for users and for the processes acting on their behalf, and its zero-trust architecture asks for least-privilege access decisions made per request.[7][8]

What the principle has always lacked for software is a description of the job. A person has a job description, a manager, a start date and, eventually, an end date. An agent usually has a token.

So write the job down. A job description for an agent states its purpose in a sentence; the principal it works for and whether it may run unattended; the models it may use for each class of data it handles; the data classes it may read and write; the tools and MCP servers it may call, with their verbs and argument rules; a budget and the window it covers; two approvers; and an expiry date. It is a short document. A team can review it in the time it takes to review a pull request.

Then compile it. A job description should not be advice to the agent. It should be the source from which the agent’s permissions are generated. Compiled deterministically, the same job description always yields the same authority record, the same model and tool policy, the same allowance and the same identity template, under one digest that names the version. The agent runs as that persona, and when the job description expires, everything compiled from it expires too.

Asked, granted, used

A job description written once and never revisited would become the next over-privileged service account. What keeps it honest is a comparison across three columns.

Asked is what the job description says the agent needs. Granted is what compiled and was approved, which can be less, because a reviewer narrowed it or an enforcement point could not express a control. Used is what the receipts show the agent actually did during a review window.

The differences are where the signal is. A grant left unused for a whole window is a candidate for removal, and removing it should be cheap: narrowing can only reduce access, so one person can approve it. An attempt that was refused means something else. It may be an attack, a bug or a job description that is wrong, and it deserves an investigation, never an automatic grant. Widening still takes two people.

None of this is unique to agents. Cloud providers have offered the same comparison for human and workload identities for years. AWS can generate a policy from up to 90 days of recorded activity, and Google Cloud’s role recommendations compare granted permissions with those actually used over a similar period.[9][10] The idea works. What agents add is speed and number, which is why the comparison has to run continuously and the narrowing has to be cheap.

Why roles are not enough

The strongest objection is that this is what roles are for. Give each agent a service account with a narrowly scoped role and let the identity system do its job.

Roles are scoped to systems, and an agent’s needs are scoped to tasks. A role that lets an agent update tickets lets it update every ticket, whatever task it is on and whoever’s instruction it is following. Roles also drift upward over time, which is what the 1 and 2 percent figures measure. A role is a sound enforcement mechanism and a poor description of a job, and a persona compiles down to roles and policies wherever those are the mechanisms available.

A second objection is more serious: an agent’s actions cannot be fully predicted, so any job description will be either too narrow or too broad. NIST’s current work on agent identity asks exactly how least privilege should be established for an agent whose required actions may not be predictable.[11] The comparison of asked, granted and used is our answer. Start from a declared job, observe, and narrow toward what is used. A persona does not have to be right on its first day. It has to converge.

The third objection is friction. Engineers route around controls that slow them down, so the design makes the safe direction the cheap one. Narrowing takes one approval, renewal is a date on a calendar, and a persona that lapses takes its keys with it rather than leaving them in a configuration file.

The missing layer

Much of the industry is building pieces of this, and the pieces are good. Identity providers are issuing agents identities of their own; Microsoft Entra Agent ID, for one, gives agents identities separate from people and workloads.[12] Workload identity standards such as SPIFFE give software short-lived, verifiable identities, and an IETF working-group draft applies those ideas to AI agents and calls static API keys an antipattern.[13][14] The MCP specification’s security guidance asks servers to keep the scopes they request to a minimum.[15]

What sits between those pieces is the layer that says what a particular agent is for, and turns that statement into enforcement at every point the agent touches: the model gateway, the MCP gateway, the budget and the data classes. Identity says who an agent is. A persona says what it is supposed to be doing. Without that layer, a well-identified agent can still be a confused deputy.

What we are building

ARC1’s Agent Personas and Job Descriptions are being built in our lab now. A job description compiles deterministically into four records ARC1 already enforces: an authority record for the agent’s actions, policy entries for its models, tools and data classes, an allowance for its tokens and dollars, and a template for its signed workload identity claims. The comparison of asked, granted and used proposes narrowing when a grant goes unused.

The foundations are further along than the persona itself. Authority records and two-person approval run in our released product, on our hosted deployment with synthetic data. Allowances and workload identity claims are built and run in our lab. Refusing persona-bound keys at the gateway and the MCP proxy comes next. Our documentation marks each part LIVE, LAB or NEXT, and it will change as they move.