DEVELOPER PREVIEWSANDBOX / TESTNO PRODUCTION MONEY MOVEMENT

Authorize.
Execute.
Prove.

Authority infrastructure for AI agents.

Before an AI agent spends money, starts a subscription, shares protected information, delegates work or hires another agent, Quattrino determines what it is actually authorized to do — with your payment rail or ours — and can prove why afterward.

Prefer to read? How it works →

Your AI agent can act. Quattrino decides whether it should — and proves it did.

real sandbox decision · dry run · nothing executes

Standing authority

$50.00 per action

The human said

“Buy a USB-C cable. Keep it under $20. One-time purchase.”

The agent wants to

AUTHORIZED

Within effective authority. In binding mode this would be a single-use authorization.

Standing
$50.00
Task
$20.00
Delegated
none
Effective
set by: the task (compiled intent)
$20.00
SANDBOX / TESTNO PRODUCTION MONEY MOVEMENT
Run your own in the playground

The problem

AI agents can act. A prompt is not authority.

A dollar figure alone is not enough information to authorize an agent. Real authority has several dimensions, and the narrowest one wins.

money · task narrows standing

A $50 standing limit does not make “under $20” enforceable.

The task instruction is authority too. Quattrino intersects the standing policy with the task: $50 ∩ $20 = $20 effective. $14.99 is AUTHORIZED; $24.99 is DENIED — and the decision names the layer that decided.

commitment · never assumed

A cheaper subscription is not a purchase.

A $9.99/month plan is below the $20 ceiling, but “one-time purchase” prohibits recurring commitments. DENIED, commitment_prohibited. Undeclared commitment is never assumed to be one-time: NEEDS_INFORMATION.

data · minimum necessary

A shipping address is not the owner’s whole identity.

Fulfilment needs an address — released once, to that merchant only. An analytics service asking for the same field is refused. Payment secrets, credentials and identity documents are never disclosable.

The decision

Every consequential action gets one of four answers.

Deterministic, replay-resistant, and identical whether Quattrino executes or you do. The demo above returns these from the real engine.

AUTHORIZED

Within the effective authority. In binding mode a single-use authorization is issued: it expires, can be revoked and is consumed exactly once.

DENIED

Outside the effective authority, a prohibited commitment class, a blocked counterparty or a violated task constraint. Nothing is issued.

APPROVAL REQUIRED

A human must confirm — above the autonomous ceiling, an approval rule, or an owner-gated disclosure. The request waits in Approvals; silence never means yes.

NEEDS INFORMATION

The authority to decide does not exist yet. Safe work continues; exactly one precise question goes to the owner, only when the consequential step is imminent.

And every answer explains itself

GET /authorizations/{id}/explain answers who acted, on whose behalf, which layer set the effective authority, what was disclosed, what happened and whether it matched — in plain language and as hashed evidence.

Source intentInferred meaningInherited authorityTask / envelope authorityDelegated authorityEffective authorityDisclosuresOutcomeCompliance

What Quattrino governs

Money is one dimension. Authority has six — plus a human gate.

Each dimension is intersected separately: standing policy, compiled task envelope, delegated grant. The most restrictive posture is the one that binds.

Money

Per-action and aggregate ceilings, currency, conditional ceilings (“$1,200 only if RAM ≥ 32 GB”).

Commitment

One-time · recurring · subscription · auto-renewal · account · contract · warranty · trial-that-converts. Unknown is never one-time.

Data

Per-field posture: release once, redacted, ask the owner, deny — bound to purpose and recipient. Secrets never.

Counterparty

Which merchants, services or agents may be dealt with; attribute requirements (“must grant commercial rights”).

Time

Validity windows, deadlines and expiry for every authorization and every delegated grant.

Delegation

Whether an agent may hire or delegate, how deep, with what budget — conserved: children never add up to more than the parent.

Approval — the human gate. Anything above the autonomous ceiling, and any disclosure the owner reserved, waits for an explicit decision in one inbox. Approvals expire; silence never means yes.

How it works

Intent → Authority → Decision → Execute → Outcome → Proof

  1. 01

    Intent

    The human says what they want. Quattrino compiles it into a typed authority envelope — meaning may be inferred, permission never is.

    q.compile_intent("Buy a USB-C cable. Under $20. One time.")
  2. 02

    Authority

    Standing policy ∩ envelope ∩ delegated grant ∩ counterparty ∩ time. The narrowest layer wins, per dimension.

    effective = standing ∩ task ∩ delegated
  3. 03

    Decision

    One call, four answers. Deterministic, replay-resistant and explainable.

    q.authorize(amount_minor=1499, merchant="Amazon", ...)
  4. 04

    Execute

    Use your own rail, or a Quattrino adapter in the sandbox. Quattrino never needs to own the payment to govern it.

    execution_plan.execution_mode # "external" | "quattrino"
  5. 05

    Outcome

    Report what actually happened. Amount, counterparty, commitment class, data and delegation are checked against the authorized terms.

    q.record_outcome(auth_id, actual_amount_minor=1499, ...)
  6. 06

    Proof

    Plain-language explain plus hashed evidence: who, on whose behalf, which layer decided, what happened, did it match.

    q.explain(auth_id)["plain_language"]

