The operating manual for agent authorization.

FLINT evaluates agent transaction requests submitted to its verification surfaces before settlement and records the result as signed evidence. Each request can draw on Principal Identity, Agent Identity, Wallet Provenance, Authorization Scope, Environment Identity, and Cross-Merchant Reputation.

FLINT is an authority-verification and evidence layer. It is not a wallet, payment rail, custody provider, universal bot detector, or guarantee that every upstream claim is true.

Use the live demo to submit an agent payment request, watch the KYA layers evaluate the transaction, and export the signed verification record.

KYA means Know Your Agent: verifying that a non-human actor is known, authorized, and in scope before it can move money.

A FLINT Agent Passport binds an agent to a controller, wallet, and mandate. It is the portable identity and authorization artifact for non-human actors.

The agent passport is the foundation of the Cross-Domain Agent Passport™ (CDAP), the neutral credential architecture for carrying platform attestations across trust domains.

Every verified request resolves to exactly 1 of 4 verdicts. STEP-UP and BLOCK are not the same finding: STEP-UP means FLINT does not yet have enough verifiable evidence to decide, and it comes with a remediation menu the agent can act on. BLOCK means affirmative risk or fraud signals were found, such as a sanctions or blocklist match, tampering, a revoked or frozen passport, or a mandate violation.

A cold-start agent, 1 that FLINT has not seen before, with no passport, no declared authorization scope, and no principal attestation, receives STEP-UP rather than BLOCK. STEP-UP is not a rejection: the response carries a machine-readable menu of cures the agent can complete on its own, and completed cures attach to the agent and carry forward automatically to future verifications. The 3 cures FLINT offers a cold-start agent are:

Reputation accrues to the passport-agent pairing for the life of the pairing, so a cure completed once keeps paying off on every later verification. Headless or server-side callers are not treated as suspicious by default; environment signals only weigh against a request when a browser context was claimed and the runtime does not match it.

BLOCK is reserved for something categorically different from a cold start: affirmative risk or fraud signals, such as a sanctions or blocklist match, tampering, a revoked or frozen passport, or a mandate violation. An agent with no history and no red flags gets STEP-UP, not BLOCK.

Example STEP-UP response shape

{
  "verdict": "step_up",
  "score": 60,
  "advisory": "This agent has not yet established a verifiable identity or authorization for this request. Complete any of the listed cures to continue; completed cures attach to this agent and carry forward automatically.",
  "cures": [
    { "type": "mint_passport" },
    { "type": "declare_authorization_scope" },
    { "type": "attach_principal_attestation" }
  ]
}

A verification record is the signed artifact showing that FLINT evaluated an agent transaction request. It preserves what FLINT checked, observed, and decided at verification time, together with labeled timestamps and attribution.

The signature proves record authenticity and integrity. It does not independently prove that every upstream representation was factually true, that a downstream payment settled, or that a counterparty will accept the record as dispositive evidence.

passport_id is additive: set to the Agent Passport id when 1 was present in the request context at verify time (free verify, x402 metered verify, or x401), and an honest null when the request was anonymous or the supplied id did not validate. It is never guessed or inferred from any other field on the request.

{
  "record_version": "1.2",
  "record_type": "agent_transaction_verification",
  "issuer": "flint",
  "framework": "KYA",
  "passport_id": "kya_01J9EXAMPLE0000000000000",
  "transaction": {
    "timing_mode": "authorization",
    "chain": "eip155:8453",
    "token": {
      "symbol": "USDC",
      "issuer": "circle"
    },
    "amount_display": "847.00",
    "direction": "credit_to_merchant"
  },
  "agent_claim": {
    "agent_id": "agt_skyline_88af3c12",
    "runtime_hint": "coinbase_agent_kit",
    "wallet_type": "smart_account_erc4337"
  },
  "authorization": {
    "authority_bound": true,
    "authority_evidence_basis": "purchase_authorization",
    "purchase_authorization_id": "kya_pa_01J9EXAMPLE"
  },
  "verdict": {
    "decision": "allow",
    "confidence": 0.2,
    "model_version": "flint-verifier-v1.0.0-sandbox"
  }
}

The decision model converts verification signals into a bounded trust score and a four-state verdict. The score starts at a neutral 50, applies positive and negative signals, clamps to 0-100, and maps to ALLOW, STEP-UP, REVIEW, or BLOCK.

This table is an illustrative public decision model for docs and partner review. Production policy may vary by partner, rail, mandate, and risk configuration.

When a request presents a passport_id, FLINT resolves the passport, verifies its hybrid signature (ES256 plus ML-DSA-65), and checks its lifecycle: stamped, and not revoked, frozen, or expired. For wallet payments, identity and principal attestation credit is applied only when the verified payer wallet matches the wallet bound to the passport.

An authenticated off-chain integration can instead present an owner-issued, short-lived, single-use purchase authorization bound to a specific merchant, action, currency, amount, and time window. A valid transaction-bound authorization can establish authority without pretending that the Passport wallet paid the off-chain transaction.

