Skip to main content

Core Concepts

A person grants an agent authority in a mandate. The agent asks Mandaitor to perform an operation, an execution, through a tool that a connector runs in the target system. Mandaitor decides on the record, asks for an approval where the mandate says so, performs the write, and signs a Proof-of-Mandate and a receipt. Every step goes on the audit trail.

Mandate​

A mandate is a signed record of delegated authority: a power of attorney for an AI agent. Each mandate contains:

  • Principal: who grants the authority, such as a person or a company.
  • Delegate: who receives it: for executions, a registered agent.
  • Scope: what the delegate may do, and on which records.
  • Constraints: the limits the authority is granted within.

Mandaitor signs a mandate when it is created, and checks the signature again before every write it makes under it. A mandate starts ACTIVE, or PENDING_APPROVAL when a person must approve it first, and can become SUSPENDED, REVOKED or EXPIRED.

A mandate lets an agent act only when a person stands behind it: a person's session created it, or a person approved it. A mandate that an API key created on its own never backs an execution.

Principal and Delegate​

The principal owns the authority, and the delegate receives it. Both are subjects, with a subject_id and a type: NATURAL_PERSON, LEGAL_ENTITY, AGENT or SERVICE. An agent is named by the DID it was given in the Agent Identity Registry:

Example delegate
{
"type": "AGENT",
"subject_id": "did:web:agents.mandaitor.io:agt_01HXYZ",
"display_name": "Procurement agent"
}

Scope​

The scope says what the delegate may do:

  • actions: the business actions it may perform, such as procurement.requisition.release. An execution needs the action named exactly: * and other patterns grant none.
  • resources: the records the actions apply to, such as procurement:plant:1000/requisition:*. In a pattern, * matches within one / segment, and ** matches everything below.
  • effect: ALLOW or DENY. A DENY mandate that covers a request wins.

Constraints​

Constraints bound what the scope allows. An execution reads these:

  • Validity: when the mandate starts and expires.
  • Amount cap: the most a single operation may be worth, read from the record.
  • Cumulative limits: the most the mandate's operations may add up to, and how many there may be, per hour, day, week or month.
  • Approval threshold: above it, a person must approve, the person the mandate names or else its principal.
  • MFA: every approval must be given with multi-factor authentication.

A mandate with any other constraint never backs an execution, because Mandaitor does not act past a limit it cannot evaluate. A mandate written for executions gives each key and its effect. The older POST /verify evaluates a different set: see Constraint enforcement.

Taxonomies​

A taxonomy is the vocabulary of one industry or business function: its business actions, and the resource patterns they apply to. The procurement taxonomy, for example, defines procurement.requisition.release on procurement:plant:{plant}/requisition:{purchase_requisition}. When an agent asks Mandaitor to act, each placeholder is filled from what Mandaitor read from the record, never from the agent.

A mandate is written in a taxonomy's actions, never in a vendor's API, so the same mandate governs the operation in every system Mandaitor has a tool for. See Taxonomies.

Agents​

An agent is registered in the Agent Identity Registry with a DID, and with a public key whose private half only the agent holds. It authenticates as itself, with a client assertion signed by that key, and gets a short-lived session for the execution API or the MCP server. It never holds a credential for a target system.

Tools and connectors​

A tool is one typed operation in one system, such as sap.purchase_requisition.release. Each tool maps onto one business action, declares the identifiers it takes, the facts it reads from the record and the fields it returns, and never takes a fact from the agent.

A connector is Mandaitor's connection to one system, with the credential for it. Nobody reads the credential back, and the agent never sees it. A tenant administrator enables a tool on a connector, in one environment.

Execution​

An execution is one operation an agent asked for, and what became of it. Mandaitor reads the record, decides on what it read, writes once and reads the result back. Its state says where it is: DENIED, AWAITING_APPROVAL, AUTHORIZED_NOT_EXECUTED, EXECUTING, SUCCEEDED, FAILED, or UNKNOWN when a write was sent and its outcome is not established yet. See Executions.

Approval​

An approval is a person's decision on one execution. It is bound to a digest of exactly what was decided: the record at the version read, the facts, the mandates and the tenant's execution policy. If any of those change before the write, the approval no longer counts.

Proof-of-Mandate and receipt​

The Proof-of-Mandate is Mandaitor's signed statement of the authorization a write was made on, issued when the write is sent. The receipt is its signed statement of the outcome, issued once a read-back establishes it, and it names the Proof-of-Mandate by digest. See Proof-of-Mandate.

Request-bound decision​

When your own system performs the operation, its enforcement point asks for a request-bound decision: a single-use authorization for exactly one request, which it redeems immediately before it acts. The agent never holds it. See Request-bound Decisions.

Audit trail​

Every significant event, from a mandate's creation to each execution's decision, approval, dispatch and outcome, is recorded as an AuditEvent. The events of a mandate are linked by a hash chain, and each is signed with a key held in a key management service (KMS), so a change to any event breaks the chain. A mandate's evidence pack exports its chain with the Proofs-of-Mandate and receipts on it.