Product 02

An agent acted at 03:12.
Six weeks later someone asks who allowed it.

AFA keeps a signed, ordered record of what an agent did and was allowed to do. You check it on your machine, without asking us.

  • Hashes, not promptsThe record holds a digest, never the text.
  • Detection, not preventionA changed entry breaks the link.
  • Checked without usThe check runs on your machine.
Delegation shape / demonstration
Authority tree expanding from one to seven agents A human root delegates to scoped agents. Additional branches appear while the authority boundary remains fixed. H GATE A1 A2 A3 T1 T2 T3 X DECLARED AUTHORITY BOUNDARY OUT OF SCOPE
Active agents3
Authority boundaryFixed
Out-of-scope pathBlocked
01 / What the record does not do

A valid signature does not mean the action was right.

AFA signs each envelope and preserves event order. That exposes a changed record, an expanded scope, and approval added after an action. For disputed work the same record can support chronology; it does not decide who owns the work.

AFA HELPS WITH
  • Checking supported actions before they run
  • Comparing a child envelope with its parent
  • Pausing actions outside configured scope
  • Preserving signed chronology and content digests
AFA DOES NOT
  • Replace operating-system permissions or a sandbox
  • Infer intent from private reasoning
  • Store raw prompts, source code, or secrets
  • Decide authorship, ownership, originality, or truth

Current foundation: SHA-256 digests and Ed25519 signatures. Integrity is not truth. Governance is not a sandbox.

Read the security and privacy model
02 / What it is for

More agent work does not have to mean unlimited access.

AFA is designed to help teams run longer tasks, control spending, coordinate more agents, and review what happened afterward. Each agent can have a clear limit, stop point, and human owner. These are practical examples, not measured gains. We have not measured a capacity multiplier.

01 / Time

Work that ends when you said

A grant carries an expiry and can be revoked earlier. Check: GET /v1/grants/status names the tools and the expiry.

02 / Money

Spending that can pause

On a supported host, a rule can hold model spending for a person. Usage is counted per key, not billed. Check: GET /v1/usage/summary.

03 / Operations

Several agents, named owners

AFA records which child agent started under which parent. Call budgets and parent containment are checked at the gate. Per-child file-path scope is still open.

04 / Evidence

Read the handoffs back

Signed summaries preserve the order of work across agents. They show what ran and under which grant. They do not say the action was right.

03 / The authority loop

Check before the tool runs.
Keep a record after.

A normal log tells you what already happened. AFA is designed to add a decision before a supported action, then keep a receipt afterward.

I S G A R
Request Name who is asking and what the work is for.

Before a tool is reached, the task gets a clear owner, purpose, time limit, and parent.

04 / Delegation

Split the work.
Keep the limits.
Bring it back for review.

When several agents work at once, AFA helps preserve who started each branch, what it was allowed to reach, and where a person must step in.

Scoped delegation branches and a human merge gate A root instruction branches to research, build, and review. An out-of-scope network action is denied before the approved branches merge. HUMAN INTENTsigned root SCOPEsplit RESEARCHread only BUILDworkspace write NETWORKnot granted HUMANmerge gate RECEIPTordered
ExpansionMore branches, not more ambiguity.InterventionThe denied path remains visible.
05 / The drift envelope

Keep the job around
the work.

AFA wraps a task in a signed envelope: owner, purpose digest, scope, action class, time mode, and parent. As work branches, envelope changes can be compared. On a supported host, an explicit boundary crossing can pause or stop before the tool runs.

01 / AnchorOwner + purpose digest
02 / BoundScope + time + parent
03 / CompareEnvelope delta + policy
04 / InterruptAllow + ask + deny

AFA surfaces structural drift. It does not infer intent from private reasoning, and broad limits still permit broad behavior.

Authority trace / demonstrationDEMO
  1. intentowner + purpose boundsha256:7c1d...a8
  2. delegationchild envelope linkedsha256:883e...19
  3. envelope_deltanetwork scope addedsha256:0ad4...72
RETAINED event class / parent / decision / digest / signature NOT RETAINED prompt / source / secret / chain of thought
06 / MCP + API

Three ways in.
The same control model.

The hosted API is live. Connect an agent host over MCP, call the REST API from your own code, or open the console. All three read and write the same record on one account, and the docs cover each one, limits first.

01 / Connect a host

MCP

Bring AFA action checks and signed records into a compatible agent host over the hosted endpoint. A tool call is one HTTPS request; nothing runs offline.

Live
02 / Work across machines

Hosted API

Per-machine keys, signed records, sub-agent grants, delegation tokens, notifications and usage counts. Verification runs without our servers.

Sign in for the docs
03 / See what the API knows

Console

Email sign-in, keys, records, grants and notices for one account. It shows what the API knows; nothing is inferred.

Sign in

Not offered. There is no client library to install and no portable evidence file to download. A private client for one integration can be discussed on request.

Hosted API Live

The account and API layer is live. Its limits come first.

Sign in, create a key for one machine, write a record and check it. Before relying on anything, read the limits: the record holds hashes, not payloads; it detects changes, it does not prevent them; a host must deliver the action to the gate.

There is no client library to install and no evidence file to download. A private client for one integration can be discussed.

Seats are limited. Seats are bounded by review capacity, not by infrastructure.