BengarTrust infrastructure

How it works

One sentence, six flows

Every authorization Bengar makes is the same sentence with different nouns.

WHOauthorizesWHOMto doWHATtoWHICH RESOURCEunderCONDITIONSuntilWHEN→ACTION→PROOF

The first six are a permit. What may happen right now, given circumstances the permit could not know about, is policy. Where the rules say a person must decide, that is an approval. Doing it is execution, and what remains afterwards is a proof.

Authority is the meet of these, never the sum. Nothing in the list can widen anything else in it.

A · An AI purchasing agent

A procurement assistant can order supplies. It runs unattended, it reads email, and it will eventually be told to do something by a document rather than by a person.

  1. Acme creates an identity for itself and one for the agent.
  2. Acme issues a permit: purchase, from `resource://company/procurement/*`, up to 5,000 ₺ per transaction and 50,000 ₺ a month, for 90 days.
  3. The agent asks to buy a 4,200 ₺ chair. Permit allows; policy allows. **ALLOW**, executed, recorded.
  4. An injected instruction in a supplier email tells it to transfer 200,000 ₺ to a new account. It asks. The resource is not covered by the permit. **DENY** — and the attempt is in the audit trail with its reason.

The agent was compromised and nothing was lost. Not because the model resisted, but because what it could ask for was bounded by a document it did not hold the pen for.

B · A company approval workflow

Spending above a threshold needs a person, and the auditor will ask who that person was.

  1. Policy: allow procurement under 5,000 ₺; require approval above it.
  2. A 40,000 ₺ order arrives. **REQUIRE_APPROVAL** — an obligation is opened and nothing proceeds.
  3. An approver opens it and reads the amount, resource and agent as the Gateway states them, not as the previous page displayed them.
  4. They authenticate with a passkey. Custody signs the approval with their key.
  5. The action proceeds, and the audit trail carries who approved what, and what exactly they were shown.

“A human approved it” is only worth something if you can say what the human saw. Here, the signature covers that exact statement.

C · A delegated agent

An orchestrator hands work to short-lived workers, and you do not want each worker holding the orchestrator's authority.

  1. Acme issues to the orchestrator: purchase, all of procurement, 50,000 ₺.
  2. The orchestrator delegates to a worker: office supplies only, 5,000 ₺, two hours.
  3. The worker asks for 20,000 ₺ of furniture. Refused: a delegated permit can only narrow.
  4. Two hours later the delegation has expired on its own.

Authority flows downward and gets smaller. A chain is bounded by its weakest link, not its most recent one.

D · A Trust-gated asset

An issued instrument may only move between parties who satisfy a condition.

  1. The issuer sets a gating policy naming the keys whose authorizations the chain accepts.
  2. A holder asks to transfer. Permit, policy and approval decide.
  3. On ALLOW the Gateway issues an authorization artifact bound to that movement, with a nonce and a short window.
  4. The transfer is submitted with the artifact. The chain verifies it and spends the nonce; a replay is refused.

The transfer rule lives in the authorization pipeline, with an audit trail — not in an administrator key somebody could be compelled to use.

E · Merchant execution, and a timeout

An allowed action has to actually happen somewhere else, over a network that fails.

  1. The ALLOW carries an execution block with a nonce.
  2. The Gateway calls the merchant. The connection drops after the request is sent.
  3. The execution is **UNKNOWN** — not FAILED. The budget stays held and nothing is retried.
  4. An operator checks the merchant's records, finds the order, and resolves it as SUCCEEDED with a note.

The system's honest answer to “did it happen?” is sometimes “I don't know”. Pretending otherwise is how one purchase becomes two.

F · Verifying it, six months later

A reviewer wants to know that a record was not edited after the fact.

  1. The audit event is fetched with its inclusion proof.
  2. The proof is checked against the batch root.
  3. A chain node the reviewer chooses is asked whether it holds that root at that height.
  4. **VERIFIED** — or NOT_WITNESSED, or UNAVAILABLE, each of which means something different.

The trail is checkable by somebody who does not trust the party that wrote it. That is the only kind of audit trail worth having.

Next

Run it · Read the concepts · Use cases