AI Agents Should Inherit Delegated Authority

When I go on vacation, I don't hand my deputy CISO a copy of my job. I hand them a slice of it.

While I'm out, they can approve an emergency firewall change. They can't sign a vendor contract. Finance still approves payments. HR still approves hiring. The moment I'm back, that slice returns to me.

Nobody writes a new policy to make that happen. It's just how delegation works, and my organization has been doing it for decades.

A recent conversation with Malcolm Harkins made me realize how much that ordinary fact matters for AI agents. The hardest question people ask about agentic AI — who is this thing allowed to act as, and how do we keep it bounded? — is a question organizations already answer every day. We just answer it for people. Malcolm had the right word for it: delegated authority.

This isn't a new practice we have to invent. Finance has been doing it forever. Procurement has been doing it forever. A manager can approve up to one number, a director up to another, a VP up to another — written down, enforced, and audited every quarter. We already know how to give someone bounded authority to act on the organization's behalf.

So why are we trying to invent a brand-new way to do it for AI?

The backbone already exists

The structure we'd need to govern an AI agent this way is one most organizations already maintain. It's the organizational graph.

I want to be precise here. The org chart by itself doesn't hold the details. Approval limits, financial delegation, and emergency authority live in adjacent systems — HRIS, IAM, procurement, ERP, and the GRC and workflow tools that actually route an approval. The organizational graph is the backbone. Those systems hang the specifics on it: who reports to whom, who covers for whom, who's acting in a role this month, and what each of them is allowed to sign for.

We're not missing the structure. We built it years ago, for humans.

Ask whose authority, not what access

So instead of asking what an AI agent should be allowed to access, ask whose delegated authority it's exercising.

The organization should treat the agent as acting under a bounded slice of a specific person's authority — the finance manager's approval limit, not an unlimited one; the analyst's scope, not the CISO's. That's a governance decision, not an implementation one. Whether it's enforced with a workload identity, a service principal, delegated tokens, or something else is a question for later. The governance question — on whose behalf, and within what bounds — has an answer the organization already trusts.

Delegation has always lived inside constraints

Delegated authority has never meant unlimited authority, and this is the part Malcolm kept coming back to.

You still can't request, approve, and pay the same invoice — no matter how senior you are, and no matter how convenient it would be. Handing a slice of authority to an AI agent doesn't suspend that rule. If anything, separation of duties is the first control I'd want to survive the handoff.

The part everyone forgets is time

The dimension most of these conversations skip is time.

My deputy's expanded authority exists because I'm on vacation. It grows during an incident and ends when the incident does. Organizations model this constantly: an incident commander who holds decision authority only for the duration of the event, an acting CIO covering a departure, someone stepping in during maternity leave, a temporary owner assigned to a project that wraps in a quarter. Time-bound authority that expires on its own isn't exotic. It's routine.

An AI agent's authority should carry the same expiration. Standing authority that never lapses is exactly how you end up with a machine identity that outlives its purpose — the service account spun up for one project that still has live permissions two years later. Authority scoped to a reason, and ended when the reason ends, is a norm we already hold humans to.

This also points to an opportunity most organizations haven't taken yet. If an agent's authority is tied to a person and a reason rather than to a standalone credential, it could align with the joiner-mover-leaver processes you already run — shifting when someone changes roles, ending when they leave. Almost nobody works this way today. But it's the right target, and a far easier one to hit than inventing a separate lifecycle just for agents.

Why not just build a new model?

Because a new abstraction has to be worth its weight.

As Julie Tsai put it in the same conversation, "every layer of abstraction has to earn it." A purpose-built identity model for AI has to be genuinely better than the delegation structures you already run — and worth teaching every executive, auditor, and security team a new way of thinking. The structures you have are already trusted, already audited, and already staffed. That's a high bar for a new abstraction to clear.

Where this stops

To be clear about the edges: delegated authority answers who an agent may act for, within what bounds, and for how long. It doesn't govern how that agent is provisioned, scoped, and monitored as a privileged actor in your environment — I wrote about that in AI Agents Are Digital Workers. Govern Their Identities Like It. And it does nothing about model-layer risks like prompt injection. Different problems, different controls. This one is only about where an agent's authority comes from.

The bigger pattern

Delegated authority is only the first example. The same logic holds for the other structures we've spent decades refining — change management, procurement approvals, joiner-mover-leaver, risk acceptance. Each is a governance system security leaders already know how to run. And each is a place an agent could operate inside of, instead of around.

Thanks to Malcolm Harkins and Julie Tsai, whose thinking shaped this piece.