mcpField
D
drift — mandate enforcement for AI agents

drift — mandate enforcement for AI agents

Remote
drift.rta.latSecurity0Updated today

About drift — mandate enforcement for AI agents

drift is an MCP server for checking AI-agent actions against signed mandates before execution. It applies six fixed-order rules to spending and intent limits; it decides whether an action is allowed but does not execute it or verify signatures.

Key features

  1. 01Checks amount and currency limits
  2. 02Checks payee and audience
  3. 03Enforces validity windows
  4. 04Restricts actions by intent
  5. 05Checks action sequences with reports
  6. 06Explains rules in evaluation order

Use cases

  1. 01Check a payment before an agent submits it
  2. 02Prevent a recipient or currency substitution
  3. 03Review a sequence of actions against a mandate

MCP support

drift exposes `drift_check`, `drift_session`, and `drift_explain` to MCP clients. The tools check individual actions or sequences against a mandate, and explain the rules; they do not execute actions or verify mandate signatures.

Configuration

Remote servers need no local install. Pick your client, then copy the config or install in one click.

Endpointhttps://drift.rta.lat/mcp
Copy install command
Claude CodeTerminal
Cursor.cursor/mcp.json
VS Code.vscode/mcp.json
Claude Desktopclaude_desktop_config.json
Windsurf~/.codeium/windsurf/mcp_config.json

Run commands in a terminal; paste JSON into the client’s MCP config and restart. Servers that need sign-in will prompt on first connect.

Tools

3
ParameterTypeRequiredDescription
actionobjectYesThe action being proposed.
action.atintegerYesWhen the action would happen, unix seconds.
action.intentstringYesWhat the agent says it is doing. Untrusted.
action.audiencestringYesAudience the payment would go to.
action.currencystringYesISO-4217 code of this payment.
action.payee_idstringYesPayee the agent is about to use.
action.amount_minorintegerYesAmount in minor units, same scale as max_amount_minor.
mandateobjectYesThe signed authority being enforced. Treat as read-only input.
mandate.audiencestringYesMerchant audience URI bound into the mandate.
mandate.currencystringYesISO-4217 code, e.g. USD.
mandate.payee_idstringYesExact payee the mandate names.
mandate.valid_fromintegerYesInclusive start, unix seconds.
mandate.valid_untilintegerYesInclusive end, unix seconds.
mandate.allowed_intentsarrayYesPermitted intents. Empty means any intent is allowed.
mandate.max_amount_minorintegerYesSpending cap in minor units, e.g. 10000 = 100.00 USD. Integers only.

Details

From the project README

drift

M8ven Score Listed on mcpservers.org

Continuous mandate enforcement for AI agents. Every action is checked against the signed mandate before it happens, not once at signing.

pip install drift          # or: pip install -e .
python3 -m drift.http_server --http 8080

The gap

An agent is granted a mandate: who to pay, how much, in which currency, until when. AP2 verifies that mandate once, at signature time. After that the agent acts alone, and nothing holds it inside its authority.

Measured proof that this matters, from the AP2 Python SDK itself:

verify_chain documents:
  "enforcing expected_aud / expected_nonce on the terminal hop when provided"

but kb_sd_jwt.verify calls verify_expected_claims only when typ in TYP_TERMINAL,
and a kb+sd-jwt+kb token — which the SDK itself produces whenever the payload
carries a cnf — falls into TYP_INTERMEDIATE:

  hop type      : kb+sd-jwt+kb
  aud in token  : https://attacker.example/ap2
  expected_aud  : https://honest-merchant.example/ap2
  ACCEPTED a token with the wrong audience.

The protocol an agent trusts with its spending authority does not check that the authority was not substituted. drift checks it.

What it checks

#rulecatches
1amountover the limit — the most common form of drift
2payeewrong recipient
3audiencepayment redirected to someone else
4currencycurrency substituted
5windowoutside the validity period
6intentintent outside the allowlist

Default is DENY. Rules run in fixed order, so a refusal names the most important reason rather than an incidental one.

MCP tools

toolpurpose
drift_checkcheck one action against a mandate
drift_sessioncheck a sequence, get a report with a chain fingerprint
drift_explainshow the rules in the order they apply

No SSE, no stateful sessions, no HTTP framework. Standard library only.

Example

from drift import Mandate, Drift, Action

m = Mandate(
    payee_id="shop", audience="https://merchant.example/ap2",
    max_amount_minor=10_000, currency="USD",
    valid_from=1_700_000_000, valid_until=1_700_086_400,
    allowed_intents=("buy",),
)
d = Drift(m)
verdict, rule = d.submit(Action(
    intent="buy", payee_id="shop", audience="https://merchant.example/ap2",
    amount_minor=99_999, currency="USD", at=1_700_000_060,
))
print(verdict, rule)   # DENY amount

Limits, stated plainly

  • Does not verify mandate signatures. That is AP2's job. drift runs after signature verification, at the level of decisions.
  • Does not execute. It decides; the caller acts.
  • Does not keep state. A session is an argument. No state means no attack surface and no divergence under replication.
  • Does not tell truth from intent. intent arrives from the agent and is untrusted input. drift bounds the damage; it does not certify the intent.

If an agent controls both intent and amount, it can lie in both. Closing that gap is attest's job: attest proves afterwards, drift bounds beforehand. They are complements.

Use it from your agent

{
  "mcpServers": {
    "drift": { "url": "https://drift.rta.lat/mcp" }
  }
}

That block is how our own agents call this server. Tools: drift_check (one action), drift_session (a sequence), drift_explain (the six rules and why each exists). 100 free checks per day, then $0.005 per call over x402.

Licence

Apache-2.0.

Comments

Markdown supported

New to MCP?

From what the protocol is to installing your first server, these answers cover most first questions.

An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.