Skip to main content

What is Mandaitor?

Mandaitor carries out an AI agent's business operations, within the authority a person gave the agent. The agent asks for one operation, such as releasing a purchase requisition. Mandaitor reads the record from the target system and decides on what it read, against the mandates that name the agent. Where a mandate says so, it asks a person to approve. It then performs the write with a credential the agent never holds, reads the result back, and signs a receipt of the outcome.

The problem​

An agent that holds an API key for a business system can do whatever the key allows. Checking with an authorization service before it acts does not change that: the agent still holds the key. It can act without asking, act on another record than the one it asked about, or state a smaller amount than the record's.

Mandaitor closes that gap by performing the operation itself. The agent never holds the target system's credential, so the only way it can act is to ask. And Mandaitor decides on the record as the target system holds it, never on what the agent says about it.

How it works​

  1. Mandates. A person grants an agent a business action, such as procurement.requisition.release, on named records, within limits: an amount cap, an approval threshold, totals and counts per hour, day, week or month, and an expiry. The action comes from an industry taxonomy, so a mandate says what may be done, never which vendor's system does it. One mandate governs the same operation in every system Mandaitor has a tool for.
  2. Tools and connectors. A tool is one typed operation in one system, such as sap.purchase_requisition.release, and maps onto one business action. A connector holds Mandaitor's own credential for a system. A tenant administrator enables a tool on a connector.
  3. Executions. The agent sends a request naming the tool and the record, through the execution API or as a tool call to Mandaitor's MCP server. Mandaitor reads the record and decides on its facts. It writes once, and reads the result back.
  4. Approvals. Above a mandate's threshold, the person the mandate names approves the request they are shown, bound to a digest of exactly that request. If the record changes before the write, the approval no longer counts.
  5. Proof and receipt. When Mandaitor sends the write, it signs a Proof-of-Mandate: the authorization the write was made on. When a read-back establishes the outcome, it signs a receipt of what the write did, which names that proof. Both go on a hash-chained audit trail.

When your own system must perform the operation, its enforcement point asks for a request-bound decision instead: a single-use authorization for exactly that request, which the agent never holds.

What it is not​

  • Not a replacement for the target system's access control. The target system still checks the credential Mandaitor presents, so give a connector only the rights its tools need.
  • Not a model guardrail. Mandaitor does not read prompts or judge a model's reasoning. It decides on the operation and the record.
  • Not an open-ended gateway. Each tool is one reviewed operation, with the facts it reads and the fields it returns declared. An operation without a tool cannot be asked for.

Where it stands​

The execution API, the MCP server and request-bound decisions are in Preview, and executions run only against Mandaitor's hosted SAP and ServiceNow sandboxes. Beta Limitations lists what is available today and at what stability. The older POST /verify answers whether an agent may act and leaves the acting to the agent; Verifying Actions describes it.