Delegated authority
The actor is not the principal.
When software acts on a person’s behalf, two identities are in play. Whoever makes the call, and whoever the call is for. Most systems record one and enforce the other, and that gap is where delegation goes wrong.
The AI agent did not create this problem. It is the newest shape of a decades-old one, and it is the one Vengtoo was built to solve.
One problem, eight shapes
Every one of these is the same thing: a piece of software doing something for a specific person who is not there to click “yes.” The first four are older than most authorization products. The agent is the fifth to arrive, not the first of a new kind.
Background job
Runs payroll or a nightly export as the finance team, hours after everyone signed off.
Service chain
Service A calls Service B carrying “this is for Dana” in a header nobody can verify.
Scheduled task
A recurring workflow acts on a schedule its owner set weeks ago and has since forgotten.
Webhook callback
An event fires long after the user left, and does something with their authority.
AI agent
The newest arrival. An autonomous caller taking actions on a person’s behalf, at machine speed.
Support impersonation
An operator clicks “act as this customer” to debug an account they do not own.
Batch / act-as-many
One process performs an action for thousands of users in a single sweep.
Cross-org delegation
A partner’s system acts inside yours, under authority you granted but do not control.
This is not a new problem. It has been hand-rolled badly for decades.
The industry has been answering “act on this person’s behalf” the whole time. With spoofable impersonation headers, with service accounts handed god-rights “just in case,” with audit logs that cannot say who an action was really for. It worked well enough while the callers were slow, few, and internal.
Then the caller became an autonomous agent: fast, numerous, and reasoning about what to do next on its own. The same weak machinery is now load-bearing in a way it never was. Nothing about the problem changed. The blast radius did.
So the interesting question is not “how do we authorize AI agents.” It is the older one nobody finished answering. How does one identity act with another’s authority, safely, when the second is not there.
The mistake is treating them as one identity
For decades of “Dana clicks a button,” the actor, the principal, and the subject of the authorization question were all the same person. So the words got used interchangeably and the distinction never mattered. Delegation is the moment it splits, and a system that still assumes one identity fails in a specific, repeatable way.
Who is making the call right now. The agent, the job, the service. The party physically performing the action.
Whom the call is for. The person whose authority is actually being spent, narrowed by the terms of the delegation.
Record the actor but enforce the principal, and the audit log names the wrong party. Collapse them into one and the agent inherits the person’s full rights, permanently, instead of a scoped and revocable borrow. Keep them apart, as two distinct fields on every decision, and delegation has somewhere correct to stand.
What “getting it right” actually requires
Strip the problem to its requirements and the same list falls out every time, whether the caller is a background job that predates the cloud or an agent from this morning.
Act with no session
The person is not present. The system must be able to act for them without a live login to lean on.
Authenticate the caller
Know which software is calling, as a first-class identity. Not a spoofable header or a shared secret.
Least privilege
The borrowed authority is scoped down, never up. A delegate can do less than its principal, never more.
Delegation integrity
Every hop narrows. A chain of delegations is capped by its tightest link, not its most recent one.
Dual audit
Record both who acted and who it was for. Conflating them is how the log ends up blaming the wrong party.
Business authorization preserved
Delegating a task does not delegate around a control. Approval gates hold even for a delegated caller.
What it took to build
Anyone can assert this is hard. Here is where it bit us.
Delegation reads simple and behaves treacherously. Building it, we hit four cases where the intuitive implementation was quietly wrong. We are naming them because a vendor that has met these traps is worth more than one that claims never to have.
Grant, not constraint
There are two ways to model delegation, and the obvious one is wrong. Treat the delegation as a constraint on the delegate’s own permissions and you are forced to first over-provision the delegate: give the agent broad access, then narrow it, which is the opposite of the point. Treat it as a grant borrowed from the principal, and the delegate needs no standing access of its own at all. We shipped the second.
Revoking access could widen it
Under one implementation, revoking a delegation part-way down a chain did not close the borrowed access. It let a downstream party fall back to broader standing rights it had held all along. The act meant to reduce access increased it. We found it, reproduced it, and fixed it.
A delegation walked past the approval gate
An action marked as requiring human approval was reachable without it, if the caller arrived under a delegation. The delegation was quietly acting as a way around a control. Acting on someone’s behalf is not a loophole around the gate. The gate holds for the delegate too.
The record named the wrong party
A decision made under delegation logged the delegate as the subject, the one party whose permissions were never actually consulted. The authority came from the principal; the audit credited the actor. Two different identities, and the log picked the wrong one.
The delegated-authority layer
Users, services, devices, and AI agents. One engine that keeps the actor and the principal apart, narrows every borrowed grant, and records both sides of every decision.