Runtime Authority for Legal and Contracts

A signature isn't binding because someone typed a name -- it's binding because they had the authority to

Legal and contracting functions already operate on precisely delegated signing authority: who can execute a contract, at what value a co-signature is required, who can approve outside counsel spend, who holds settlement authority up to what amount. This structure exists because the organization is bound by what gets signed, regardless of who or what drafted it.

An AI agent that can draft, route, or flag an agreement for execution is operating directly inside that structure. Whether it's checked against actual delegated signing authority before execution is the difference between a control that holds and one that exists only on paper.

The same runtime, evaluating your governance

Nothing about this path changes by industry -- the same Runtime Authority engine evaluates every Intent against your own Authority Graph and Runtime Policies. What changes is whose governance it's evaluating, and what the workflow on either side of it looks like.

Where this shows up in legal and contracts

A governance document was never evaluated at the moment of action

A signing authority matrix is written for a general counsel's office to apply case by case. It's never been evaluated automatically at the point an agreement is routed for execution, because nothing sat between the draft and the signature. Runtime Authority's Authority Graph models exactly who holds signing and settlement authority, and to what extent; Runtime Policies compile the specific conditions -- value, counterparty, contract type -- that determine whether execution proceeds or escalates.

Every decision produces evidence the moment it's made, tying the specific authority checked to the specific action taken -- exactly the kind of record a later dispute over whether an agreement was properly authorized would need.