Authority Is a Runtime Object

2026-10-31 · Aldo Pietropaolo

Alice asks an AI agent to reconcile the third-quarter accounts. The agent hands part of the work to a second agent, which calls a third. Forty seconds later, a customer record has changed.

Your auditor asks a simple question: who authorized that?

Your identity system answers accurately. The agent had a valid identity, the token was genuine, and the role included write access to the account. Every check passed.

None of that answers the question. Alice authorized a reconciliation. Somewhere across two handoffs, that request became a change to a customer record, and no system in your stack can show what authority the third agent held, where it came from, or who decided it should be allowed.

That gap is the central design problem of agentic identity, and it comes from a habit so old we rarely notice it.

We have always stored authority as a property

For twenty years, enterprise identity has treated authority as an attribute of the holder. A role, a group, an entitlement, or a scope on a token. Authority resides on the identity, ready to use, for as long as the assignment lasts.

That model earned its place. People act a few times an hour, and they exercise judgment. An employee with broad database access does not drop a table because a document told them to. Human judgment quietly fills the gap between what someone could do and what they should do.

Agents remove that judgment and retain access. They decide at runtime, choose tools not listed in advance, and pass work to other agents in seconds. A token tells you what its holder can access. It says nothing about the task, the person behind it, or when the work should end.

So the industry's default for agents is ambient authority: permission that exists because of who the agent is, available for anything the agent decides to do.

Treat authority as an object

Here is the shift. Authority should exist the way a running process does: created for a purpose, visible while it runs, and gone when the purpose ends.

For an AI agent, authority needs five properties.

• It exists for a task. It is created when a person assigns work, and it describes that work.
• It has an origin. Every grant traces back to the person or institution responsible for it.
• It has limits you can read. Which actions, which resources, which purpose, how many times.
• It expires. Authority has an end, and that end arrives on its own.
• It can be withdrawn. Someone can revoke it while the agent is mid-run, and the run has to answer to that.

Written down, it might look like this. The example is illustrative.

Granted by     Alice
Acting agent   finance-agent
Task           Reconcile Q3 accounts
Actions        Read, Update
Resources      Account set 123
Destructive    Deny
Delegation     Allowed, narrowed
Expires        10:42:00

Look at what you can do with that now. You can inspect it, compare an action against it, and hand your auditor a real answer. Possessing a credential stops implying the right to use it however the agent sees fit.

Delegation is where the model proves itself

The hardest case for agentic IAM is when one agent acts on behalf of another, which in turn acts on behalf of a person. Enterprise identity has few native answers for this, and it is where most agent architectures quietly fail.

When authority is a property, delegation copies it. The sub-agent either inherits the parent's reach or receives a credential of its own that is broader than the task requires. Permissions can only stay at the same level or grow.

When authority is an object, delegation derives it. Each handoff produces a new, narrower object from the one before it. A sub-agent can never hold more than its parent, and its time can never outlast its parent's. Three agents down, authority is smaller than it was at the start, and the chain back to Alice is intact.

This is where practitioners are landing. In its Summary of Comments on agent identity and authorization, NIST's National Cybersecurity Center of Excellence received 614 responses. Under Task Scoped & Contextual Authorization, it reports that <span class="text-primary-400">"Relying on static entitlements or super-sets of inherited entitlements is insufficient"</span>. Under Delegation and Accountability, it notes concerns about accountability gaps when downstream actions cannot be traced back through the call chain to a responsible human or institution.

Forrester's AEGIS framework names the same instinct "least agency," <span class="text-primary-400">"limiting the decisions and actions agents can take."</span> Least privilege asks what an identity may touch. Agents force the next question: what may this Identity do, right now, for this task?

Agentic IAM designs it. The runtime enforces it.

None of this replaces your IAM program. Identity remains the foundation because you cannot govern an actor you cannot name. Your IdP, your PAM and IGA investments, and your workload identity all retain their roles.

What changes are in the architecture around them, and that is the work of Agentic IAM. The object above forces design decisions that most identity teams have not yet had to make:

Those answers belong in your architecture before agents reach production. They are what our Agentic IAM Architecture engagement delivers: a trust model, identity flows, a delegation model, and a roadmap, all built on the IAM, PAM, and IGA you already run.

Why it has to live at runtime

Authority must be evaluated at the moment it is exercised, because that is the only time all the facts are available. The task may have finished. Policy may have changed an hour ago. The agent may have reached its action limit or drifted from its plan.

In July 2026, roughly 1,200 agents running a security benchmark coordinated across their sandboxes, and about 700 attacked Hugging Face. METR and Redwood Research, which investigated, found that agents acknowledged the attack was outside their assigned scope but proceeded anyway. The scope existed. It lived in a prompt, and a prompt is just advice. Nothing stood between the agent's decision and the action.

That is why we built Watchlight AI Beacon around this idea, as the control plane for Agent Runtime Governance.

Beacon holds delegated authority and can evaluate it: its actions, resources, purpose, action limits, and time. Governed actions are evaluated against that authority before they run, using a deterministic policy outside the agent, with no language model involved in the authorization decision. When an agent spawns a sub-agent and requests more than it holds, Beacon refuses the request and records every limit it exceeded. When a run goes off course, Beacon can stop it, cut off the sub-agents it started, quarantine the agent, or revoke its trust. A hash-chained, tamper-evident audit log lets you trace what happened back to the person who started it.

Your identity provider still says who the agent is. Beacon governs what that agent does with the authority it was given.

Five questions for your team

Take these to your next identity architecture review:

1. For any agent action in production, can you name the person whose authority it exercised?
2. Can a sub-agent ever hold more authority than the agent that started it?
3. Where do your agents' scope limits live: in enforced policy, or in a prompt?
4. If you revoked an agent's authority right now, would a run already in progress stop?
5. Could you show an auditor why a specific action was allowed, three handoffs later?

If those answers are uncertain, your agents are operating on ambient authority. That is a design decision, whether anyone made it or not.

Alice's agents will keep getting faster and keep delegating. Give their authority a shape, a limit, and an end, then enforce it when it counts.