Topics

Human-to-agent authority: where every mandate starts

Human-to-agent authority is the first delegation in any agent's chain of authority: the point where a person who holds decision rights inside the organization grants some portion of them to an agent. Every subsequent hop, agent to agent, derives from this one. If the first grant is unclear, everything downstream inherits the ambiguity.

Why the first hop matters most

An organization can only delegate authority it actually has, through people who actually hold it. A support director can delegate refund authority because the organization gave it to them. A developer who deploys a refund agent cannot delegate refund authority, because they never held it. If the agent's mandate comes from the developer, the delegation is invalid at its root, regardless of how carefully the rest of the chain is built.

This is not a theoretical concern. In most agent deployments today, the person who defines what the agent may do is the person who built it, and the person who is accountable for the decisions it makes has never seen the configuration. The authority did not come from where it should have.

The owner field is not a delegation

The standard response is to add an owner. Find the agent, assign it a human, and now every agent has a person behind it.

An owner is a label, not a control. Knowing who to call after the agent has moved the money says nothing about what it was allowed to decide before it moved the money. The owner field puts a name on the incident report. It does not change what the agent does.

It also does not scale. Assigning owners works for dozens of long-lived agents. Agents are increasingly spawned by workflows and other agents and torn down when the task is done. The people named as owners end up accountable for things they never saw and could not have reviewed. We already know how this ends because we ran the experiment with human access reviews, which became a quarterly rubber stamp.

And it only reaches the agents that were found. An agent built on a laptop with a borrowed key has no owner and is not governed.

What a human-to-agent grant should look like

Our position is that the grant should be a policy the human owns, not a property of the agent. It states the class of decisions the agent may make, the constraints on each, the cumulative ceilings across a run, the conditions under which the rights do not apply, and where a decision goes when it reaches the boundary. The human who owns the policy is accountable for every decision made under it.

This attaches accountability to the rule, not to the actor. It scales because the number of policies tracks the kinds of decisions a business makes rather than the number of agents. It reaches unregistered agents because any agent attempting that class of decision is evaluated against the policy. And it puts the accountable person where they belong: attached to a rule they wrote and can defend, rather than to the actions of software they never reviewed.

Inheriting the human's permissions is not the answer

A more sophisticated version of the owner field has the agent act as the user, inheriting that person's permissions. This sounds like human-to-agent authority and is the opposite.

It hands the agent the human's full reach, not the human's intent. A director with refund authority also has the sense not to issue fifty refunds in ten minutes. That restraint was never encoded anywhere; it lived in the person. The agent gets the entitlement without the judgment, and the access system cannot tell the difference, because from its perspective the director is just very busy today.

It also corrupts accountability. When an agent three hops down makes a bad decision, the record says the human did it. Making a person answerable for decisions they never saw is liability transfer, not accountability.

Where BotAris fits

BotAris roots every delegation in a human-owned policy in the Authority Model. Decision rights carry provenance: who granted them and on what basis. Escalation goes to the accountable human named in the policy. The ledger records, for every decision, which policy applied and who owns it.

Frequently asked questions

Who should grant an agent its authority?

The person who holds that decision authority in the organization. For refunds, the leader accountable for refunds. Not the engineer who built the agent, unless they happen to be the same person.

Is assigning an owner to each agent enough?

No. An owner is a name for the incident report. Human-to-agent authority means a written mandate the person owns and the agent is checked against, not a contact field.

What if an agent's action falls outside every policy?

Then no human has delegated that decision to any agent, and it should not proceed. It is denied or routed to a person, and the attempt is recorded.

Keep up to date on Authority Governance

Long-form writing on defining, enforcing, and proving what AI agents are allowed to decide. No product pitches.

Confirm by email. Unsubscribe anytime.

Humans define authority. BotAris enforces it.

BotAris is onboarding a limited group of enterprise design partners. Design partners shape the product roadmap and receive early access. If you are putting agents into workflows with real consequences, we want to talk.

Related topics