FLINT Verification Record Spec · Signed Agent Authority

On this page · Overview

01 / Getting Started

Overview

FLINT verifies non-human financial activity before money moves and records the result as signed evidence. It evaluates Principal Identity, Agent Identity, Wallet Provenance, Authorization Scope, Environment Identity, and Cross-Merchant Reputation, including agent authorization scope, environment identity, and cross-merchant agent reputation, to help stop cyber-enabled agentic fraud without blocking every useful agent.

02 / Getting Started

Quick Start

Step 1

Submit agent payment request

Step 2

Run FLINT verification

Step 3

Receive transaction decision

Step 4

Export verification record

03 / Getting Started

Run the Demo

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

04 / Core Concepts

KYA: Know Your Agent

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

05 / Core Concepts

FLINT Agent Passport

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.

06 / Core Concepts

Verification Layers

Principal Identity

Confirms the controller or principal associated with the agent request.

Agent Identity

Verifies the non-human actor presenting the payment request.

Wallet Provenance

Screens wallet context, funding signals, and payment instrument history.

Authorization Scope

Checks amount, counterparty, action, and time window against declared authority.

Environment Identity

Assesses runtime continuity and environment signals for the agent session.

Cross-Merchant Reputation

Uses network history to identify trusted, unknown, or abusive behavior.

07 / Core Concepts

Transaction Decisions

ALLOW

Payment may proceed within controls.

STEP-UP

An additional check is required before the payment clears.

REVIEW

Routed to a human; the signals conflict enough to warrant a look.

BLOCK

The request fails authority, policy, or risk checks. Stop before money moves.

08 / Specification

Verification Record

A verification record is the signed artifact that proves FLINT evaluated an agent before the transaction moved.

Each record captures the transaction context, agent claim, decision, score, issuer, and record version for dispute defense, fraud review, and controls testing.

09 / Specification

Record Schema

json

{
  "record_version": "1.0",
  "record_type": "agent_transaction_verification",
  "issuer": "flint",
  "framework": "KYA",
  "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"
  },
  "verdict": {
    "decision": "allow",
    "confidence": 0.2,
    "model_version": "flint-verifier-v1.0.0-sandbox"
  }
}

10 / Specification

Decision States

State	Record value	Meaning
ALLOW	allow	Payment may proceed within controls.
STEP-UP	step_up	An additional check is required before the payment clears.
REVIEW	review	Routed to human review.
BLOCK	block	Payment should not execute.

11 / Specification

Decision Model

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 v0.1 table is an illustrative public decision model for docs and partner review. Production policy may vary by partner, rail, mandate, and risk configuration.

80-100

ALLOW

Payment may proceed within controls.

60-79

STEP-UP

An additional check is required before the payment clears.

40-59

REVIEW

Routed to a human; the signals conflict enough to warrant a look.

0-39

BLOCK

The request fails authority, policy, or risk checks. Stop before money moves.

Rule example	Weight	Signal
principal_attested_by_known_issuer	+20	Principal attested by a known issuer or enrolled controller
principal_attestation_fresh	+10	Principal attestation is fresh
agent_known_named	+15	Agent is known-named in FLINT context
wallet_screening_clean	+15	Wallet screening returns clean
amount_in_scope	+10	Requested payment is within declared transaction scope
scope_window_active	+5	Payment falls inside the active authorization window
counterparty_on_allowlist	+5	Counterparty is included in the agent mandate
environment_identity_clean	+10	Runtime continuity signals are consistent with prior observations
principal_attestation_stale	-10	Principal attestation is stale
agent_cold_start	-10	Agent has limited prior FLINT context
no_authorization_scope_declared	-15	No authorization scope was declared for the request
high_value_transaction	-20	High-value payment requires enhanced review
no_principal_attestation	-25	No verifiable principal identity is present
environment_identity_suspicious	-30	Runtime continuity signals are inconsistent or suspicious
wallet_screening_flagged	-35	Wallet screening returns a material risk signal
amount_exceeds_per_tx_cap	-40	Requested payment exceeds the authorized limit

12 / Specification

MITRE F3 Labels

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.

Detected today

F1023

These chips render only after the technique id validates against FLINT's bundled F3 data.

Blind spots published by design

F1031 F1032 F1004 F1006.001 F1046 F1030 F1007

Open MITRE F3

13 / Specification

Passport Mandate

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.

14 / Specification

Sentinel: agent takeover protection

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.

Every change to a passport's mandate is attributed and written to an append-only ledger.

A classifier flags escalations: a raised spend cap or newly added permissions.

On escalation, the bound owner gets an out-of-band alert (Telegram or email), on a channel the compromised agent does not control.

The owner can Freeze the passport, a reversible kill-switch that makes verification return a hard block in /api/verify and /api/x402/verify. Unfreeze restores it. Revoke is also owner-reversible and always two-step.

States

activefrozen: reversible blockrevoked: reversible by the owner

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.

15 / Specification

Post-Quantum Signing

Hybrid / PQC-readyExperimental · versioned

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.

16 / Specification

JSON Examples

request

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

{
  "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"
  }
}

17 / Governance

Versioning

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.

18 / Governance

Trust Boundaries

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.

19 / Governance

Data Minimization

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.

20 / Governance

Auditability

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.

21 / Developer Reference

API Preview

http

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

{
  "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"
  }
}

22 / Developer Reference

Webhooks Preview

event

{
  "event": "flint.verification.completed",
  "record_id": "frv_01HX7KYA9W9A4Y0T5F6B2M3C8N",
  "agent_id": "agt_skyline_88af3c12",
  "verdict": {
    "decision": "allow"
  },
  "signed_record_url": "https://flint.network/api/records/frv_01HX7KYA9W9A4Y0T5F6B2M3C8N"
}

23 / Developer Reference

Error Codes

flint.invalid_request

The request is missing required transaction or agent fields.

flint.scope_missing

The payment request lacks an authorization scope.

flint.signature_unavailable

A verification completed, but signed export is temporarily unavailable.

flint.policy_denied

The transaction failed configured authority or policy checks.

24 / Developer Reference

Changelog

May 2026

Spec v0.1 published for FLINT MVP documentation.