Mandates

The same object you see in the console is the one every action is checked against. An agent with no mandate for an action type gets deny with no_mandate: there is no default allowance.

#The object

{
  "id": "mdt_91c3e0b2",
  "agentId": "agt_4f2c91a7",
  "kind": "payment",
  "title": "Weekly groceries",
  "status": "active",
  "expiresAt": null,
  "createdBy": "you@example.com",
  "signature": "base64url Ed25519 over the canonical mandate",
  "currency": "GBP",
  "perTransaction": 15000,
  "perPeriod": 60000,
  "period": "week",
  "merchants": { "allow": ["market.example", "grocer.example"], "block": [] },
  "categories": ["groceries"],
  "approveAbove": 8000,
  "newMerchant": "approve"
}

status is active, revoked or expired. Amounts are minor units of currency. A change is a new signature and a ledger record naming who made it.

#Payment mandates

Breaching perTransaction or perPeriod is a deny, not a question. To be asked instead, set approveAbove below the limit and keep the limit as the ceiling nobody can talk past.

The workspace also keeps one allowance and one never-pay list across every mandate, under Settings: a payee on the never-pay list is refused whichever mandate an agent cites.

#Data mandates and the vault

The vault holds a person’s fields (name, address, email, passport number) sealed at rest. An agent never holds them: it asks for a release, and on allow the values come back once, in released, for that recipient only.

A release outside recipients is recipient_not_allowed, a deny. Restricted fields (passport, national_id, bank_account, card, health) always need a person unless the mandate names that field and that recipient. A mandate for passport to * does not count.

#Action mandates

Three things hold under every action rule, whatever it says and however trusted the agent:

• A destructive command asks a person: rm, git push --force, git reset --hard, git clean, piping a download into a shell (curl ... | sh), writing over a file outside the project (~/.bashrc, ~/.ssh, /etc, .git/hooks), dropping a database table, publishing a package, and the like (destructive_command).
• A command that cannot be read with confidence asks a person: one too long to be sent whole, one spelt in escape codes or built from a variable, or one carrying invisible characters (unverifiable_command).
• A secrets file (.env, keys, ~/.aws, ~/.ssh) or the environment leaving the machine is refused (secrets_leaving).

Every site a command names is checked against domains, not only the first, and a command that uses the network without naming where (git push origin, ssh host) asks a person under a rule that names domains (unnamed_destination).

#Rules add up

An action needs to fit only one of an agent’s mandates, so the broadest one sets the limit. Two things keep a broad mandate from quietly undoing a narrow one:

• A payment to a merchant that a mandate allow-lists is judged under that mandate, and an action a mandate names exactly (tool.call) is judged ahead of a wildcard (tool.*).
• Creating a mandate that allows anywhere (an action mandate with no domains, or a payment mandate with no merchant list that allows new merchants) beside a narrower one for the same agent is refused with 409 confirm_broaden and a reason such as “This rule allows more than an existing rule for this agent: tool calls to any domain (Coding agent allows only github.com, registry.npmjs.org)”. Send it again with confirmBroaden: true to save it; the answer then carries the same sentence as warning, and the ledger record says which mandates it widens.

#A rule for your own agent

Nobody widens the authority of an agent that acts for them on their own say-so. In a workspace with another owner, a mandate you write for an agent that acts for you, and that gives it anything its current mandates do not (a higher limit per payment or per period, a new kind of authority or action, a merchant, recipient, field or domain it cannot reach now, or no approval line where it has one), is not saved. The answer is 403 second_owner_required:

{
  "error": {
    "type": "second_owner_required",
    "message": "This agent acts for you, and this rule gives it more than it has now (up to £50,000 a payment, more than the £150 it has now), so another owner of this workspace confirms it. It has been sent to them as a proposal.",
    "proposalId": "prp_6f1c2a9e",
    "why": ["up to £50,000 a payment, more than the £150 it has now"]
  }
}

The proposal waits for another owner for seven days: GET /api/w/$IMMISCIBLE_WORKSPACE/proposals lists them, and POST .../proposals/:pid/confirm saves the mandate exactly as it was asked for, with both names on the record; .../dismiss drops it. Whoever proposed it cannot confirm it. Raising the workspace’s burst lines (agentVelocity in the settings) works the same way.

In the same workspace, the person an agent acts for never approves its payments either: someone else does, whatever the mandate’s approval line.

#What a mandate cannot do

A mandate grants authority. It cannot remove the floors under it.

• It cannot switch off the Rule of Two: untrusted content driving a payment or data release with an external effect needs a person, however generous the mandate.
• It cannot permit a lookalike domain. arnazon.com is denied even if someone allow-listed it.
• It cannot outlive the kill switch. A frozen agent is denied everything.
• It cannot lift the agent above its tier. An intern asks about everything that matters whatever its mandates say.

#Templates

The console offers templates (groceries, subscriptions and bills, travel, data sharing). Each is a starting point; every field is editable before saving. A service token registering agents as code may only attach mandates from templates: a machine never writes a custom spec.

#Revoking and expiry

Revocation is immediate: the next request under the mandate is no_mandate. A mandate with expiresAt stops on its own at that moment. Neither cancels an action already allowed and settled; they stop the next one.

#API