Imagine giving an employee a corporate purchasing card with a $250,000 limit.

They are negotiating a $40,000 cloud-compute contract.

Should the supplier be allowed to see that the employee can spend $250,000?

Of course not.

The supplier needs to know that the purchase is authorized.

It does not need to know the employee’s full budget, how much has already been spent, what other purchases are planned, or who inside the company approved the card.

Now replace the employee with an autonomous AI agent.

The previous article examined how observers can infer a company’s decision rules from agent behavior. Here, the question is how an agent can prove its authority without exposing its full mandate.

Control of funds is not authority to spend

An AI agent may control a wallet containing millions of dollars.

That does not mean the CFO authorized it to spend millions of dollars on anything it wants.

That sounds obvious in human organizations. We have spent centuries building legal and operational machinery around delegated authority.

Employees have signing limits.

Executives have approval thresholds.

Corporate cards have category restrictions.

Procurement teams have vendor policies.

Attorneys operate under powers of attorney.

Banks honor mandates.

The ability to move money and the authority to move money are different things.

Autonomous agents need the machine-verifiable equivalent.

Custody answers: “Can it?”

Authority answers: “May it?”

If software is going to negotiate contracts, select suppliers, commit funds, and settle transactions across organizational boundaries, counterparties will eventually need to verify both.

I use the phrase cryptographic power of attorney as an architectural analogy, not as a claim that a cryptographic mandate is itself a legally recognized power of attorney. The legal effect would depend on the surrounding agreements, jurisdiction, and implementation.

The analogy is useful because it points to the underlying requirement: delegated authority should be bounded, provable, and separable from simple possession of a key.

What should the seller be entitled to know?

Suppose a procurement agent wants to purchase $40,000 of compute capacity.

Its principal has authorized it to:

  • spend up to $250,000 in total,
  • spend no more than $50,000 per transaction,
  • purchase only approved infrastructure services,
  • transact before Friday,
  • and delegate limited authority to specialist sub-agents.

The supplier needs confidence that the proposed $40,000 transaction falls inside those rules.

But should the supplier learn the full $250,000 ceiling?

Probably not.

Should it learn that only $60,000 remains?

That could weaken the buyer’s negotiating position.

Should it learn who else received delegated authority?

That could expose internal workflow structure.

Should it learn the principal’s identity if the commercial relationship does not require it?

Again, not necessarily.

What the seller needs is a much smaller statement:

This agent is authorized to make this transaction.

The counterparty can verify that the transaction satisfies the mandate’s constraints.

But the mandate itself does not have to become public.

Why revealing the mandate creates a new privacy problem

Traditional authorization systems often assume that whoever verifies authority is allowed to inspect it.

That works reasonably well inside one organization.

It works much less well when autonomous agents negotiate across corporate boundaries.

If every counterparty can inspect an agent’s full mandate, authorization becomes another source of competitive intelligence.

A seller could learn:

  • the buyer’s total budget,
  • its maximum per-transaction ceiling,
  • its deadline,
  • its permitted vendor universe,
  • whether authority was delegated,
  • and potentially how much spending capacity remains.

At that point, the authorization system itself becomes an information leak.

The goal is authority privacy:

Prove that an agent’s proposed action falls within its delegated mandate without revealing the full mandate.

That is where zero-knowledge proofs become especially useful.

A spending limit is not a credential

A traditional credential is usually a fact.

This person is over 21.

This company passed KYC.

This entity is incorporated in Delaware.

A spending cap is different.

It is consumable state.

If an agent receives authority to spend $250,000 and then spends $40,000, it should have $210,000 of authority remaining.

If it delegates $50,000 to another agent, the two agents should not end up with $260,000 of combined authority.

And if both agents attempt to spend at the same time, the system must still guarantee that the principal’s original limit cannot be exceeded.

This means a mandate cannot merely be a signed document saying:

“Agent X may spend up to $250,000.”

Something has to track how much authority has already been consumed.

The obvious solution is a centralized authorization server.

But then every transaction depends on that server being online, trustworthy, and willing to approve the next action.

There is another approach.

Treat authority itself as private, consumable state.

Authority can behave like value

Imagine the original $250,000 mandate as a private authorization note.

The agent spends $40,000.

The original mandate is consumed.

A successor mandate appears representing the remaining $210,000.

Conceptually:

$250K mandate
     │
     ├── $40K authorized spend
     │
     ▼
$210K remaining authority

