Human authority for autonomous systems.

No. An agent can only spend against a mandate you create: a monthly budget, a per-purchase ceiling, permitted categories and permitted vendors. A request that falls outside any of those is either routed to a named approver or refused outright — the agent never has a spending path around the rules. You can see the three pilot mandates on the Agents screen and edit their limits on the Policies screen.

Each rule names the human who owns the exception. In the pilot, spend above an agent's per-purchase ceiling and every recurring subscription route to a named approver, who approves or refuses in the Requests screen. The approval carries the approver's name, the decision, the rationale and the timestamp, and is written to the audit trail as a distinct event. Case 002 in the guided demo walks through a live escalation.

It sits in front of it, not instead of it. The mandate encodes the delegated authority your finance policy already grants; anything beyond that delegation becomes a normal human approval with an owner and a paper trail. Requests and the audit trail export to CSV so the evidence can be filed alongside your existing procurement and month-end records.

No. The policy engine is deterministic: budget, ceiling, category and vendor are evaluated in a fixed order, and the same request always produces the same decision. A model may draft or initiate a request, but it has no influence on the outcome. That is why the three demo cases reproduce identically every time you reset them.

Prohibited categories are a hard refusal, not an escalation. In the pilot the Operations Agent is barred from fund transfers and crypto assets; that request is refused with a stated reason and cannot be approved through the interface by any user. Case 003 in the guided demo shows the refusal and the record it leaves.

Every approved purchase draws down the agent's monthly budget at settlement, and each new request is checked against the remaining balance rather than the original allowance. Small purchases that individually clear the ceiling still stop once the budget is spent. Remaining balances are shown per agent on the Control and Identity screens.

No. This pilot has no custody of any kind — no wallets, no cards, no customer funds and no live payment execution. Settlement is simulated end to end so the control model, the approval chain and the evidence can be evaluated without moving money or onboarding a payment provider.

Realistic but entirely simulated pilot data: three agents, their mandates, the policy rules and the canonical demo cases. Nothing here is production or customer-facing, and no real vendor is invoiced. If you request pilot access we collect only the contact details you submit, and use them solely to respond.

The trail is append-only in behaviour: each decision, approval and settlement is written as a separate timestamped event with its actor, and the interface offers no way to alter or delete an event once recorded. Reset restores the canonical starting state for demonstration purposes rather than editing history in place. You can export the full trail as CSV for independent review.

It demonstrates one working rail end to end. There is no live money movement, no production hardening, no vendor integrations and no SSO or enterprise access management yet. Those are exactly the questions the pilot is intended to surface — the control model is the part being validated here.