Use your own rail

Quattrino does not need to own the rail to govern the action.

Authorization and execution are separate. Execute with your own provider and report the outcome, or use a Quattrino adapter in the sandbox. Either way the authority layer, the evidence and the compliance check are the same.

Your own provider

Authorize-only. Quattrino issues the decision and the evidence; you execute anywhere and record the outcome.

AVAILABLE IN SANDBOXThe core product

Merchant checkout (Stripe SPT)

A single-use token pays the merchant on its own Stripe account. Same authorization layer.

TEST INTEGRATIONStripe test mode

Quattrino Credits · marketplace

Agent-to-agent services, funded by sandbox Credits, held until delivery.

AVAILABLE IN SANDBOXSandbox

x402 machine payments

HTTP-native payments on testnet only. Not expanded in this phase.

TEST INTEGRATIONTestnet

MPP

Machine payments protocol adapter: card SPT on Stripe test through the official mppx sidecar; stablecoin verification is simulated (provider capability blocked).

TEST INTEGRATIONStripe test · production OFF

Not just money

Delegation is conserved. Disclosure is minimal.

Human → agent → sub-agents

A project lead holds $300.00 and hires three specialists at $175, $40 and $60. A fourth asking for $50 is refused: only $25 is left to promise. Authority is conserved at issuance — it never multiplies down the tree — and unspent grants return when a child is revoked or expires.

Figures are read from the real delegation engine in the “Delegation conserves” tab of the demo above.

Purpose-bound disclosure

Shipping a cable needs a shipping address: released once, to that merchant, for that order. The same merchant asking for a card number, or an analytics service asking for the address, is refused. Values are never returned by a dry run and never shown on this site; only the decision is.

Try the “Minimum necessary disclosure” tab above — every posture comes from the engine’s disclosure policy.

For developers

One call. Any language. Your rail or ours.

Thin SDKs over a single REST contract, plus an MCP server your agent can call directly. No policy logic lives in the client.

  • Sandbox account in under a minute — open signup, no invite
  • quickstart.py / quickstart.ts and seven runnable differentiation journeys
  • authorize · compile_intent · authority_gap · explain · outcome · disclosure_release
  • Works when Quattrino does not move the money
from quattrino import Quattrino
q = Quattrino(api_key="qtrn_sk_...")          # the agent's scoped credential

r = q.authorize(amount_minor=1499, merchant="Amazon",
                purpose="USB-C cable", task={"max_amount_minor": 2000,
                "prohibited_side_effects": ["subscription"]})
r.decision                  # AUTHORIZED
r.effective_maximum_minor   # 2000  <- standing $50 narrowed to $20

Safety & explainability

Built to fail closed and to prove it.

Fail closed

If a dimension cannot be checked, the answer is not AUTHORIZED. Ambiguity never expands authority.

Single-use, expiring, revocable

A binding authorization is consumed exactly once; changed amount, merchant, commitment or agent fails the consumption guard.

Conserved delegation

A child grant can never exceed what the parent still holds; unspent authority returns on revoke or expiry.

Evidence, not logs

Material terms, pipeline, outcome and mismatch flags are hashed and explainable in plain language.

Tenant isolation & idempotency

Every record is organization-scoped; every binding call carries an idempotency key, so a retry can never authorize twice.

Immutable envelopes

Every envelope version is append-only with provenance. Agents may only narrow; only the owner widens.

Security & trust

What is real today

  • authorize · explain · outcome · revokeAVAILABLE IN SANDBOX
  • Intent compilation · authority envelopes · latest safe questionAVAILABLE IN SANDBOX
  • Conserved delegation (human → agent → sub-agent)AVAILABLE IN SANDBOX
  • Purpose-bound disclosure decisionsAVAILABLE IN SANDBOX
  • Merchant checkout via Stripe Shared Payment TokenTEST INTEGRATION
  • Credits · agent-to-agent marketplaceAVAILABLE IN SANDBOX
  • x402 machine payments (testnet)TEST INTEGRATION
  • MPP adapter (card SPT on Stripe test · stablecoins simulated)TEST INTEGRATION
  • Authorization pricingPROPOSED
  • Production money movement · Stripe live · mainnetFUTURE

Nothing simulated is presented as production. Live settlement is gated off platform-wide until providers, reviews and pricing are approved.

Straight answers

Questions developers ask first

Sandbox

Try the playground — real decisions, no real money.

Run authorize, compile an intent, inspect the effective authority and read the explanation. Nothing executes and nothing is billed.

Open the playground

Early access

Create a sandbox account. Join early access.

Open signup, no invite. Inside the app you can ask to be told when production onboarding opens and say what you are building. Developer preview: sandbox only, pricing not activated.

Start building