Now suppose the procurement agent wants a specialist infrastructure agent to handle a $50,000 sub-task.

It can split the authority:

$210K mandate
     │
     ├──────────────┐
     ▼              ▼
$160K retained    $50K delegated

The critical rule is conservation:

Agents should not be able to counterfeit authority any more than they should be able to counterfeit money.

Across spending, splitting, and delegation, total authority must never exceed what the principal originally issued.

That is much harder to guarantee with ordinary bearer tokens or reusable credentials.

It becomes natural when authority is modeled as consumable cryptographic state.

Delegation should narrow authority, not multiply it

Delegation is essential for autonomous organizations.

A purchasing agent may delegate freight procurement to one agent, compute purchasing to another, and software licensing to a third.

But each delegation should narrow authority rather than silently expand it.

A child agent might receive:

  • a smaller cap,
  • an earlier expiry,
  • fewer approved recipients,
  • or a shallower ability to delegate again.

When authority moves to another agent, the system needs confidence that the recipient controls the key to which it was assigned.

Otherwise a typo or malicious substitution could send authorization into a cryptographic black hole.

This begins to resemble traditional organizational governance, except the rules can be proven during execution rather than reconstructed afterward from access-control logs.

Revoking authority without confiscating assets

Delegated authority also needs revocation.

If an agent is compromised, dismissed, or no longer needed, the principal must be able to revoke its authority to spend.

Revoking an agent’s authority should not give the principal, operator, or platform the power to seize assets the agent or another counterparty already legitimately owns.

Those are different rights.

The principal owns the mandate.

The asset holder owns the asset.

So the rule should be:

Revoke the authority. Don’t seize the asset.

Revocation should change what an agent is authorized to do next.

It should not retroactively rewrite ownership.

How ZKM approaches the problem

This is the problem we are exploring with Zero-Knowledge Mandates (ZKM).

ZKM represents principal-issued spending authority as private committed state.

A mandate can encode a total spending cap, expiry, policy constraints, the agent authorized to exercise it, delegation depth, and revocation state.

When an agent spends, the proof can establish that the mandate is valid, the proposed amount is within the remaining cap, the policy is satisfied, and the agent exercising it is authorized.

The verifier does not need to learn the original cap, remaining balance, principal identity, prior spend history, or delegation graph.

The spend consumes authority and creates successor authority representing what remains.

Delegation does the same thing without moving value.

And revocation kills future authority without freezing the underlying settlement asset.

That separation is deliberate.

Why this matters beyond crypto

It would be easy to describe this as a blockchain authorization problem.

I think it is broader than that.

Autonomous agents will eventually need to exercise authority over:

  • purchases,
  • subscriptions,
  • cloud resources,
  • financial accounts,
  • data access,
  • intellectual property,
  • contractual commitments,
  • and other agents.

Each domain will need an answer to the same question:

How does software prove that it is acting within delegated authority?

Today, many agent systems collapse authority into API access.

If the agent has the credential, it can perform the action.

That is convenient, but it is a coarse security model.

Possessing a Stripe API key does not explain which purchases the principal intended.

Holding a wallet key does not establish which payments the CFO approved.

Being able to call an infrastructure API does not prove that scaling a cluster from 20 servers to 2,000 was within mandate.

As agents become more autonomous, possession-based authorization will not be enough.

We will need authority that is:

bounded, delegable, consumable, revocable, private, and provable.

The question ahead

Human organizations already understand delegated authority.

We have powers of attorney, corporate bylaws, purchasing limits, signing authorities, escrow instructions, and banking mandates.

The machine economy will need equivalents.

But simply digitizing those documents is not enough.

Autonomous agents will negotiate with other autonomous agents at machine speed, often across organizations that do not fully trust one another.

Their authority will need to be verified just as quickly.

And if we design that verification badly, we may solve the authorization problem by broadcasting every organization’s internal limits and delegation structure to its counterparties.

The better question is:

When an AI agent makes a $100,000 purchase on your company’s behalf, what exactly should the seller be entitled to know about the authority behind it?

My answer is increasingly simple:

Enough to prove the purchase is authorized.

And nothing else it does not need.

Disclosure: I am an active contributor to the ZKM/ZKA/ZKC/AFP protocol family discussed here. ZKM remains draft-stage protocol work, and the architectural ideas described above should be evaluated as proposals rather than production assurances.

Authority answers whether the agent may act for its principal. The next article asks what the counterparty needs to verify about eligibility, and how to prove those facts without turning compliance into surveillance.