Delegated Authority Framework

Governing AI agents that don't just answer. They act.

Executive summary

AI agents are moving from assisting to executing, and that changes the question. It stops being what a model can do and becomes what this agent is allowed to do right now, under whose authority, with what reach, and on whose record.

DAF is my answer in progress: a governance model I research, design, and drive on my own time. Enterprise customers, asked separately what they need before agents touch production, described its core controls almost line for line.

12 slides · about 3 minutes
The problem

An AI agent has already deleted a production database it had explicit written instructions not to touch. The instructions were right there. They described intent, and intent is not a constraint.

That's the founding observation. Rules in a prompt are not governance, because nothing in the system is checking them before the action lands.

The two obvious fixes both fail. Approve every step and you've built a bottleneck that erases the reason you wanted agents. Approve the goal and let it run and you get visibility only after something breaks. Supervision doesn't scale down to useful, and trust doesn't scale up to safe.

And underneath both sits the quiet trap: individually authorized actions can chain into an outcome nobody authorized. Every step passes. The trajectory is the problem. Governance that lives in a policy document can't see a trajectory, which is most of why governance that lives in a policy document isn't governance.

The evidence

In April 2026, at Adobe Summit, C-suite and senior technology leaders from six enterprise customers spent a two-hour session designing the controls they would need before deploying multi-agent AI. Banking, healthcare, advertising, asset management, fintech, and professional services.

They weren't blocked on capability. They were blocked on governance, and four controls came back as non-negotiable before agents reach production.

Control 01
Agent identity

A persistent, unique identity for every agent, separate from user accounts and API keys, tied to a named human owner who is accountable when it goes wrong.

Control 02
Kill switch

The ability to halt a running agent mid-execution, without waiting for the current step to finish.

Control 03
Full audit trail

Every invocation, the reasoning chain, the sources consulted, the decision at every node.

Control 04
Cost attribution

Spend per agent, rolled up to real budgets. Participants cited an incident where a single agent generated a $20,000 bill overnight and finance blocked the deployment.

An AI agent should always be tied to a human — somebody should take accountability for it. I'm not saying co-pilot. I'm saying superpower.
A marketing technology architect, CAB participant (Saksena, 2026)

They also asked for autonomy as a dial rather than a switch: when an agent may act, when it must ask, when it escalates, set per agent and per task type.

I didn't run this research. It was developed, facilitated, and reported by Shrut Kirti Saksena, Staff Experience Researcher at Adobe Design Research & Strategy, in April 2026. What it gave my work is the thing you can't manufacture: independent confirmation. These leaders designed from a blank page and landed on the controls I had been building toward.

Capability is the engine. Authority is the license.

The framework

Treat an AI agent like a new hire, not a new tool.

You'd never hand a new employee every system password on day one with no manager and no record of what they did. You onboard them: an identity, an accountable owner, a scope, permissions that grow with trust. Then you manage them: assign work, decide how much rope each task gets, review what happened. That's the whole framework in one metaphor, and four ideas do the work underneath it.

Idea 01
Capability is not authority

Capability is what an agent is able to do, a function of its skills and tools. Authority is what it's permitted to do right now, delegated by a human and enforced by the system. Most AI safety argument is about capability. Enterprises can only govern the second one.

Idea 02
Authority has two planes

The organization sets an envelope per role: the ceiling of what anyone in that role may delegate. An individual issues a contract within that envelope, to a specific agent, for a specific task. An intern can't grant their agent VP-level authority, for the same reason an intern can't authorize a wire transfer.

Idea 03
Authority only flows down

An agent's authority is always a subset of the human who delegated it, and sub-agents get an attenuated slice. Delegations can't be pooled to exceed the root. Every action lands in a signed ledger traceable to a person, so "the agent did it" is never the answer.

Idea 04
Engineer the reach

Authority isn't a yes-or-no gate, it's the deliberate shaping of how far an action can reach before a human is required. Binary forces a false choice: lock the agent down and it's useless, let it run and it's unsafe. The third option is a bounded, reversible, observable radius with a human gate at the edge.

Making that enforceable means classifying every consequential action before it runs: what does it touch, how far does it reach, can it be undone. Risk tiering is what turns a principle into a pipeline.

The pipeline
01ProposeThe agent states the change it wants to make.
02ClassifyThe system tiers the risk: what does this touch, how far does it reach, is it reversible.
GateGateAuthority is checked against the contract.
Escalate to a human
04ExecuteThe action runs, or waits. Either way, the ledger records it.

The order is the point. If you gate after the side effect, it isn't approval. It's incident documentation.

26 slides · PDF
Making it visible

Governance you can watch happen

Two surfaces make the model real. The Authority Inspector is where a person sees and reasons about what an agent may do: its contract, its reach, what it has touched. The Authority Ledger is the record of authority granted, used, escalated, and revoked. Not a compliance artifact, a queryable trace of what actually happened.

Then I built it. The Governed Action Pipeline is one screen where you watch an agent propose a change, see it classified, see authority checked, and see it either execute or stop for a human, with every step landing in the ledger. Mocked data, clearly labeled, built so a leadership audience gets the model in under a minute. The rule I held it to: at least one action auto-executes and at least one escalates, so you can see the gate doing real work.

Where it stands

Internal platform work is now asking concrete governance questions: how agent identity should work, whether a kill switch is per agent or per organization, where autonomy configuration lives, how spend gets attributed. For each of them this framework already argues an answer, and that mapping from question to position to product gap is the working document I bring to those conversations.

It's a provocation, not a finished framework, and pretending otherwise would invite exactly the wrong critique. The open questions stay visible on purpose. Who owns the organization-level envelope. What happens to delegated authority when the person who granted it leaves. How scoped credentials get issued fast enough at fan-out scale. And the hardest one, which isn't technical at all: convincing enterprises to certify boundaries and audit traces instead of certifying processes.

So the ask isn't a greenlight. It's a cross-functional working group to pressure-test the model against real products. I drive this alone. The point of it is to stop being alone with it.

Execution can be autonomous. Authority cannot.

The mirror

This framework didn't come from nowhere. Unified Review & Approvals, the product work I lead, is already a governance layer for execution: a person proposes, the system routes, a decision gates what ships, and the record holds. DAF asks what that model becomes when the thing proposing is an agent.

AI Collaborators is where the question gets concrete. A collaborator's profile shows what it can do and what it's doing. Setup can switch actions on and off, which is real governance as far as it goes. What a permission doesn't say is how far one action may reach before a human is required, on whose authority it was granted, or what happens to that grant when the person who issued it leaves. That gap is the reason this framework exists.

And I don't only argue the model, I live inside it. My second brain runs my work memory on the same shape: the AI proposes, I govern, git records. Every file an agent writes is a proposal until I commit it.

The shipped governance layer this started from.

Unified Review & Approvals

Where the authority gap shows up in a real product.

AI Collaborators

The same model, running at personal scale.

Sancho
For AI and deep readers

This page is the story. The dossier is the record.

The full dossier carries what the page compresses: the complete framework, the verified customer evidence, the decision log, and the open problems kept visible on purpose. Written for the AI you'll paste this page into. Open to everyone.

www.arnoldp.com/dossiers/daf.md