Governance Playbooks
Playbooks are copy-paste recipes for governing a real AI agent. Where the Academy explains why delegated authority matters, a playbook gives you an opinionated starting point for one operation, which you can run against a hosted sandbox in an afternoon and adapt to your own systems.
Each playbook follows the same shape:
- The scenario: who the agent is and what it should be able to do.
- The risk: what goes wrong when the agent holds the target system's credential itself.
- The mandate design: the business action, the records, and the limits.
- Set it up: the sandbox, the tool, the agent and its mandate.
- Let the agent ask: the request, and what the agent does with each answer.
- What must be refused: requests to run, each with the outcome it must have.
- Evidence and review: what to keep, and who reviews it.
The playbooks
| Playbook | Pattern | Best for |
|---|---|---|
| Requisition release agent | Mandaitor writes within limits; a person approves above a threshold | Procurement and finance agents that change records in an ERP |
| One mandate, two systems | One mandate governs the same operation in SAP and in ServiceNow | Agents that work across several vendors' systems |
| Your system acts | A single-use authorization for one request, redeemed before your own system writes | Integrators whose enforcement point must perform the operation itself |
The playbooks use the execution API, the MCP server and request-bound decisions, which are in Preview. Their business operation, procurement.requisition.release, comes from the procurement taxonomy, which is not loaded yet. Until it is, its tools cannot be enabled, and decisions on it are denied with UNKNOWN_ACTION. See Beta Limitations.
Before you start
You need a tenant, and a tenant administrator's account on the dashboard: creating a sandbox, registering an agent and enabling a tool are a person's actions, and an API key cannot take them. Getting Started walks through the setup once, in detail. In the examples, adminClient stands for a tenant administrator's session, and mcp for an MCP client connected as the agent.
The plants, amounts and approvers below fit the hosted sandboxes' seeded records. Replace them with your own sites, limits and people. The shape is the part to keep: one business action, the records of named sites, a cap, and a threshold above which a person decides.
The rules every playbook follows
Grant the least authority that still lets the agent do its job, and let Mandaitor refuse everything else. A good mandate is boring: one business action, the records of the sites the agent works for, a cap no approval overrides, and a threshold above which a person decides. If you can describe the mandate in one sentence, you have probably scoped it well.
The agent never holds the target system's credential. Mandaitor's connector does, so the agent can only ask. The mandate is then not advice the agent may ignore: it is the only way in.