Security

mnd8t decides whether an action is authorised and proves what it decided. It never holds your funds or your keys — but because a wrong decision has financial consequences, it is built to production security expectations.

The execution boundary

The most important security property is architectural: mnd8t cannot move your money, because it has no way to.

• No execution path exists in the service. The API and background worker contain no transaction-submission code at all. This is enforced by an automated test that fails if either ever imports provider execution code.
• Key separation. mnd8t holds one Ed25519 key, used to sign evidence receipts and authorisation artifacts. It cannot sign a provider transaction. Your wallet or provider credentials live only in your own executor's environment and are never transmitted to mnd8t.
• Verification needs no secret. Your executor verifies artifacts and receipts against the published public key. Nothing private is shared in either direction.
• Live-money execution is disabled and the service refuses to start with it enabled.

If your executor is compromised

An attacker who controls your executor controls your payment credentials, and mnd8t cannot stop them spending. That is the trust assumption this architecture rests on, so it is stated first. Artifact verification is code that runs inside your executor: an attacker who owns that process can skip it and submit whatever transaction the credentials allow. Nothing described here prevents that, and no verification step should be read as preventing it.

What mnd8t still gives you in that scenario is narrower, and worth being precise about:

• Authority is unchanged. mnd8t will not issue an artifact for anything outside the mandate, so the attacker gains no new authorisation — the signing key that mints artifacts is not on the executor's host. Budget state caps what mnd8t will ever authorise, and revoking the mandate invalidates every outstanding artifact immediately.
• Artifacts cannot be edited or replayed. They are bound by signature to the account, action type, asset, amount, destination, counterparty and expiry, and each is claimable once. An attacker cannot turn a legitimate artifact into a larger or differently addressed one, or reuse it.
• The divergence is evidenced. mnd8t's receipt chain records what was authorised; an unauthorised payment leaves a transaction with no matching artifact, and an unreconciled claim holds budget until somebody accounts for it. That makes the compromise detectable after the fact — detection, not prevention.

Getting enforcement rather than evidence requires a separate, protected boundary. The constraint binds an attacker only where the thing that signs or submits the payment is not the thing the attacker controls, and that component refuses to act without a valid mnd8t artifact. In practice that means a policy-controlled signer with credential isolation and hardware-bound approval (AC2 is one such transport — see wallet adapters), an HSM or KMS policy that enforces the same check, or a regulated provider that will not release funds without the artifact. mnd8t is the authority decision in each of those designs; it is not itself the enforcement point.

Whatever the topology, your executor should pin the mnd8t public key and verify every artifact before claiming it. That protects you against a compromised or impersonated mnd8t — a different threat, and one verification does close.

Authorisation artifacts

Artifacts are the one-time tokens that authorise execution, so they are built against replay:

• Single claim. The ISSUED → CLAIMED transition is atomic; concurrent claims produce exactly one winner. Verified by test.
• Short-lived, with an expiry you configure per mandate.
• Nonce-bearing and hash-committed, so a replayed or edited artifact is detectable.
• Revoked on mandate revocation, immediately and without a grace period.
• Signed over every material field — changing any of them invalidates the signature.

Evidence integrity

• Receipts are append-only and hash-chained. Any mutation breaks the Ed25519 signature; tampering is covered by an automated test.
• Every receipt records what mnd8t actually did, generated from the runtime path rather than asserted — including that no transaction was executed by the service.
• Confirmations record who reported the outcome and how it was verified, so a customer-asserted result is distinguishable from an independently checked one.

Money-state integrity

• Budget changes happen inside a single transaction with row-level locks. Two concurrent requests cannot jointly exceed a limit; the overspend scenario is an automated test.
• Idempotency keys prevent duplicate decisions and double reservations. Reusing a key with a different payload is rejected.

Authentication and secrets

• Sign-in uses Google or GitHub OAuth with CSRF-protected state and a verified-email requirement.
• API keys are 192-bit random, shown once, stored only as SHA-256 hashes, and revocable. Sandbox and live-test environments are fully separated.
• API keys are scoped, and default to a runtime set that cannot alter mandates, counterparties, agents or other keys. This is deliberate: a credential held by the agent being constrained must not be able to rewrite the constraint. A key cannot mint a key wider than itself. Keys issued before scoping existed carry every scope and are flagged for rotation.
• Approval links carry 256-bit single-use tokens, stored hashed, that expire and cannot be reused.
• Session cookies are signed, HttpOnly, SameSite=Lax and Secure in production.
• Signing keys load from a secret manager or the environment; nothing key-shaped is ever committed.

Tenancy

Every tenant-owned record carries an organisation id and every query filters on it server-side. A resource belonging to another organisation returns 404, never 403 — mnd8t will not confirm that someone else's data exists. Cross-tenant isolation is covered by automated tests. Roles are enforced per route: administrators manage, approvers act on approvals, viewers read.

Request hardening

Strict schema validation with allowlisted fields on every route; unknown policy fields are rejected outright. Request bodies are size-limited, and rate limits apply globally with tighter limits on authentication, decision and approval endpoints. Authorisation and cookie headers are redacted from logs; API keys are never logged.

Webhooks

Payloads are signed with HMAC-SHA256 over a timestamped payload and a five-minute replay window. Deduplicate on the event id — delivery is at-least-once by design.

Audit trail

Structured audit records cover sign-in, API-key creation and revocation, mandate publication and revocation, approvals, and changes to agents and counterparties.

Before live money

Enabling real-money execution is gated on a documented review covering regulatory perimeter in each operating jurisdiction, provider contracts, data protection, an updated threat model, penetration testing, an incident response plan, and written agreement on who owns execution and the associated liability. Until that review is complete and signed off, the capability stays disabled in code.

Reporting a vulnerability

This is pre-production software. Please report suspected vulnerabilities privately to the mnd8t team rather than disclosing them publicly, and allow us reasonable time to remediate before any disclosure.