Mandate — Agents you can point at a ledger

A prompt is a request.
This is a decision.

Most agent safety is written in the system prompt, which means it can be argued with. Mandate moves it into deterministic code that runs before anything happens. An agent that has been jailbroken, prompt-injected or is simply confused can ask as many times as it likes and still move nothing.

No privileged surface

The agent gets no capability the person it acts for lacks.

Enforced in code

Limits live in a tested function, not in an instruction.

Provable afterwards

Every decision recorded — allowed and denied. The denials are where an attack shows up.

Running in this tab

Try to talk it into something.

You are the agent. Replay a spent confirmation, change the amount after someone agreed to it, use a standing permission to grant yourself a bigger one.

The agent proposesget_fee_balance()

ALLOWEDvia read tool

Every verdict above is the return value of authorizeWithContext() from @britelink/agent-core, executed in this tab. The kernel has no dependencies and does no I/O, so the code guarding a payment rail is the code running here.

Your system exposes tools. It never refactors around us.

Three signed endpoints and a list of what the agent may attempt. That is the whole contract — which is how one deployment drives a school, a payment rail and a shop without any of them knowing about each other.

Your channelWhatsApp, your app, a widget, voice

MandateIdentity, authorisation, consent, audit

Your systemresolve · prepare · execute

The model never states a number

Writes are a two-phase commit. Your system computes the exact figures and returns a reference only it can recognise; the person confirms those figures and nothing else. Consent is bound to them cryptographically, so an amount or a rate that moves after agreement invalidates it.

That is the difference between an agent that is convenient and one you can put in front of a customer's balance.

What it refuses to do.

Each of these is a test in the repository, not a claim on a marketing page.

Undeclared toolsAn action absent from your manifest throws. There is no default-allow path.
Replayed consentConfirmations are single use, and spending one is atomic — two arriving together cannot both win.
Terms changed after agreementConsent is fingerprinted against the exact figures shown, including the rate on a two-sided transfer.
Permission widening itselfStanding permissions can never authorise raising a standing permission.
Anxious resendsA near-identical action inside a short window is read as the same intent, not a second one.
Asking for a credentialOutbound text that solicits a PIN, password or key is blocked before it is sent. Not a prompt rule.

Small enough to audit.

The decision engine has no dependencies, does no I/O, and never touches a key — which is why it runs unchanged on a server, at the edge, or in the browser you are reading this in. It is also short enough that whoever has to trust it can read all of it.

Zero dependencies

Enforced by CI — the build fails if the kernel ever gains one. No supply chain to audit.

Open to inspection

Source and tests are published. Every refusal above is reproducible on your own machine.

Built where the assumptions are different.

Agent platforms built elsewhere assume a website, a CRM and a ticket queue already exist. Across most of Africa that is not true — WhatsApp is the storefront and the order book, and the agent is not a widget bolted onto software a business does not have. It is the software. Which raises the stakes on it being right.

team@britelink.io Source and tests

Agents you canpoint at a ledger.

A prompt is a request.This is a decision.