When a verified Passport has an EVM wallet, FLINT may add a factual Ethereum mainnet history baseline for that Passport-bound identity wallet. The record labels it passport_bound_wallet andidentity_wallet_not_shopify_payer. It is evidence only: observed or empty history does not create a clean, fraud, sanctions, or authorization judgment and does not change the verdict.

A stolen passport_id confers nothing. FLINT grants credit only after the applicable wallet match or transaction-bound authorization check succeeds.

Every record that carries a declared or resolved authorization scope also carries a scope evidence basis, so a counterparty reading the record can tell how that scope was established:

A counterparty should read passport_mandate as the principal's declared standing scope,wallet_corroborated as scope confirmed against wallet or transaction evidence, andpurchase_authorization as owner-issued authority bound to the specific off-chain action. The evidence-basis field makes those proof levels explicit.

FLINT uses MITRE F3 as an additive labeling vocabulary. Verification records are interpretable as MITRE F3 sightings; this does not imply MITRE endorsement or certification.

A mandate defines permitted actions, payment limits, counterparties, wallet bindings, and validity windows. FLINT uses the mandate to determine whether a payment request is inside authorized scope.

Sentinel turns an Agent Passport into a portable anti-fraud tool. It watches the agent's own permission set, its mandate, and alerts you out of band the moment that authority is escalated, with a one-tap kill switch to stop the agent everywhere FLINT is checked.

Sentinel catches takeover that escalates an agent's authority, and Freeze blocks the agent wherever FLINT is checked. It does not stop spending that stays within the agent's existing mandate, and it does not stop spending that never routes through FLINT. It is one layer of a defense in depth: the passport is identity, Sentinel is the takeover alarm and kill switch, and enforcement at the wallet or runtime is the hard backstop.

FLINT verification records are hybrid-signed. The primary signature is unchanged ES256 (ECDSA P-256) over the RFC 8785 canonical payload, carried as a compact JWS. A parallel post-quantum signature, ML-DSA-65 (NIST FIPS 204), is computed over the same canonical bytes and travels with the record as additive sibling fields (pq_signature, pq_kid, pq_alg) inside a versioned envelope (envelope_version: "hybrid-v0"). Because the signature travels with the record rather than in transport headers, it survives export, storage, paste-to-verify, and partner forwarding.

Existing ES256-only consumers ignore the new fields and validate the unchanged JWS exactly as before; PQC-aware consumers verify both signatures. The ML-DSA-65 public key is published in the JWKS using the draft IETF JOSE PQC AKP key type and is marked experimental. This is crypto-agile and versioned: FLINT is hybrid / PQC-ready, not standards-compliant, until the JOSE PQC RFCs ratify, and a draft change to the algorithm id or JWK type is configuration rather than a re-architecture.

Public records include explicit record and framework versions. Clients should store the version with the verification record and treat unknown major versions as incompatible until reviewed.

FLINT verifies authority and emits evidence. Payment rails, wallet providers, compliance engines, and agent frameworks remain separate trust domains. A verification record is not custody or settlement.

FLINT records use proxy identifiers and verification outcomes where possible. The goal is to preserve evidence of authorization without exposing unnecessary personal, wallet, or operational data to every counterparty.

The signed verification record gives teams a stable artifact for dispute defense, fraud review, controls testing, and audit support. Decoded data is not verified data; signature validation is required before treating a record as authentic.

Integrators should use the live HTTP and MCP surfaces below. FLINT does not currently publish an npm client package. The OpenAPI document is the source of truth for exact HTTP request and response fields.

Records and mutual acknowledgment

The published record JSON Schema defines the signed verification record versions. After completion, POST /api/records/:id/acknowledge records a counterparty acknowledgment beside the signed verification record. When both sides acknowledge the transaction, those acknowledgments form the mutual receipt both parties can retain with the record.

STEP-UP remediation options

STEP-UP is not a dead end. The response offers machine-readable options that an agent can satisfy, then the completed cure carries forward to future verifications.

Agents can also call the FLINT MCP tools when their runtime discovers tools dynamically. Human readers can use the MCP setup guide for client configuration and troubleshooting.

Each request needs a fresh replay-protection nonce and an ISO-8601 timestamp inside the accepted server window. See /openapi.json for the complete contract and response shapes.

POST /api/verify
Content-Type: application/json

{
  "nonce": "8b2ef62d-6ec0-4ac8-a5e4-e6d4ec447bcf",
  "timestamp": "2026-08-19T19:00:00.000Z",
  "timing_mode": "authorization",
  "transaction": {
    "chain": "eip155:8453",
    "token": { "symbol": "USDC", "issuer": "circle" },
    "amount_display": "847.00",
    "direction": "credit_to_merchant"
  },
  "agent_claim": {
    "agent_id": "agt_skyline_88af3c12",
    "principal_hint": "registered_controller"
  },
  "declared_scope": {
    "max_amount_per_tx_display": "1000.00"
  }
}

FLINT does not currently deliver a public flint.verification.completed outbound webhook. Integrators receive the verification result in the API response, retrieve records through the Records API, and submit observed outcomes with POST /api/outcomes.

Payment-provider or commerce-platform webhooks remain inside the integrator's system unless a separate FLINT integration explicitly documents them.