Glossary · English

The vocabulary of agent authority

43 terms, each defined in a form you can quote. Reason codes (MD-101 to MD-502) are contract and appear verbatim — they are what your integration compares strings against. Deutsche Fassung

Agent mandate: An agent mandate is a cryptographically signed, revocable authorisation by which a person or organisation permits an AI agent to carry out defined actions on their behalf — with scope, amount limits, validity period, and escalation rules. It is machine-checkable and legally readable at the same time.
Mandate (OMP): In the Open Mandate Protocol, a mandate is a verifiable credential of type omp/mandate/1: it binds a principal (identity root) to an agent (key), defines permitted actions and limits, and points to a live status endpoint for revocation.
Principal: The principal is the person or organisation granting the mandate. Their identity is the root of the delegation chain — anchored in the EUDI wallet, the Swiss E-ID, or an organisational identity tied to the commercial register — and makes every agent action attributable to a real legal person.
Verifier (relying party): The verifier is the other side of an agent action — shop, bank, SaaS provider, or public authority — that checks a presented mandate before executing. With the signed verification receipt it can demonstrate its diligence at any time and is protected against liability claims.
Scope: A mandate's scope lists the permitted actions from the OMP taxonomy (for example subscription.cancel, purchase.goods). Wildcards are allowed only at the lowest level, never globally — so an agent always receives an explicit, finite list of powers rather than a general power of attorney.
Constraints: Constraints bound a mandate quantitatively: amount limit per action and per period, frequency, permitted or blocked counterparties, time windows. Monthly limits are reserved atomically during verification so that parallel agent requests cannot jointly exceed a limit.
Escalation (step-up): An escalation interrupts an agent action above the defined threshold and obtains confirmation from the principal. Without a decision inside the timeout (600 seconds by default) the request counts as denied; approvals are consumable exactly once.
Kill switch: The kill switch is the principal's final revocation of a mandate. It is atomic: status change, evidence entry, and webhook commit together. It applies from the next verification onwards, with no cache — and remains available even during payment arrears: money never deletes mandates.
Revocation: Revocation ends a mandate irreversibly (status revoked). Every further verification is denied with code MD-201. Legally it corresponds to the revocability of a power of attorney at any time (Swiss CO Art. 34, German BGB §168); technically the status is read fresh on every verification, so revocation takes effect without a grace period.
State machine: The state machine defines the permitted lifecycle transitions of a mandate: draft → active → suspended/revoked/expired/consumed. It is enforced twice — as a database trigger and in application logic — so that impermissible transitions are technically impossible, not merely forbidden.
Suspension: Suspension puts a mandate on hold reversibly (status suspended, Verify answers MD-202). It is triggered by the principal, by administrators, or by automatic anomaly signals from governance systems. Unlike revocation, a suspended mandate can be reactivated.
Verification receipt: The verification receipt is the signed record of every mandate check: decision, primary code, action, timestamp, signature. It proves to regulators, courts, and insurers that the relying party checked before executing — the basis of its exculpation.
Evidence vault: The evidence vault is the two-sided evidence chain: issuance, verification, escalation, consumption, and revocation are stored append-only and hash-chained; root hashes are anchored with qualified eIDAS timestamps. Later changes are technically detectable.
Hash chain (Merkle log): In a hash chain, every entry references the hash of its predecessor. If an entry is altered afterwards, none of the following hashes match — tampering becomes mathematically visible. Mandact revalidates the chain in full on every retrieval.
Qualified timestamp: A qualified electronic timestamp under eIDAS establishes, with a statutory presumption, that data existed at a given point in time. Mandact uses it to anchor the root of the evidence chain daily — the step from “log file” to evidence with legal weight.
Proof of possession (PoP): Proof of possession demonstrates that the presenting agent actually holds the mandate's private key — via a fresh, nonce-bound signature no older than 60 seconds. Stolen or copied presentations without the key therefore fail with MD-104.
Presentation: The presentation is what an agent shows the relying party: the mandate (with selective disclosure of only the necessary attributes) plus fresh proof of possession of its key. It is generated in the agent's wallet — the key never leaves it.
Selective disclosure: Selective disclosure (SD-JWT) lets the agent reveal only those mandate attributes needed for the specific action — the scope, say, but not every limit. Data minimisation becomes a property of the format rather than a policy.
SD-JWT VC: SD-JWT VC is the credential format of the eIDAS 2.0 world: a signed JWT with selectively disclosable claims. Mandact mandates are issued on activation as SD-JWT VCs of type omp/mandate/1 — with holder binding (cnf) and selectively disclosable limits; presentation via OID4VP follows in sprint S4.
Verifiable credential (W3C VC): A verifiable credential is a cryptographically signed, machine-checkable attestation following the W3C standard. Issuer, holder, and verifier are separate roles — precisely the structure a mandate needs: the principal issues, the agent holds, the relying party checks.
OID4VC (OID4VCI / OID4VP): OID4VC are the OpenID protocols for issuing (OID4VCI) and presenting (OID4VP) verifiable credentials. They are anchored in the eIDAS 2.0 Architecture Reference Framework; Mandact uses them so that mandates work with any EUDI-conformant wallet.
DID (decentralised identifier): A DID is a cryptographically verifiable identifier that works without a central registration authority. Mandact uses DIDs for agent instances and provider attestations (did:web) — every agent is thereby uniquely addressable and checkable.
Agent attestation: Attestation is the agent provider's confirmation (via did:web) that an agent instance originates from and is operated by them. Relying parties may reject unattested agents by policy (MD-502) — a market mechanism for trustworthy agents.
Acceptance policy: The acceptance policy is a relying party's own set of rules in addition to the mandate: attestation requirement, its own amount ceilings, minimum verification level. Violations return code MD-501 — the relying party always keeps the last word.
Identity anchor: The identity anchor connects a mandate to a real legal person. For organisations this happens through the UID and commercial register link; for individuals a state identity such as the EUDI wallet or the Swiss E-ID is foreseen once a provider is connected. It answers the first question of any agent transaction: on whose behalf?
EUDI wallet: The European Digital Identity Wallet is the state-backed digital identity every EU member state must offer its citizens. For mandates it is the identity root rolled out by law — Mandact consumes it rather than issuing identity itself.
Swiss E-ID: The Swiss E-ID is Switzerland's state electronic identity (E-ID Act, popular vote 2025). It serves Mandact as the Swiss identity anchor for mandates — equivalent to the EUDI wallet in the EU and decisive for banking and public-sector use.
eIDAS 2.0: eIDAS 2.0 is the EU regulation on digital identity and trust services. It mandates the EUDI wallet and governs qualified timestamps, seals, and signatures — providing the legal infrastructure on which Mandact's identity and evidence layers rest.
Delegation chain: The delegation chain documents without gaps who permitted what to whom: person → mandate → agent → (optionally sub-agent) → action. With sub-delegation, structural attenuation applies: the sub-scope is always strictly smaller than the originating scope — powers can only shrink.
Sub-delegation: Sub-delegation lets an agent pass parts of its mandate to sub-agents — disabled by default (delegation_depth 0). When enabled, the protocol enforces attenuation: each level may do less, never more. This prevents privilege escalation in agent chains.
Atomic reservation: For monthly limits, the Verify API reserves the requested amount atomically before answering allow. Parallel requests from several agents therefore cannot jointly exceed a limit; unused reservations expire automatically after 15 minutes.
Consumption: Consumption reports the completion of an action: the reservation is redeemed, usage is booked against the limit, single-use mandates are consumed, and the action hash enters the evidence chain. It closes the loop between permission and execution.
Single-use mandate: A single-use mandate (single_use) expires automatically after its first successful use (status consumed). It suits one-off instructions — a purchase, a cancellation, a booking — where a standing authority would be unnecessary.
OMP action taxonomy: The action taxonomy is the controlled catalogue of mandatable actions in the namespace domain.action.variant — from subscription.cancel to gov.file_request. Every action carries a risk level (1–3) that drives default escalation thresholds and verifier policies. contract.sign deliberately does not exist.
Risk level (1–3): Every action in the OMP taxonomy carries a risk level: 1 (reversible, no outflow of funds), 2 (monetary or data effect within limits), 3 (immediate payment or high-risk effect). Level 3 requires an escalation threshold in practice.
MD-401 (escalation_required): MD-401 is the Verify API's escalation answer: the action is above the mandate's threshold and needs the principal's confirmation. The response carries the escalation ID; after confirmation the relying party verifies again using that token.
MD-501 (verifier_policy_reject): MD-501 means the mandate itself would be valid, but the relying party's own acceptance policy rejects it — because of an amount ceiling, for instance. The code separates cleanly between “mandate insufficient” and “house rule violated”.
MD-104 (stale_pop): MD-104 rejects a presentation whose proof of possession is older than 60 seconds. The freshness rule prevents intercepted presentations from being replayed later — every presentation needs a current signature from the agent's key.
Primary code: Every Verify API denial carries exactly one primary code (MD-101 through MD-502): the first failed check in the deterministic check order. That makes decisions machine-readable, reproducible, and explainable in a dispute — no black-box denials.
Status endpoint: Every mandate points to a live status endpoint (Cache-Control: no-store). Verifiers must check status online — relying offline on a stored status violates the protocol. This is what makes a revocation take effect immediately rather than at token expiry.
Governance sync: Governance sync connects mandates with agent monitoring: anomaly signals (cost spikes, policy violations) can suspend mandates automatically and reversibly; conversely, verification metrics flow into governance dashboards. Observing and authorising become one system.
Four-eyes signature: Organisational mandates above the signing threshold require signatures from two different authorised signatories. The rule is technically enforced — the same person cannot sign twice, and activation is blocked without sufficient signatures.
AP2 (Agent Payments Protocol): AP2 is Google's open protocol for agent payments with signed intent, cart, and payment mandates as W3C verifiable credentials. Mandact wraps AP2 payment mandates as a subtype (payment.*) and extends the model to all non-payment actions plus the European evidence layer.

The German site carries additional material — knowledge articles, jurisdiction pages, and the action catalogue — that has not been translated. Those pages are written for German search intent; mirroring them mechanically would add thin duplicates rather than useful English content. English overview · API reference