Agent Personas and Job Descriptions

A job, not an identity

Most agents today run on borrowed identity: a developer’s token, a shared service account, a key copied into a configuration file. They inherit everything that identity can reach, for as long as it lasts. Least privilege for people took years of role design. Agents arrive faster than roles can be written, and many of them are started by other agents.

A persona is a named, versioned job that an agent runs as. Its job description is the source, and everything the agent may do is compiled from it. The argument behind the design is set out in Least privilege for agents.

What a job description states LAB

• Its purpose, in one sentence: the only free text.
• The principal it works for, and whether it may run unattended.
• The models it may use, by the data classes it handles.
• The data classes it may read and the data classes it may write.
• The tools and MCP servers it may call, with their verbs and argument rules.
• Its budget and the window the budget covers.
• Two approvers and an expiry date.

What it compiles to LAB

A job description compiles into four records the rest of ARC1 already understands: an authority record for its actions; policy entries for its models, tools and data classes; an allowance for its tokens and dollars; and a template for its workload identity claims. Compilation is deterministic. The same job description always yields the same four records and the same digest, so a reviewer sees exactly what an edit changes before anyone approves it.

Applying a persona goes through the same two-person approval as any policy change. Receipts name the persona’s version; refusing a key presented under any other version is the next step. Sub-agents inherit their parent’s persona and may be narrowed, never widened. A persona that is not renewed lapses, and its keys lapse with it.

Asked, granted, used LAB

Three columns keep a persona honest. Asked is the job description. Granted is what compiled and was approved, which can be less, because a reviewer narrowed it or a target could not express a control. Used is what the receipts show the agent did.

When a grant goes unused for a full review window, ARC1 proposes narrowing it to what was used. Narrowing needs one person, because it can only reduce access; widening still needs two. An attempt that was refused becomes an item to investigate, never an automatic grant. Over time the granted column converges on the used one, which is what least privilege looks like when it is maintained rather than declared.

What it builds on

Personas are new; their parts are not. Authority records and two-person approval run in the released product. Policy compilation to managed coding agents and to Kong, Azure API Management and LiteLLM is in the hub, with the evidence Policy IR lists. Gateway allowances and signed workload identity claims are built and run in our lab.

Where it stands

LIVE: in the released product and running on our hosted production deployment, with synthetic data. LAB: built or being built, and run only in our lab or against a vendor’s documented interface. NEXT: designed, not yet built. How we use these words.