Mandate knowledge base
A compact reference for the objects and decisions that make an agent purchase request governable.
Agents and identity
An agent is the software actor asking whether it may perform a purchase. In Mandate, an agent has a name, business purpose, status, budget, organization owner, and scoped credential. Identity matters because a policy is not a general company rule; it governs what one specific agent may do.
- Active
- The agent may submit requests under its current mandate.
- Paused
- Requests stop temporarily without deleting history or policy.
- Revoked
- The identity is terminally disabled and its credential should no longer authorize requests.
Spending mandates
A spending mandate is a structured, versioned statement of delegated financial authority. It can begin as natural language, but a human reviews and activates the structured rules. Changing a rule creates new governing state rather than rewriting the evidence attached to earlier decisions.
Authorization decisions
The deterministic policy engine returns exactly one initial result. It evaluates facts and rules; the language model never selects the result.
APPROVED
All hard rules and mandatory-review conditions passed.
APPROVAL_REQUIRED
No hard rule blocked the request, but policy or risk requires a person to resolve it.
DECLINED
At least one hard authorization boundary failed.
A later human approval does not rewrite the original result. It adds a resolution record showing who acted, when, and why.
Risk and human approval
Risk signals help decide whether an otherwise eligible request deserves additional scrutiny. Mandate’s basic factors include amount anomaly, new merchant, category mismatch, abnormal velocity, and geography mismatch. The score ranges from 0–100 and records the factors that contributed.
Risk may escalate an eligible request to APPROVAL_REQUIRED. It must not convert a policy decline into an approval. This preserves explicit business rules as the final hard boundary.
Scoped API keys
An agent API key identifies the requesting agent to Mandate’s authorization endpoint. It sits under the agent because its authority must be narrow: it may submit purchase facts for that agent, but it cannot edit the mandate, increase the budget, approve its own request, or act as another agent.
The key belongs to the integration—not to the payment instrument. A customer backend, MCP server, or agent runtime can send the key with an authorization request before attempting a downstream action. Keys should be shown once, stored as secrets, rotated when exposed, and revoked with the agent.
Audit evidence
An explainable decision needs more than a final status. Mandate records the request facts, mandate version, passed and failed policy checks, risk factors, initial decision, later human resolution, actor, timestamp, and linked audit event.
The current audit trail is hash-linked and tamper-evident in style; it is not represented as a certified immutable ledger. Production expansion should add independent export, retention controls, verified backups, and integrity monitoring.