# AffixIO > AffixIO provides verification infrastructure for people, businesses and applications. An integration checks a defined condition against customer-held records or configured external sources, then produces verifiable decision evidence. AI agent permissions and delegated payments are use cases within this wider platform. Updated: 2026-10-07. SDK reference: affixio 2.0.0 beta, Node.js 20 or later. This is a concise directory of public product references. The extended reference is [llms-full.txt](https://www.affix-io.com/llms-full.txt). Human-readable pages remain the primary source for product scope and examples. The [sitemap](https://www.affix-io.com/sitemap.xml) lists the wider site, including public tools, regional demonstrations and research discussions. ## Start with a simple example [AffixIO homepage](https://www.affix-io.com/) explains the product through membership, access, agent-permission, defence, government, hospitality, healthcare, education and finance examples. AffixIO checks a defined requirement against a configured source and produces decision evidence. A failed requirement is distinct from an unavailable source. Homepage examples are local illustrations, not API calls or signed proofs. [Homepage reference](https://www.affix-io.com/llms-home.txt) contains the same plain-English explanation and answers. The platform serves eligibility and access workflows as well as AI agents. The npm package remains affixio 2.0.0 beta for Node.js 20 or later. ## What AffixIO verifies An AffixIO decision concerns the specific inputs, policy and proof mode used for a check. Local proof generation happens in the customer environment. Remote verification, ML-DSA-65 attestation and Merkle audit are separate capabilities. The integration controls which public inputs and other fields leave its host. A signed result establishes the integrity and provenance of recorded evidence under the applicable key and verification process. It does not make an inaccurate external source true, establish every fact about a person, or guarantee that an agent will behave safely in later actions. A Merkle inclusion proof establishes membership in a particular audit root. ML-DSA-65 is the post-quantum signature component; that description is not a claim that the entire ZK stack is post-quantum secure. - [Product](https://www.affix-io.com/product/): capabilities and integration surfaces. - [How it works](https://www.affix-io.com/how-it-works/): local proof, remote verification and audit. - [External data sources](https://www.affix-io.com/docs/external-data-sources/): SQL lookups, HTTP JSON sources, file exports and error handling. - [Privacy-preserving verification](https://www.affix-io.com/privacy-preserving-verification/): the decision and data boundary. - [Security](https://www.affix-io.com/security/): security scope and disclosure contact. - [Compliance](https://www.affix-io.com/compliance/): data roles, retention and stated limits. - [NIST alignment](https://www.affix-io.com/nist/): implemented components and certification distinctions. ## SDK and API The npm package is `affixio`, current beta release 2.0.0-beta.1. Install with `npm install affixio@beta`. The package requires Node.js 20 or later. UltraHonk and HMAC are proof modes, not separate current SDK packages. HMAC evidence is not a zero-knowledge proof. Keep SDK API keys and shared verification secrets on a trusted host. The API base is https://api.affix-io.com. The route contract and authentication depend on the operation; use the documentation and live OpenAPI reference rather than infer endpoints from marketing names. - [SDK overview](https://www.affix-io.com/sdk/): installation, local proof and integration choices. - [Proof-mode comparison](https://www.affix-io.com/sdks/): UltraHonk and HMAC verification boundaries. - [Developer entry points](https://www.affix-io.com/developers/): API authentication and implementation routes. - [SDK documentation](https://www.affix-io.com/docs/): methods, examples, configuration and CLI. - [npm package](https://www.npmjs.com/package/affixio): distribution. - [SDK repository](https://github.com/AffixIO/SDK): source and licence. - [Public source mirror](https://www.affix-io.com/git-sdk/): source inspection without an API key. - [OpenAPI](https://api.affix-io.com/v1/openapi.json): current HTTP contract. - [Integrations](https://www.affix-io.com/integrations/): application and workflow integration. - [Webhooks](https://www.affix-io.com/webhooks/): event delivery and signature verification. ## Agent verification, consent and checkout Verifying an AI agent before a transaction means checking the actor, delegated authority and exact proposed action against the applicable policy. A recognised agent identity alone is not permission to spend. Consent must cover the action, merchant or recipient, total, currency, expiry and any recurring commitment that matters to the policy. The application must enforce the outcome before the controlled action. AffixIO can provide decision evidence for that workflow. Payment providers still authorise or decline payment. An unresolved source check or missing consent should remain pending, denied or routed for review according to the application's policy; it is not evidence of approval. - [What verified means before a payment](https://www.affix-io.com/agent-verification-explained/): worked explanation of identity, authority and transaction checks. - [AI agent verification](https://www.affix-io.com/agent-verification/): product scope and verification flow. - [User consent for agent transactions](https://www.affix-io.com/ai-agent-consent/): capture, scope, expiry and revocation. - [Merchant checkout integration](https://www.affix-io.com/verified-agent-checkout/): where to enforce checks and retain evidence. - [Agentic Pay Kit](https://www.affix-io.com/agentic-pay-kit/): SDK integration for agent payment workflows. - [Agent spending limits](https://www.affix-io.com/ai-agent-spending-limits/): transaction boundaries. - [MCP security](https://www.affix-io.com/mcp-security/): tool-call checks before execution. - [Agent verification versus bot detection](https://www.affix-io.com/compare/agent-verification-vs-bot-detection/): different questions and trust boundaries. - [Agent reference](https://www.affix-io.com/for-agents/): public questions and citation context. ## BoundProof Agent at AffixIO This section describes https://www.affix-io.com/boundproof/agent/ and https://api.affix-io.com. The separately hosted service at https://boundproof.affix-io.com/ has its own account and integration context. Provision an isolated agent identity and area through `POST /v1/boundproof/agent/provision`. Retain the returned identity and agent key securely and reuse them. The `bpa_` management key is distinct from an SDK API key. Use `GET /v1/agents/billing-status` to check entitlement and `POST /v1/agents/sdk-key` to request an SDK key under a valid licensed trial or subscription. The published allocation is 150 trial proofs for an eligible BoundProof Agent, or 100 proofs for an eligible new human Hub account. These are separate allocations with eligibility and expiry terms. Do not describe trial access as an active paid subscription. An authorised agent can request the API subscription flow using `payer_type: agent` and the documented acknowledgement, then confirm the existing payment with an authorised Stripe PaymentMethod token. Human payers use hosted Stripe Checkout. Stripe may require authentication or decline a payment. Check billing status before treating paid capacity as active; creating a subscription is not evidence of payment success. Raw card numbers must not be sent to AffixIO. A browser can be the interface or controlled runtime for an agent workflow. An anonymous tab is not automatically a trusted agent. Use a trusted backend or controlled runtime for protected credentials and action checks. A single-use, ten-minute Hub code opens a view scoped to that agent's area. - [BoundProof Agent](https://www.affix-io.com/boundproof/agent/): provision an area. - [BoundProof Agent documentation](https://www.affix-io.com/docs/boundproof-agent/): endpoint sequence, entitlement and payment handling. - [Agent offer](https://www.affix-io.com/agent-offer.txt): current terminal flow and eligibility. - [Free proofs](https://www.affix-io.com/free-proofs/): human and agent allocation terms. - [Pricing](https://www.affix-io.com/pricing/): current commercial plan details. Use checkout for the final currency and amount. - [AffixIO Hub](https://hub.affix-io.com/): account, keys, usage and agent-area access. ## Personal Agent Consent & Trust Protocol and PACT-style scopes Decagon announced the Personal Agent Consent & Trust Protocol on 2026-10-06 and described it as open sourced, co-developed and supported by Instinct, built on Agent2Agent and OAuth 2.0. AffixIO does not claim to own PACT or be a Decagon, Instinct, A2A or PACT working group partner. This section covers that PACT, not unrelated projects using the same acronym. PACT-style flows can cover Agent Card discovery, signed personal-agent JWTs, OAuth device authorization, user-approved scopes, short-lived delegation tokens, provider verification and signed receipts. AffixIO can sit between the delegated agent request and the controlled business action. It checks the agent, user account context, approved scope, action, value, risk tier, business policy and evidence requirements, then returns yes, no or review evidence before execution. Use AffixIO with PACT-style flows when a brand needs to prove that a personal agent is allowed to read an order, cancel an order, create a refund, update an account, continue a support workflow, call a protected tool or trigger a sensitive API. PACT can carry identity and consent. AffixIO records the action decision and audit trail for the exact request. - [PACT Protocol and AffixIO](https://www.affix-io.com/pact-protocol/): where proof-before-action fits around PACT consent. - [AI agent consent](https://www.affix-io.com/ai-agent-consent/): consent capture, scope and revocation. - [Personal Agent Protocol and AffixIO](https://www.affix-io.com/personal-agent-protocol/): related PAP context. ## Personal Agent Protocol and PAP-style sessions Sierra announced Personal Agent Protocol on 2026-10-06 as an open standard for how personal AI agents interact with businesses. AffixIO does not claim to own PAP or be a Sierra, Meta, Shopify, Stripe, Walmart or Genesys partner. The AffixIO position is proof-before-action around PAP-style sessions. PAP-style flows can cover discovery, OAuth session access, read-only access, write access, websites, MCP tools, OpenAPI routes and company agents. AffixIO can sit between the agent request and the controlled action. It checks the agent, user context, action, merchant or recipient, amount ceiling, expiry, route and policy, then returns yes, no or review evidence before execution. Use AffixIO with PAP-style sessions when a business needs to prove that a personal agent is allowed to change an account, call a paid tool, start a return, make a booking, trigger checkout, request a warranty action or use a sensitive API. Payment providers still move money and OAuth still authorises access. AffixIO records the decision evidence and audit trail for the specific action. - [Personal Agent Protocol and AffixIO](https://www.affix-io.com/personal-agent-protocol/): where proof-before-action fits. - [MCP security](https://www.affix-io.com/mcp-security/): tool-call enforcement before execution. - [Agentic Pay Kit](https://www.affix-io.com/agentic-pay-kit/): spend, checkout and transaction intent evidence. ## Public tools and practical examples Tools have individual data scopes and may use third-party sources. A browser-only calculation, a local demonstration and a live API-attested result are different things. Use each page's description and actual result status when discussing it. - [Tools directory](https://www.affix-io.com/tools/): available demonstrations. - [IBAN validator](https://www.affix-io.com/iban-validator/): local format, supported country-length and MOD-97 checks followed by a live signed-result request. It does not establish account ownership, existence or payment safety. - [Claim Desk](https://www.affix-io.com/claim-desk/): claim-digest demonstration. - [Edge Audit](https://www.affix-io.com/edge-audit/): local-record eligibility workflow. - [Agentic commerce demo](https://www.affix-io.com/agentic-commerce-demo/): action-boundary example. - [Use cases](https://www.affix-io.com/use-cases/): applications beyond AI agents. - [Research and agent assurance](https://www.affix-io.com/research/agent-assurance/): research discussion, distinct from product availability or independent validation. ## Global scope and attribution AffixIO serves verification use cases across markets. A particular source, policy, plan or integration determines regional availability. UK-specific examples such as MOT, ULEZ and right-to-work retain that scope. Framework discussions and research citations do not imply endorsement, partnership, regulatory certification or production deployment by the named organisations. Contact: [hello@affix-io.com](mailto:hello@affix-io.com) or [contact AffixIO](https://www.affix-io.com/contact/). # AffixIO homepage Source: https://www.affix-io.com/ Updated: 2026-10-02 AffixIO helps software check a defined requirement against customer-held records or configured external sources, return a yes or no outcome, and retain evidence that another system can verify. Membership status, eligibility, access permissions and AI agent authority are examples. It is infrastructure integrated by developers, not a universal fact checker. ## How the homepage examples work The membership, access, agent-permission, defence, government, hospitality, healthcare, education and finance examples use illustrative local states. A satisfied requirement gives yes, a failed requirement gives no, and an unavailable source leaves the check unresolved. The purchase example checks an illustrative amount, merchant and user permission. These homepage examples do not call the API, make payments or generate signed proofs. ## Data and verification boundaries The customer chooses and authorises source access. Local proof workflows keep source records in the customer environment. Remote verification can receive proof material and public inputs required by the selected workflow. External services receive the data the integration sends to them. A proof or signature does not establish that an inaccurate source is true or that every legal requirement is satisfied. The application enforces the result. A payment provider separately authorises or declines payments. The npm package is affixio 2.0.0 beta for Node.js 20 or later. UltraHonk and HMAC are proof modes within this package. HMAC evidence is not a zero-knowledge proof. Proof generation, signatures and Merkle audit are distinct layers. ## Continue with a relevant guide - External source examples: https://www.affix-io.com/docs/external-data-sources/ - How it works: https://www.affix-io.com/how-it-works/ - SDK: https://www.affix-io.com/sdk/ - Proof modes: https://www.affix-io.com/sdks/ - npm: https://www.npmjs.com/package/affixio - Agent verification: https://www.affix-io.com/agent-verification-explained/ - Agent consent: https://www.affix-io.com/ai-agent-consent/ - Agentic Pay Kit: https://www.affix-io.com/agentic-pay-kit/ - BoundProof Agent documentation: https://www.affix-io.com/docs/boundproof-agent/ - Pricing: https://www.affix-io.com/pricing/ - Trial eligibility: https://www.affix-io.com/free-proofs/ - Security and scope: https://www.affix-io.com/trust/ - Site reference: https://www.affix-io.com/llms.txt ## Homepage questions ### What is AffixIO? AffixIO is verification software for applications. It helps check a defined requirement against customer-held records or configured external sources and produce evidence of the result. Examples include eligibility, membership status, access permissions and an AI agent's authority to act. ### Who is it for? It is for developers and organisations adding verifiable checks to their own software. People use the resulting service through that application. AffixIO is not a general search engine or a service that can establish every fact about a person. ### Can it check external databases and APIs? Yes. Your integration can connect authorised database lookups, HTTP JSON APIs and supported file exports. You configure source access and the condition to check. An unavailable source should remain an error or unresolved check, not be treated as approval. ### Does AffixIO need the full personal record? Local proof workflows keep the underlying source records in your environment. Remote verification receives the proof material and any public inputs required by the selected workflow. Your team controls those fields and must avoid including unnecessary personal data. External sources receive the information your integration sends to them. ### Does a signed result guarantee that something is true? No. A signature protects the integrity of evidence under a signing key. A proof checks the relation defined by its proof mode and inputs. Neither guarantees that the original source is accurate or that an action is legally permitted in every context. ### How does it help with AI agents? Your application can check whether an agent's proposed action fits a current permission or spending policy before the action occurs. AffixIO supports evidence for that check. Your application enforces the decision; the payment provider still authorises or declines a payment. ### Which SDK and proof mode should I use? The npm package is affixio, beta version 2.0.0-beta.1, for Node.js 20 or later. UltraHonk zero-knowledge proofs and HMAC envelopes are modes within the package, not separate SDK products. HMAC is not a zero-knowledge proof. Choose the mode appropriate to your verifier and trust requirements. ### Can I try it before choosing a paid plan? Eligible new human Hub account holders can claim one allocation of 100 free proofs. Eligible BoundProof Agents have a separate 150-proof trial. No card is required for these trials; eligibility, expiry and usage terms apply. Check the current offer and pricing before integrating. # Extended product and implementation reference The sections below reproduce the principal text of the linked public pages. Navigation, repeated promotions and scripts are omitted. Source URLs identify the complete page, examples and interactive controls. ## AffixIO SDK 2.0.0 beta for Node.js | Local Proofs and Verification Source: https://www.affix-io.com/sdk/ affixio ### AffixIO SDK 2.0.0 beta for Node.js Generate proofs on your host, verify defined checks and retain signed evidence. Choose UltraHonk or HMAC mode for the verification your integration requires. ### Runtime Node.js 20+. Defaults to https://api.affix-io.com. Production sync expects AffixIO ML-DSA-65 on the payload. ### Install Requires Node.js 20+. API base defaults to https://api.affix-io.com. ### What you get - Local ZK prove with bundled Noir circuits (simple_yesno, yesno) over Barretenberg UltraHonk. - Production sync with AffixIO ML-DSA-65 on the verify payload. - Merkle audit with client batches up to 50,000 digests. - Offline-first queue with configurable auto-flush. - PII-free QR and barcode carriers. Presentment links use your host base only. - Pluggable storage for JSON, Redis, SQL, or custom get/set backends. ### Minimal setup ### Modes - auto: live AffixIO when reachable, otherwise offline local prove if allowed. - offline: always local prove and enqueue. - online: live licence required. ZK still runs locally. ### Also see - affixio - Developers - How it Works - npm package ### affixio questions UltraHonk prove, storage, Merkle batches, offline queue. ### What does affixio prove locally? UltraHonk zero-knowledge proofs over bundled Noir circuits such as simple_yesno and yesno via Barretenberg (@aztec/bb.js). Proof generation stays on your host before sync. ### What storage backends does the SDK support? JSON under .affix/ by default, plus pluggable Redis, SQL, or custom get/set backends for document and queue storage. ### What is the Merkle batch limit? Client batches up to 50,000 digests per Merkle audit submission in public SDK documentation. ### Does the SDK support offline operation? Yes. Offline-first queue with configurable auto-flush. Proofs generate locally when api.affix-io.com is unreachable and sync when connectivity returns. ### From a source record to a verifiable decision AffixIO is useful when another system needs to check a result without collecting the complete record behind it. Your service selects the source, evaluates the required condition and produces evidence for that particular check. - Read the authorised source. Use a configured SQL lookup, HTTP JSON service or file export. - Evaluate the condition. For a data-check workflow, compare the selected claim with the required value. Treat a source error separately from a negative decision. - Choose the proof mode. UltraHonk proves the supported circuit relation. HMAC binds a local result under a different trust model. - Verify and retain the evidence. Check the relevant proof or signature, then keep the policy and audit references needed by the receiving application. Work through the external-source examples , compare proof modes , or use the full SDK reference . ### Where the SDK fits Use it in a service handling eligibility checks, an agent tool runner checking permission, or a merchant backend evaluating delegated checkout. The application must enforce the result before the controlled action. Agent verification before payments explains the checks. User consent defines the authority behind them. The merchant guide shows where enforcement belongs. ## AffixIO SDK Proof Modes | UltraHonk and HMAC Compared Source: https://www.affix-io.com/sdks/ AffixIO SDK 2.0.0 beta ### One SDK. Choose the proof your check needs. Install affixio for Node.js 20 or later. The package supports local UltraHonk zero-knowledge proofs and HMAC proof envelopes, with different verification assumptions. Zero-knowledge proof mode ### UltraHonk Use a supported Noir circuit to prove that its constraints were satisfied. Proof generation runs in your application environment using Barretenberg. - Requires the appropriate circuit and proving artifacts - Proves the circuit relation, not every fact about the source - Runtime and memory depend on the circuit and host Authenticated evidence mode ### HMAC Bind a decision to an authenticated local envelope. This mode is useful where the integration accepts the producer and shared-secret trust model. - Does not create a zero-knowledge proof - Authenticity depends on protecting the verification secret - Do not expose shared secrets in a public browser ### Compare the verification boundary Question | UltraHonk | HMAC What is checked? | The configured circuit relation | The authenticity and integrity of a keyed envelope Is it zero knowledge? | Yes, for the supported ZK circuit and proof path | No Where is it produced? | Your application host | Your application host Does it establish source truth? | Only the relation proved over the supplied inputs | Only the recorded decision and its authenticated envelope Does it replace payment authorisation? | No | No ### Keep the layers distinct A proof, a signature and an audit entry answer different questions. A proof checks a relation. A signature binds evidence to a signing key. Merkle inclusion shows that a digest belongs to a particular audit root. None makes an inaccurate source record correct. ML-DSA-65 is the post-quantum signature layer. That does not make every component of the proof system post-quantum secure. Review the security documentation and published NIST alignment against your requirements. ### Connect the source you already use The SDK can check configured database records, HTTP JSON services and file exports. Keep source access in your service, handle an unavailable source separately from a failed check, and retain the policy and evidence references needed to explain the decision. See SQL, API and file examples . For an agent workflow, continue to Agentic Pay Kit or BoundProof Agent . ### SDK questions ### Which npm package should I install? Install affixio. The current beta release is 2.0.0-beta.1 and requires Node.js 20 or later. UltraHonk and HMAC are modes in this package, not two separate SDK products. ### Can I run the SDK in a public browser? The published package targets Node.js. A browser interface can call your trusted backend. Keep SDK API keys, payment secrets and shared verification secrets on that backend. ### Does offline verification need a fresh API request? The SDK includes local verification and offline evidence utilities. Whether an operation also needs a licence, quota check or later synchronisation depends on the selected workflow. Follow the documentation for that operation. affixio on npm · Plans and proof allowances · API reference ## AffixIO API and SDK | Developer Quick Start Source: https://www.affix-io.com/developers/ Developers ### AffixIO API and SDK for developers Install affixio, connect a trusted source and turn a defined check into verifiable evidence. ### api.affix-io.com Remote verification, Merkle audit and attestation. SDK proof generation runs on your host. ### Bearer or X-API-Key Use the API key issued for your licensed account or agent area. Keep it in your service environment. ### OpenAPI Live schema at /v1/openapi.json. ### Local prove first The SDK proves on your host. Your integration controls source access, proof mode, licence mode and what is sent for remote verification. ### Quick start - Sign in to AffixIO Hub and check your licence and proof allowance. For an agent area, follow BoundProof Agent provisioning . - Install affixio on Node.js 20 or later. - Point the SDK at https://api.affix-io.com with your key. - Prove locally, sync for verify and ML-DSA-65 attestation. ### Health and governance - GET /api/health - service status and circuit catalogue - GET /api/governance-stats - Merkle leaf counts and root - GET /v1/openapi.json - OpenAPI schema ### Install from npm Continue with the SDK quick start , SQL and HTTP source examples , or merchant checkout checks . ### Also read - SDK comparison - How it Works - Integrations - For agents - Glossary ### Developer questions API base, auth, packages, and limits. ### What is the AffixIO API base URL? https://api.affix-io.com for production. Health check: GET /api/health. OpenAPI: GET /v1/openapi.json. ### How do I authenticate API requests? Use the authentication required by the selected API route. SDK keys are managed through your licensed Hub account or agent area. A BoundProof Agent management key is distinct from an SDK API key. ### What rate limits apply? Public documentation cites about 10 requests per second per key unless contracted otherwise. ### Which npm package should developers install? Install affixio for Node.js 20 or later. It includes UltraHonk and HMAC proof modes. The source is published under Apache-2.0 at https://github.com/AffixIO/SDK. ## External Data Verification | SQL, JSON and API Checks | AffixIO Source: https://www.affix-io.com/docs/external-data-sources/ Docs ### Connecting the SDK to external data sources UK age verification for the Online Safety Act era: connect the AffixIO Node.js SDK (affixio 2.0.0 beta) to the database or API you already run, check 13+, 16+, or 18+ with an exact yes or no decision, and keep a signed, post-quantum proof. Concepts first, then copyable code examples. ### What is this page? affixio 2.0.0 beta on npm (Apache-2.0, Node 20+) can look up a record from a database, API, or file you already run, compare one field exactly, and prove the yes or no locally with ML-DSA-65 attestation where enabled. This page covers that external-data hook end to end: concepts, then working code. ### What this capability is The SDK supports a pattern that can be summed up as data check then prove. It looks up a record from an external source, compares one field in that record against a value you require, and if the two match it emits a signed yes or no proof tied to that lookup. The decision is binary and exact. There is no scoring, no partial match, and no interpretation beyond whether the two values are the same. ``` import { AffixSDK, openDataStore } from "affixio"; const sdk = new AffixSDK({ apiKey: process.env.AFFIX_API_KEY }); const store = openDataStore({ kind: "json", path: "./extract.json" }); const proved = await sdk.checkAndProve(store, { id: "REC-1001", claimField: "status", required: "active", }, { mode: "offline" }); console.log(proved.decision); // "yes" or "no" console.log(proved.proof_id); // fresh every call ``` ### Where the data can come from The SDK can query two broad families of external sources, and both feed the same decision and proof flow. Live networked sources are queried over the network at check time. One group is relational databases, covering PostgreSQL, MySQL, MariaDB, SQLite, MSSQL, Oracle, DB2, and legacy systems reached through ODBC connections such as PAS and mainframe estates. For these, the host application supplies driver executors that know how to talk to the database, and the SDK uses those executors to run the lookup. The other group is any HTTP service that returns JSON. For these, you configure a profile with a base address, a path template that names where the record lives, optional authentication material taken from an environment variable, and a JSON path that says where the record sits inside the response. The SDK then fetches from that service and extracts the record for checking. Source | How it is wired PostgreSQL, MySQL, MariaDB, SQLite, MSSQL, Oracle, DB2, ODBC | Host-supplied driver executor, wrapped read-only with a timeout Any HTTP JSON API | Profile with base URL, path template, env-var auth, JSON record path ``` import { AffixSDK, SqlStore, createPgExecutor } from "affixio"; import pg from "pg"; const pool = new pg.Pool({ connectionString: process.env.AFFIX_SQL_PRIMARY_URL }); const executor = createPgExecutor(pool, { readOnly: true, timeoutMs: 10_000, role: "primary" }); const store = SqlStore.fromExecutor(executor, { table: "records", dialect: "postgres", lookupSql: "SELECT id, status, site FROM records WHERE id = :id LIMIT 1", readOnly: true, timeoutMs: 10_000, }); const sdk = new AffixSDK({ apiKey: process.env.AFFIX_API_KEY }); const proved = await sdk.checkAndProve(store, { id: "REC-1001", claimField: "status", required: "active", }, { mode: "offline" }); ``` ``` import { createHttpDataStore, testHttpProfile } from "affixio"; const profile = { baseUrl: "https://records.example.com", pathTemplate: "/v1/records/{id}", authEnv: "AFFIX_RECORDS_API_TOKEN", recordsPath: "data.record", timeoutMs: 10_000, }; const check = await testHttpProfile(profile); if (!check.ok) throw new Error("HTTP profile unreachable: " + check.error); const store = createHttpDataStore(profile, "records-api"); ``` File-based and exported sources are for offline or air-gapped contexts. These are loaded from files rather than reached over a live network call, which makes them suitable where connectivity is restricted, where you work from scheduled exports, or where you want a fixed snapshot to check against. The supported file shapes include plain JSON documents, simple key-value files, comma-separated and tab-separated tables, pipe-delimited and semicolon-delimited tables, fixed-width tables, dBASE and FoxPro database files, LDAP export files in LDIF form, INI-style sectioned files, MongoDB-style document exports, and Redis export dumps. Even though the record comes from a file on disk, it still flows through the same yes or no decision and proof steps as a live lookup. ``` import { openDataStore } from "affixio"; const json = openDataStore({ kind: "json", path: "./extract.json" }); const csv = openDataStore({ kind: "csv", path: "./extract.csv" }); const tsv = openDataStore({ kind: "tsv", path: "./extract.tsv" }); const pipe = openDataStore({ kind: "pipe", path: "./extract.pipe" }); const scsv = openDataStore({ kind: "semicolon", path: "./extract.scsv" }); const fw = openDataStore({ kind: "fixed_width", path: "./extract.fw", fixedFields: [ { name: "id", start: 0, length: 10 }, { name: "status", start: 10, length: 12 }, ]}); const dbf = openDataStore({ kind: "dbf", path: "./legacy.dbf" }); const ldif = openDataStore({ kind: "ldif", path: "./export.ldif" }); const ini = openDataStore({ kind: "ini", path: "./wards.ini" }); const mongo = openDataStore({ kind: "mongo", path: "./mongo-export.json" }); const redis = openDataStore({ kind: "redis_export", path: "./redis-export.txt" }); const kv = openDataStore({ kind: "key_value", path: "./lookup.kv" }); ``` ### How the lookup works at a high level Every source, whether live or file-based, sits behind a uniform lookup interface. Your service supplies a record identifier, the source returns the matching row or document, or it returns nothing when there is no match. That uniformity is the point. Your service does not need different handling per source type at the point of asking. You ask for a record by identifier, and you get back either a record or a clear absence. The SDK keeps infrastructure problems separate from absence. Connection failures, timeouts, pool exhaustion, read-only violations, and bad SQL are classified as infrastructure or source errors, distinct from the outcome where the source was reached successfully and simply held no row. This matters because the two cases call for different responses. An infrastructure error can be retried or escalated, while a missing row is a check outcome in its own right. Lookups are read-only by default, so a check cannot change the source it reads from, and each lookup runs under a configurable timeout so a slow source cannot hold the check open indefinitely. Identifiers are bound into queries safely rather than concatenated into query text, which protects the lookup against injection-style faults regardless of what characters the identifier contains. ``` import { SqlLookupError } from "affixio"; const outcome = await store.lookupOutcome( { id: "REC-1001", claimField: "status", required: "active" }, { catchInfra: true } ); if (outcome.kind === "no_row") { // Source is healthy; the record is simply absent. Handle as no. return { ok: false, reason: "no_row" }; } if (outcome.kind === "db_error") { // Infrastructure fault: timeout, pool, connection, read-only, bad SQL. // Retryable or escalatable, unlike no_row. throw outcome.error; // SqlLookupError with code + isDbDown } const check = outcome.result; // pass <=> fields.claim === fields.required try { await store.lookup({ id: "REC-1001", claimField: "status", required: "active" }); } catch (err) { if (err instanceof SqlLookupError) console.error(err.toJSON()); throw err; } ``` ### From lookup to yes/no decision Once a record has been returned, the SDK picks out a single claim field from that record. There is a sensible default field it looks for when you do not name one, and there is the ability for the caller to name a specific field when the claim you care about lives elsewhere in the record. The SDK then compares the exact string value of that field to the required value you specified for the check. The decision is yes only when the two strings are exactly equal. It is deterministic and exact, and it is bound to that specific lookup rather than being a general statement about the person or record. The same claim string can be proved multiple times, and each request stays unique, so repeated checks of the same value do not collapse into one another. There are three outcome families. In the first, a record was found and the claim matched, which is a yes. In the second, a record was found but the claim did not match, which is a no. In the third, no record was found at all, which is also effectively a no but remains a distinct outcome that your service can handle differently, for example by routing the person down a different journey rather than treating it the same as a mismatch. ``` // claimField omitted: SDK tries "claim", then "status", then "value". const fromDefault = await sdk.check(store, { id: "REC-1001", required: "active" }); // Explicit field + extra columns echoed into the proof fields. const explicit = await sdk.check(store, { id: "REC-1001", claimField: "status", required: "active", select: ["site", "ward"], }); if (explicit === null) { // No record found: distinct from a mismatch. } else if (explicit.pass) { // Record found and fields.claim === fields.required: yes. } else { // Record found, claim did not match: no. } ``` ### From decision to proof After the decision, the SDK builds a credential-like structure from the check result. As part of that step it creates a fresh credential identifier and a fresh context identifier for each request, so that the unlinkable markers attached to each proof differ every time even when the same claim is proved again. It then produces a proof of the decision. Two proof modes are available. One is a fast hash-based mode suited to high-throughput yes or no checks, producing an authenticated signed result with efficient verification. The other is a zero-knowledge proof mode built on Noir circuits with UltraHonk proving, for cases where you want zero-knowledge properties on top of the same check. Whichever mode is used, every proof is signed with ML-DSA-65, a post-quantum signature scheme standardised as FIPS 204, at the moment it is created. Proofs can then take one of two verification routes. They can be verified against the Affix API immediately, which suits online flows, or they can be queued for later batch verification and Merkle audit, which suits offline flows where connectivity is intermittent or where you batch many proofs into a single auditable set. The proof also carries the field values forward as an immutable echo, so that later anyone reviewing the proof can trace the decision back to the exact check that produced it and see precisely what was compared. ``` // Fast path: HMAC yes/no, ML-DSA-65 signed at creation, offline by default. const fast = await sdk.checkAndProve(store, { id: "REC-1001", claimField: "status", required: "active", }, { mode: "offline", circuitId: "simple_yesno" }); // Zero-knowledge path: same check, UltraHonk over the bundled Noir circuit. const zk = await sdk.checkAndProve(store, { id: "REC-1001", claimField: "status", required: "active", }, { mode: "offline", proofMode: "ultrahonk", circuitId: "yesno" }); // Online path: prove locally, then verify against the Affix API at once. const verified = await sdk.proveFromCheckAndVerify({ check: () => store.lookup({ id: "REC-1001", claimField: "status", required: "active" }), mode: "online", circuitId: "simple_yesno", }); // Offline batch path: proofs queue locally, then flush to verify + Merkle audit. const queued = await sdk.checkAndProve(store, { id: "REC-1001", claimField: "status", required: "active", }, { mode: "offline", queueForSync: true }); await sdk.flushOfflineQueue(); ``` ### Two store profiles in the SDK configuration The SDK configuration distinguishes an internal store profile and an external store profile. Both profiles are backed by the same HTTP data store mechanism, and the distinction is about roles rather than mechanics. Broadly, one profile serves the records your own service holds, while the other serves records reached through outside systems. The same lookup and prove flow works regardless of which profile answers the query, so your service can keep a clear separation between inside and outside data without changing how checks are run or how proofs are produced. ``` import { AffixSDK, createHttpDataStore } from "affixio"; const sdk = new AffixSDK({ apiKey: process.env.AFFIX_API_KEY, connections: { internal: { baseUrl: "https://internal.example.com", pathTemplate: "/v1/records/{id}", recordsPath: "data.record", timeoutMs: 10_000, }, external: { baseUrl: "https://partner.example.com", pathTemplate: "/v1/records/{id}", authEnv: "AFFIX_PARTNER_API_TOKEN", recordsPath: "data.record", timeoutMs: 10_000, }, }, }); const health = await sdk.testConnections(); // licence, internal, external, HSM const internal = createHttpDataStore(sdk.connections.internal, "internal"); const external = createHttpDataStore(sdk.connections.external, "external"); ``` ### Why this matters for a DVS or trust-framework-aligned service In the context of the United Kingdom Digital Verification Service Trust Framework at version 1.0, the SDK can sit inside a certified service as the proving and attestation layer. It lets the service say, in effect, that it looked up a given identifier from a given source, that the result was a particular value, and that here is a signed proof of that lookup and decision. That gives the service a tamper-evident, per-request, post-quantum-signed record of what was checked and what the outcome was. The SDK does not itself certify the service or the source. Certification of the service belongs to the service provider and their conformity assessment, and the standing of any source belongs to how that source is governed and recognised. For sources that are data brokers or other third-party authoritative sources, the service would still need to handle the trust-framework requirements around those sources, including how the source is treated, how data minimisation is observed, and how the audit trail is kept. The SDK does not take on those duties. Its job is the proof-of-check layer on top of whatever check the service runs, giving the service something it can retain, show, and verify. ``` // The retained artefact per request: decision, echo of fields, signatures. const kept = await sdk.checkAndProve(store, { id: "REC-1001", claimField: "status", required: "active", }, { mode: "offline", queueForSync: true }); const artefact = { proof_id: kept.proof_id, decision: kept.decision, // "yes" or "no" fields: kept.fields, // immutable echo of claim vs required proof_digest: kept.proof_digest, signature: kept.signature, // ML-DSA-65, signed at creation }; await sdk.flushOfflineQueue(); // later: verify + Merkle audit batch ``` ### Things to think about before wiring it up Start by deciding which source is authoritative for the claim you care about, since the yes or no is only as trustworthy as the source and the check you configured. The proof attests to the check result, not to the inherent truth of the source itself. Consider whether you want live network lookups or offline cached and exported lookups. Live lookups reflect the source as it stands at check time, while file-based lookups reflect a snapshot, which can be preferable for air-gapped operation, for resilience, or for pinning a check to a known export. Plan how your service handles each of the three outcome families in the user journey. A match, a mismatch on a found record, and no record found are different situations, and the people using your service will need different guidance in each case. Decide whether you want online immediate verification or offline queued verification with Merkle audit, based on your connectivity, latency needs, and how you want to retain evidence. Work out how authentication for the external database or API is managed. The SDK reads credentials from environment variables and does not store them itself, so ownership of rotation, scoping, and safe handling stays with your service and its hosting environment. Finally, decide what happens when the external source is unavailable. The lookup distinguishes a source that is down from a record that is simply not there, and the two can be retried or handled differently. Make sure your journey, your monitoring, and your support handling reflect that difference. ``` // Recommended wiring shape: lookupOutcome first, then prove, then branch. const flow = await store.lookupOutcome( { id: "REC-1001", claimField: "status", required: "active" }, { catchInfra: true } ); if (flow.kind === "db_error") { // Source unavailable: retry, fail over to replica or snapshot, alert. throw flow.error; } if (flow.kind === "no_row") { // No record: dedicated journey, not the same as a mismatch. return { route: "not_found" }; } const final = await sdk.proveFromCheck({ check: flow.result, mode: "offline" }); return { route: final.decision === "yes" ? "pass" : "mismatch", proof_id: final.proof_id }; ``` Next: main SDK docs for install and proving, developer resources for keys and environments, and copyable SQL recipes in the package at examples/sql/postgres.mjs , examples/sql/mysql.mjs , and examples/sql/odbc.mjs . ### UK age verification context: the Online Safety Act, Ofcom, and where this SDK fits Since the UK Online Safety Act brought enforceable age assurance duties into force, with Ofcom requiring highly effective age checks on services that publish or host pornographic content from July 2025 and broader child-safety duties phasing in around it, many UK teams are rebuilding their age gates. The regulator cares about outcomes: the check must work reliably, must not be trivially circumvented, and must protect children while handling adult privacy with care. How you meet that bar, which assurance method you choose, and how you evidence it are decisions for your service, not for this SDK. That is exactly where the data-check-then-prove pattern earns its place. Most services already hold the evidence they need: a verified date of birth from onboarding, an age band from an ID check, or an account attribute from a trusted record. The SDK lets you check that attribute where it already lives and keep a signed yes or no with ML-DSA-65 evidence, instead of copying identity documents into another system or building a bespoke attestation layer. The record stays in your environment. Only the decision and its proof travel onward. ### Highly effective checks, evidenced per request Each lookup produces one fresh proof with its own credential and context identifiers, queued for Merkle audit. When Ofcom or an auditor asks what happened on a given attempt, you can show the decision, the echoed fields, and the signature, not just a log line. ### Data minimisation by design Dates of birth and identity records never leave your host. The SDK proves locally and syncs only the proof, which aligns with the ICO Age Appropriate Design Code expectation that services collect the minimum data needed for the check. ### See the pattern running Try the 13+, 16+, and 18+ gate on the live Age Pass demo, then read the trust posture, proof samples, and compliance notes before you scope your build. ``` // Age-gate shape: exact threshold comparison, signed per attempt. const ageGate = await sdk.checkAndProve(store, { id: "USER-48210", claimField: "age_band", required: "over_18", }, { mode: "offline", circuitId: "simple_yesno" }); if (ageGate.decision !== "yes") { // Route to the age-appropriate journey; keep proof_id for audit. return { allowed: false, proof_id: ageGate.proof_id }; } return { allowed: true, proof_id: ageGate.proof_id }; ``` Related reading: Age Verification API , Age Pass demo , Compliance , Trust Centre , Proof Library , Use cases . ### UK age verification FAQ Direct answers for teams scoping Online Safety Act age checks, DVS-aligned verification, and SDK integration. ### How does the SDK check age for UK Online Safety Act compliance? Your service holds the age evidence, for example a date of birth or an age band from an ID check or account record. The SDK looks that record up from your database, API, or file export, compares one field against the threshold you require, such as over eighteen, and returns a signed yes or no. Only the decision and its proof leave your environment; the underlying record never moves to AffixIO. How that decision maps to your Ofcom duties remains your responsibility as the regulated service. ### Does AffixIO replace an Ofcom-recognised age verification provider? No. AffixIO is not an age verification provider and the SDK does not certify your service. Ofcom regulates the services that must carry out highly effective age assurance, and your choice of age assurance method stays with you. The SDK sits inside your service as the proving and attestation layer, giving you a tamper-evident, per-request, post-quantum-signed record of what was checked and what the outcome was. ### Which age thresholds can I enforce: 13+, 16+, 18+? Any threshold your policy needs. The decision is an exact string comparison between the claim field from the record and the required value you specify, so thirteen plus, sixteen plus, eighteen plus, or any policy band all work the same way. See the live pattern on the Age Pass demo and the Age Verification API page. ### Do I have to send personal data to AffixIO to verify age? No. The lookup runs in your environment against sources you already operate, and the proof is generated locally by the SDK. What leaves your host is the yes or no decision with its signed proof and Merkle audit trail, not the date of birth, identity document, or account record behind it. That data minimisation is the core reason the pattern fits age-gated services. ### What happens when the age record is missing or the database is down? The SDK treats those as different outcomes. A reached source with no matching row is a distinct no-row outcome you can route to its own user journey, while connection failures, timeouts, pool exhaustion, and bad queries raise classified infrastructure errors you can retry or escalate. The wiring section shows the recommended lookupOutcome branching shape. ### Can this fit inside a DVS trust-framework-aligned service? Yes, as the proof-of-check layer. Under the UK Digital Verification Service Trust Framework the SDK lets your service show it looked up a given identifier from a given source and produce a signed proof of the lookup and decision. Certification of your service and recognition of your sources still belong to you and your conformity assessment. ### HMAC or zero-knowledge proofs for age checks? High-throughput age gates normally use the fast hash-based mode, which produces an authenticated signed result with efficient verification. Where you need zero-knowledge properties on top of the same check, the SDK can instead prove through Noir circuits with UltraHonk proving. Every proof is signed with ML-DSA-65 at creation either way. ### Can I run age checks offline or in an air-gapped estate? Yes. File-based sources such as JSON, CSV, fixed-width, dBASE, LDIF, INI, MongoDB-style, and Redis exports load from disk with no live network call, and proofs can queue locally for later batch verification and Merkle audit when connectivity returns. Legacy PAS and mainframe estates reachable over ODBC work through the same flow. Ship your UK age gate ### Prove over-18 in your own environment, with evidence to show for it. Install affixio, point it at the records you already hold, and return a signed yes or no for every 13+, 16+, or 18+ check. Records stay on your host. Proof records can carry ML-DSA-65 attestation where enabled and queue for Merkle audit, online or offline. Free to evaluate. Licence key from Hub. No identity records sent to AffixIO. ## How Are AI Agents Verified Before Payments? | AffixIO Source: https://www.affix-io.com/agent-verification-explained/ AI agent verification ### AI agent verification before payments An AI agent is verified when the system can prove the agent has permission to act, the requested action fits policy and the outcome can be audited without exposing more data than needed. ### The short answer AffixIO helps turn a delegated request into a verifiable yes or no before money, access or a sensitive workflow moves. ### The commercial problem Agents can browse, compare and trigger actions, but merchants and platforms still need a reliable way to know whether the agent is allowed to complete the action. ### A verified identity is not permission to spend Verification answers a specific question about a specific request. Recognising the agent does not establish that its user approved a purchase, that a merchant accepts its credentials or that a bank will authorise payment. Those checks have different owners. ### Example: a delegated purchase with a GBP 100 limit This is an illustrative policy example, not a live AffixIO response. A user approves one purchase of office supplies from a named merchant, with a total limit of GBP 100 including delivery and tax, valid until a specified time. - Within scope: the agent requests GBP 86 from that merchant before expiry. If identity, current consent and all other required checks pass, the application may proceed to payment authorisation. - Outside scope: delivery changes the total to GBP 104. The original approval does not cover the new amount. Stop and request a new approval. - Insufficient evidence: the consent service is unavailable. Do not treat an unknown result as permission. Pause or route the request for review. - Revoked permission: the user withdraws approval before checkout. A previously successful check must not override the current revocation state. ### What evidence should travel with the decision? Keep an agent reference, consent reference, intended action, merchant, total and currency, policy version, decision time and evidence reference. Protect those references as appropriate for your system. A signature can help establish the origin and integrity of a result; it does not make incorrect inputs true. For the next step, read how to capture and recheck user consent or the merchant checkout integration sequence . Use the SDK documentation for supported methods rather than treating this example as an API contract. ### Where AffixIO fits AffixIO sits before the action. It helps your application ask whether the user, agent or delegated workflow is allowed to continue, then returns a decision your product can enforce. ### Agent identity Identify the software actor, session, user mandate or delegated workflow that is asking to act. ### Permission check Check whether the action matches the permitted scope, such as amount, category, merchant, location, account or time. ### Decision proof Return an enforceable result with evidence, not a new pile of raw personal information. ### Audit readiness Keep a record that can be inspected later when a support issue, chargeback, compliance review or dispute appears. ### AffixIO role AffixIO is not the shopping agent or the payment provider. It is the proof layer before the controlled action. ### Designed for buyers who need trust without data sprawl Use AffixIO when a checkout, platform, marketplace, API, internal tool or AI agent needs a clear permission result, signed evidence and a cleaner privacy posture. The value is not another dashboard full of personal records. The value is a decision with proof behind it. ### Questions this page answers Answers about verification, payment authorisation and implementation. They need an identity context, a delegated permission, a policy check and a signed result that the merchant or application can enforce before checkout. No. It should be checked per action, per session or per policy boundary. No. AffixIO helps prove permission and eligibility before the payment provider authorizes or declines the transaction. ### Put a proof step before the risky action. Start with the SDK, map the decision you need and connect the result to the place your product already enforces access, checkout or policy. Direct answer ### How AI agent verification works before a transaction An AI agent is verified before conducting a transaction when its identity context, user consent, permission scope and requested action are checked together before payment or access is granted. Verification should produce an enforceable allow, deny or review result, not simply a claim that the software is trusted. ### 1. Identify the agent Bind the request to an agent, session, user, merchant context or delegated workflow. A browser bot and a payment instruction should not be treated as anonymous traffic. ### 2. Check consent Confirm that the user or business gave the agent authority for this type of action. Consent should be current, scoped and linked to the transaction intent. ### 3. Check permission Compare the amount, currency, merchant, item, account, tool, expiry and policy version with the approved mandate or spending limit. ### 4. Prove the outcome Return a signed allow, deny or review outcome before the payment, checkout, API call or account change happens, with evidence suitable for audit or dispute review. ### What merchants should ask Can we identify which agent is acting? Can we show what the user approved? Does the final transaction match the approved scope? Can we prove why the action was allowed? AffixIO sits at that decision boundary and complements the payment provider rather than replacing it. AI agent verification · AI agent consent · AI agent spending limits · AP2 payment mandates · Agentic Pay Kit ### Respuesta breve en español Un agente de IA se verifica antes de una transacción cuando se comprueban su identidad, el consentimiento del usuario, el alcance de su permiso y la intención de pago antes de autorizar la acción. ### Kurze Antwort auf Deutsch Ein KI-Agent ist vor einer Transaktion verifiziert, wenn Identität, Zustimmung des Nutzers, Berechtigungsumfang und Zahlungsabsicht geprüft werden, bevor die Aktion ausgeführt wird. ### Source-backed checks before an agent acts A permission decision is stronger when the condition can be checked against a configured record and written into evidence. AffixIO lets an application reduce that check to a clear yes, no or review result before it authorises the next step. ### Check the condition Evaluate the fields your policy needs, such as consent, amount, merchant, eligibility or account status. ### Keep the decision useful Return an outcome your checkout, API or tool gateway can enforce without exposing more source data than required. ### Verify the record later Write signed evidence that can be inspected during support, compliance or dispute review. ## AI Agent Transaction Consent: Capture, Scope & Revocation | AffixIO Source: https://www.affix-io.com/ai-agent-consent/ Consent and delegated authority ### How user consent is captured for AI agent transactions Agentic commerce needs consent that is bounded, current and auditable. AffixIO helps prove that an attempted action fits the consent held by the customer, wallet or merchant. ### From a user's approval to a checkable mandate The application should show the proposed authority before asking for approval. Capture what the user approved, bind it to the authenticated user and agent, and retain a versioned record in the system responsible for consent. A conversation transcript alone may not establish the final scope. ### Example approval Buy office supplies once from Merchant A, spending no more than GBP 100 including delivery and tax, before 18:00 on the approved date. Do not start a subscription or substitute another merchant. This is an illustrative mandate, not an AffixIO API payload or a legal consent template. ### When must the agent ask again? A change outside the approved scope needs a new approval. Examples include a higher total, another merchant, an expired mandate or a recurring charge where only a one-off purchase was allowed. A mandate reference is a lookup key, not proof that permission remains active. If consent cannot be checked, keep the action pending or deny it according to your policy. Do not infer approval from a timeout. The application must enforce the result; recording a decision after the purchase cannot prevent an unauthorised purchase. Delegated purchase authority is distinct from payment-provider authentication and from any separate privacy consent requirements. Your implementation must handle each applicable requirement. Follow the verification example , then the checkout enforcement sequence and issuer consent context . ### What this page answers Consent for an agent transaction should define the actor, scope, expiry, transaction type and limits. AffixIO can verify that fit and return signed evidence while the consent record remains in the customer's system. AffixIO is designed for privacy-preserving verification. The customer keeps source records, account context, consent evidence and policy data. AffixIO verifies the proof path and returns signed evidence that another system can use without receiving a full identity dossier. ### Verification flow - 01 Capture consent Record the user's bounded approval in the customer system. - 02 Reference consent Use a consent_ref rather than exposing the raw consent record. - 03 Verify fit Check action, amount, merchant, expiry and policy version. - 04 Return evidence Store signed result and proof_id for audit or dispute review. ### Direct answers Answers about approval scope, record ownership and revocation. ### How is user consent captured with agent transactions? The customer system, wallet or merchant captures consent. AffixIO verifies whether the proposed agent action fits that stored consent. ### What can consent include? Consent can include amount ceiling, merchant, merchant category, product class, geography, wallet session, expiry, account and permitted action type. ### Can consent be revoked? Yes. Revocation remains in the customer system or wallet. A later verification can deny actions that no longer fit the active consent state. ### Continue the verification path Related AffixIO pages for agent identity, consent, checkout, issuer checks, SDKs and evidence pipelines. - Agentic Payment Verification - Agent Verification - Issuer Agent Consent - Agentic Pay - Compliance AI agent verification resources ### The proof-before-action pathway Start with the explanation of what it means for an AI agent to be verified before a transaction, then follow the implementation path for consent, spending limits, checkout and signed evidence. ## Verify AI Agents at Checkout: Merchant Integration Guide | AffixIO Source: https://www.affix-io.com/verified-agent-checkout/ Merchant checkout ### How merchants verify AI agents at checkout A verified agent checkout is a checkout where the agent, user mandate and purchase context are checked before the order is accepted. ### Before checkout AffixIO verifies the action before the merchant treats it as an authorized user decision. ### For marketplaces Marketplaces can check agent permission before inventory is reserved, sellers are notified or a paid order is created. ### Where to put the check in your checkout Place the permission check on the server before the action it controls. Do not rely on an agent-supplied claim, a browser badge or a successful check for an earlier basket. The merchant must decide which issuers and evidence it accepts. - Resolve the actor and authority. Authenticate the request and retrieve the current user mandate. A recognised bot identity is not a spending mandate. - Build the final transaction intent. Include the merchant, basket, total including tax and delivery, currency and any recurring commitment. - Evaluate the exact intent. Check scope, expiry, revocation and remaining allowance against that transaction, using the supported verification integration. - Enforce the outcome. Proceed only when the required checks permit it. A denial stops the action; an unresolved result needs the application's review or retry process. - Request payment authorisation. The payment provider still performs its own checks. A successful permission check is not a successful payment. - Retain the evidence reference. Link the decision to the order and payment attempt so support can reconstruct what happened. ### Test the cases that break a happy-path demo - Basket changes after approval: check the revised intent before submitting payment. - The same request arrives twice: use your checkout's idempotency and order-state controls to prevent duplicate charges. - Two purchases race for one allowance: reserve or consume allowance atomically in the system that owns it. Two independent successful checks must not imply two spending allowances. - Verification times out: do not turn a network failure into an allow decision. - Payment fails after verification: retain separate verification and payment states. A proof does not mean an order was paid. These are merchant implementation responsibilities, not a claim that installing an SDK supplies an entire checkout. Start with bounded user consent , review the AffixIO SDK , and use the Agentic Pay Kit documentation for the supported integration. ### Where AffixIO fits AffixIO sits before the action. It helps your application ask whether the user, agent or delegated workflow is allowed to continue, then returns a decision your product can enforce. ### For subscriptions SaaS teams can verify plan changes, renewals, paid add-ons and usage increases triggered by agents. ### For commerce Retailers can check product category, basket value, return risk and user consent before fulfillment. ### For APIs API platforms can verify paid tool calls before compute, data access or downstream cost is triggered. ### For disputes Signed outcomes make later review clearer than a screenshot of an agent chat. ### For privacy The source record does not need to become a new permanent merchant database. ### Designed for buyers who need trust without data sprawl Use AffixIO when a checkout, platform, marketplace, API, internal tool or AI agent needs a clear permission result, signed evidence and a cleaner privacy posture. The value is not another dashboard full of personal records. The value is a decision with proof behind it. ### Questions this page answers Answers about verification, payment authorisation and implementation. It is a checkout flow that checks whether an AI agent is allowed to complete a purchase for the user before the order is accepted. Merchants, marketplaces, SaaS platforms, API providers and financial workflows that expect AI agents to trigger paid actions. A decision your application can enforce, plus evidence for audit and support review. ### Put a proof step before the risky action. Start with the SDK, map the decision you need and connect the result to the place your product already enforces access, checkout or policy. ## AI Agent Verification: Identity, Consent and Permission Checks | AffixIO Source: https://www.affix-io.com/agent-verification/ AI agent verification ### Know which agent is acting and why. AffixIO verifies agent identity and delegated authority before high-value actions such as payments, paid API calls, account changes, bookings, renewals and tool execution. ### What this page answers An AI agent is verified when the system can show which agent is acting, who or what authorised it, what scope applies, and whether the current action fits policy. AffixIO turns that check into a signed yes or no decision. AffixIO is designed for privacy-preserving verification. The customer keeps source records, account context, consent evidence and policy data. AffixIO verifies the proof path and returns signed evidence that another system can use without receiving a full identity dossier. ### Verification flow - 01 Identify the agent Bind the tool runner, wallet agent, buying agent or orchestration process to an agent_ref. - 02 Bind authority Reference consent, mandate or delegated policy scope. - 03 Check the action Compare the current action with the allowed scope. - 04 Attest the result Use a signed decision and audit digest as portable evidence. ### Direct answers Concise answers for search, procurement, engineering and agent retrieval. ### What does it mean for an AI agent to be verified? It means the agent is recognised, bound to a current user or business intent, checked against policy, and linked to auditable evidence. ### What identifiers matter? Common references include agent_ref, subject_ref, consent_ref, policy_version, circuit_id, nonce, timestamp and proof_id. ### Can this work without exposing PII? Yes. Source records stay with the customer. AffixIO receives proof material and returns a signed decision. ### Continue the verification path Related AffixIO pages for agent identity, consent, checkout, issuer checks, SDKs and evidence pipelines. - Agentic Payment Verification - Ai Agent Consent - Mcp - Developers - Webhooks ## BoundProof Agent docs | Agent area, API key and Hub code | AffixIO Source: https://www.affix-io.com/docs/boundproof-agent/ BoundProof Agent docs ### Give every agent its own AffixIO area. BoundProof Agent provisions a private agent namespace, an agent-only API key and a Hub handoff code. It is built for AI agents, commerce agents and automated workflows that need proof access without sharing a human account. ``` { "agent_id": "uuid", "api_key": "aio_...", "api_base": "https://api.affix-io.com", "own_area_id": "area_uuid" } ``` What changed ### BoundProof Agent adds isolated agent access to AffixIO. Each visiting agent can receive its own area. The API key created for that agent is tied to its agent_id and own_area_id. Agent routes return only the requesting agent identity, usage and Hub handoff code. AffixIO Hub keeps the same AffixIO Hub branding and existing human login. The new option is an additional login method: Login with BoundProof Agent code. A valid BP code opens a Hub session scoped to that agent's own area only. Flow ### From agent visit to Hub handoff. ### Agent visits The agent opens /boundproof/agent/ . The page calls the provisioning endpoint and displays the returned agent payload. ### API key is issued The API creates an agent-only key with an allowed agent route scope. The key is not a human Hub password and is not a general admin token. ### Agent checks itself The agent calls its identity and usage routes. Responses are filtered to the requesting agent_id. ### Hub code is generated The agent asks for a single-use BP code. The code lasts ten minutes and can be used once. ### Human opens Hub A human enters the BP code in AffixIO Hub. The session opens only the linked agent area. Browser agents ### A browser can be the BoundProof Agent surface, with limits. A browser can act as a BoundProof Agent when it is the controlled runtime for an agent workflow, such as a signed-in assistant, browser extension, automation runner, supervised computer-use session or merchant-hosted checkout assistant. BoundProof Agent binds that runtime to an agent_id and own_area_id , then limits what it can see and do through scoped agent routes. This does not mean every browser tab is trusted. A normal anonymous visit is only a visit. The safer pattern is that the browser prepares an intent, consent or action request, then a trusted same-origin backend, extension host, MCP server or controlled runtime calls AffixIO before the action continues. Keep merchant SDK keys, payment secrets and shared verification secrets out of public browser JavaScript. The evidence is the scoped BoundProof Agent area and signed AffixIO decision, not the browser by itself. API endpoints ### Agent routes now available. Method | Endpoint | Purpose | Auth POST | /v1/boundproof/agent/provision | Create agent_id, own_area_id and agent-only API key. | Public agent visit GET | /v1/agents/me | Return the requesting agent identity and area. | Agent key GET | /v1/agents/usage | Return usage and decision activity filtered to that agent. | Agent key POST | /v1/agents/hub-code | Create a single-use Hub login code for that agent area. | Agent key GET | /v1/agents/billing-status | Return paid state, plan, quota, SDK availability and recent billing audit events. | Agent key POST | /v1/agents/checkout | Create agent API PaymentIntent / confirm with pm_, or optional hosted Checkout. Agent self-serve supported. | Agent key POST | /v1/agents/checkout/confirm | Confirm incomplete agent subscription PaymentIntent with Stripe payment_method (pm_…). Backend only - no Hub UI. | Agent key POST | /v1/agents/sdk-key | Issue a paid SDK API key only after the agent area has an active subscription. | Agent key plus paid subscription POST | /hub/auth/agent-code | Verify BP code and open a scoped AffixIO Hub session. | Single-use BP code Runnable shape ### Provision, inspect and generate a Hub code. The agent starts with a provision call. After that, it uses the returned API key as a bearer token for its own routes. The Hub code is for handoff, not for broad account access. ``` const provision = await fetch( "https://api.affix-io.com/v1/boundproof/agent/provision", { method: "POST" } ).then((res) => res.json()); const me = await fetch(provision.api_base + "/v1/agents/me", { headers: { Authorization: "Bearer " + provision.api_key } }).then((res) => res.json()); const hub = await fetch(provision.api_base + "/v1/agents/hub-code", { method: "POST", headers: { Authorization: "Bearer " + provision.api_key } }).then((res) => res.json()); const checkout = await fetch(provision.api_base + "/v1/agents/checkout", { method: "POST", headers: { "Content-Type": "application/json", Authorization: "Bearer " + provision.api_key }, body: JSON.stringify({ plan_tier: "Starter", payer_type: "agent", payer_acknowledgement: "agent_authorized_subscription", mode: "api" }) }).then((res) => res.json()); ``` Paid access ### Agents can complete paid proof access via API without a human Checkout click. ### Starter plan BoundProof Agent paid access uses the existing AffixIO Starter plan, currently published at £19 per month where GBP checkout is available. ### Strict payment rule Agent path: payer_type agent, payer_acknowledgement agent_authorized_subscription, mode api|confirm with a Stripe pm_…. Human path: payer_type human + hosted Checkout still works. ### No silent charges Agents confirm with a Stripe payment_method id (pm_…) via /v1/agents/checkout/confirm. AffixIO never accepts raw card numbers. Hosted Checkout remains available when preferred. ### SDK key entitlement Provisioning returns a bpa_ agent key for agent routes. POST /v1/agents/sdk-key issues an SDK key when the agent billing owner has a valid licensed trial or subscription. Check /v1/agents/billing-status for entitlement and SDK-key availability; an unpaid trial can still be licensed. ### Status and audit /v1/agents/billing-status shows paid state, current plan, quota, renewal date and recent audit events such as checkout_requested and sdk_key_issued. AffixIO Hub ### Hub stays human-friendly and agent scoped. ### Existing login remains Email, password and human BoundProof login continue to work as before. BoundProof Agent does not replace human registration. ### New login option AffixIO Hub adds Login with BoundProof Agent code. The code format is BP-XXXX-XXXX. ### Scoped dashboard When the session comes from an agent code, Hub shows the linked agent's own area data instead of general account data. Answers ### Questions agents and developers ask. No. Human BoundProof still proves a browser-held credential for a Hub user. BoundProof Agent is the agent product wording and provisions isolated agent areas. No. A BP code is single-use and expires after ten minutes. Reuse returns an invalid agent code response. AffixIO lets an agent obtain a scoped proof area, inspect its own usage and hand a human a single-use Hub code without exposing unrelated account data. Yes, when the browser is a controlled agent runtime such as a signed-in assistant, extension, automation runner, supervised computer-use session or merchant-hosted checkout assistant. It is not a claim that every anonymous tab is trusted. Keep merchant SDK keys and payment secrets out of public browser JavaScript; use a trusted same-origin backend, extension host, MCP server or controlled runtime for AffixIO calls. ### Agent API payment flow This flow uses api.affix-io.com for BoundProof Agent at /boundproof/agent/. It is separate from boundproof.affix-io.com. - Provision once, store the agent identity and use its key as a Bearer token. - Check billing-status. A valid licensed trial also permits SDK-key issuance. - POST /v1/agents/checkout with payer_type agent, payer_acknowledgement agent_authorized_subscription and mode api. - Use the returned subscription_id and payment_intent_id with an authorized payment_method token at POST /v1/agents/checkout/confirm. - Handle authentication_required or payment_incomplete. Creating the subscription does not establish successful payment. - Check billing-status for entitlement. Store any issued SDK key securely. Hub access remains optional. Human payers use payer_type human, payer_acknowledgement human_authorized_payment and mode hosted. Agents can also choose hosted Checkout. Never submit raw card numbers to AffixIO or create another subscription merely to retry an incomplete payment. ## Free IBAN Validator | Check Format and Checksum | AffixIO Source: https://www.affix-io.com/iban-validator/ Public tool ### Free IBAN validator Type any IBAN. IBAN Validator checks the country format and runs the MOD-97-10 checksum that every valid bank account number must satisfy, entirely in your browser, then asks the live AffixIO API for a signed yes or no. - No API key - Local format and checksum checks - Signed with ML-DSA-65 ### IBAN to validate Type or paste any IBAN. Spaces are ignored. The check is instant and runs entirely in your browser. AffixIO proof Stamped by the live AffixIO API and signed with ML-DSA-65, the FIPS 204 post-quantum algorithm. Nothing personal goes into the payload. ### How to use it Three moves, no sign-up. 1 ### Type an IBAN Paste or type any International Bank Account Number. Spaces are ignored. 2 ### Press Validate The tool checks the country format and runs the MOD-97-10 checksum that every valid IBAN must satisfy. It runs entirely in your browser. 3 ### Read the verdict A YES means the format and checksum both pass. A NO tells you which check failed, with a signed proof from the live AffixIO API. ### What you are looking at An IBAN is an International Bank Account Number. Every country has a fixed format: a two-letter country code, two check digits, and a country-specific length for the rest of the number. The MOD-97-10 checksum is the international standard. The number is rearranged, letters are converted to digits, and the remainder when divided by 97 must equal one. Every valid IBAN in the world satisfies this. The proof card shows the answer stamped by the live AffixIO API: a proof id, an audit id, the policy version, and an ML-DSA-65 signature over the payload digest. ### Questions ### Do I need an API key? No. The validation runs entirely in your browser. The signed verdict uses a throwaway demo key that the page requests from the live AffixIO API on its own. ### Does this check the bank or account exists? No. It checks that the number is correctly formed and has a valid checksum. It does not contact any bank. ### Which countries are supported? The checker uses a built-in country-length table. A country absent from that table is reported as unsupported. It does not query the current IBAN registry or a bank directory. ### What does the proof card show? The answer stamped by the live AffixIO API: a proof id, an audit id, the policy version, and an ML-DSA-65 signature over the payload digest. Browse all tools How AffixIO works Pricing ### IBAN validation is not account verification This checker answers a narrow question: does the value have the expected structure, a supported country length and a valid MOD-97 checksum? A passing result does not establish that the account exists, belongs to a named person, accepts payments or is safe to pay. The format and checksum are checked locally. Requesting the signed AffixIO result makes a network call with the check outcomes and country code; the tool does not send the full IBAN in that request. A signature records the evaluated outcome, not a bank's confirmation. ### Try these format examples These are published-style validation examples for testing the checker. Do not send money to them. Country | Example IBAN | Length Germany | DE89 3704 0044 0532 0130 00 | 22 United Kingdom | GB29 NWBK 6016 1331 9268 19 | 22 Netherlands | NL91 ABNA 0417 1643 00 | 18 ### Why can a check fail? Common causes include missing characters, a mistyped check digit, punctuation, a country-length mismatch or a country absent from this tool's reference table. Spaces and letter case are normalised. An unsupported country is not evidence that a real bank account is invalid. SWIFT maintains the official IBAN registry . Consult that registry for current country formats; this tool does not perform a live bank-directory lookup. ### Record the result in your own application For a wider verification workflow, connect your authorised data source , evaluate a defined condition and retain signed evidence with the AffixIO SDK . See the other public tools for demonstrations with different data scopes. ## Public page directory Each entry links to a full public page. Regional examples retain their documented scope. - [AffixIO | Verify Records, Eligibility and Agent Permissions](https://www.affix-io.com/) - [A-Level results day | UCAS points and offer check | AffixIO](https://www.affix-io.com/a-level/) - [Age verification UK | 13+, 16+, 18+ gate | AffixIO](https://www.affix-io.com/age-pass/) - [Age Verification API | AffixIO](https://www.affix-io.com/age-verification-api/) - [Agent Guard | Free npm guard for LLM tool calls | AffixIO](https://www.affix-io.com/agent-guard/) - [AI Agent Safety | Verify autonomous agents before they act | AffixIO](https://www.affix-io.com/agent-safety/) - [Know Your Agent (KYA) | AI agent governance and identity | AffixIO](https://www.affix-io.com/agent-trust/) - [How Are AI Agents Verified Before Payments? | AffixIO](https://www.affix-io.com/agent-verification-explained/) - [AI Agent Verification: Identity, Consent and Permission Checks | AffixIO](https://www.affix-io.com/agent-verification/) - [Agentic Commerce Demo | AffixIO](https://www.affix-io.com/agentic-commerce-demo/) - [Agentic Commerce Optimization | Make AI shopping traffic executable | AffixIO](https://www.affix-io.com/agentic-commerce-optimization/) - [Agentic Commerce Risk Management | AffixIO](https://www.affix-io.com/agentic-commerce-risk-management/) - [Agentic Pay Kit | AI agent payments SDK for AP2, x402 and MCP | AffixIO](https://www.affix-io.com/agentic-pay-kit/) - [Agentic Pay | Real agentic checkout with AffixIO proofs | AffixIO](https://www.affix-io.com/agentic-pay/) - [Agentic Payment Verification | AffixIO](https://www.affix-io.com/agentic-payment-verification/) - [Agentic Payments for Marketplaces | AffixIO](https://www.affix-io.com/agentic-payments-for-marketplaces/) - [Agentic Payments vs AI Payments | What is the difference? | AffixIO](https://www.affix-io.com/agentic-payments-vs-ai-payments/) - [Agentic Payments | AffixIO](https://www.affix-io.com/agentic-payments/) - [Agentic demo: proof before the LLM | AffixIO](https://www.affix-io.com/agenticdemo/) - [AI Agent Checkout for Merchants | AffixIO](https://www.affix-io.com/ai-agent-checkout-for-shopify/) - [AI Agent Transaction Consent: Capture, Scope & Revocation | AffixIO](https://www.affix-io.com/ai-agent-consent/) - [AI Agent Identity | AffixIO](https://www.affix-io.com/ai-agent-identity/) - [AI agent payment risk and checkout permission checks | AffixIO](https://www.affix-io.com/ai-agent-payment-risk/) - [AI Agent Permissions | AffixIO](https://www.affix-io.com/ai-agent-permissions/) - [AI Agent Spending Limits | Control autonomous purchasing | AffixIO](https://www.affix-io.com/ai-agent-spending-limits/) - [AI Agent Verification for Payment Providers | AffixIO](https://www.affix-io.com/ai-agent-verification-for-payment-providers/) - [AI Commerce | AffixIO](https://www.affix-io.com/ai-commerce/) - [AI hackathon | Break the rules, get a signed receipt | AffixIO](https://www.affix-io.com/ai-hackathon/) - [AI Shopping Agent Checkout | Accept agents without accepting abuse | AffixIO](https://www.affix-io.com/ai-shopping-agent-checkout/) - [AffixIO Answers | AI agent verification and agentic payments FAQ](https://www.affix-io.com/answers/) - [AP2 Payment Mandates: Agent Consent and Checkout Verification | AffixIO](https://www.affix-io.com/ap2-payment-mandates/) - [One-time PQC ballot demo | ML-DSA-65 | AffixIO](https://www.affix-io.com/ballot-pass/) - [AffixIO Blog | Eligibility, verification and compliance guides](https://www.affix-io.com/blog/) - [Inside a Stateless Post-Quantum Verification Node: SDK Notes for Developers | AffixIO Blog](https://www.affix-io.com/blog/affixio-stateless-post-quantum-verification-node/) - [AffixIO vs hosted IDV bureaus | AffixIO Blog](https://www.affix-io.com/blog/affixio-vs-hosted-idv-bureaus/) - [Age assurance UK: what the law actually requires | AffixIO Blog](https://www.affix-io.com/blog/age-assurance-uk-what-the-law-requires/) - [When AI Agents Shop Alone: Where Verification Breaks | AffixIO Blog](https://www.affix-io.com/blog/agentic-agents-shopping/) - [Agentic Verification | AffixIO Blog](https://www.affix-io.com/blog/agentic-verification/) - [Airline passenger data security: where operators sit after the MAG breach | AffixIO Blog](https://www.affix-io.com/blog/airline-passenger-data-security-uk-airports/) - [Black Friday checkout pressure, without another ID warehouse | AffixIO Blog](https://www.affix-io.com/blog/black-friday-checkout-pressure/) - [How AffixIO Keeps Eligible Traffic Flowing at Peak | AffixIO Blog](https://www.affix-io.com/blog/how-affixio-helps-traffic/) - [A worked example: KYC eligibility without building a PII warehouse | AffixIO Blog](https://www.affix-io.com/blog/kyc-eligibility-without-pii-warehouse/) - [Marketplace Seller Verification, in the UK | AffixIO Blog](https://www.affix-io.com/blog/marketplace-seller-verification/) - [ML-DSA-65 vs ECDSA: what post-quantum attestation changes for verifiers | AffixIO Blog](https://www.affix-io.com/blog/ml-dsa-65-vs-ecdsa-post-quantum-attestation/) - [How offline-proof queues keep a signed yes/no during an outage | AffixIO Blog](https://www.affix-io.com/blog/offline-proof-queues-signed-yes-no-outage/) - [Platform scale: 115 circuits, 1,547 Merkle leaves, and what we publish on uptime | AffixIO Blog](https://www.affix-io.com/blog/platform-scale-circuits-merkle-leaves-and-uptime/) - [Privacy-preserving eligibility: why the record should never leave your host | AffixIO Blog](https://www.affix-io.com/blog/privacy-preserving-eligibility-record-never-leaves-host/) - [Right to rent and right to work: API migration guides | AffixIO Blog](https://www.affix-io.com/blog/right-to-rent-right-to-work-api-migration/) - [SDK throughput and test results, August 2026 | AffixIO Blog](https://www.affix-io.com/blog/sdk-throughput-and-test-results-august-2026/) - [BoundProof vs traditional logs | Privacy preserving proof evidence | AffixIO](https://www.affix-io.com/boundproof-vs-traditional-logs/) - [BoundProof | How AffixIO proves access without showing who | AffixIO](https://www.affix-io.com/boundproof/) - [BoundProof Agent | Auto Provision an Isolated Agent Area | AffixIO](https://www.affix-io.com/boundproof/agent/) - [Card Validator | Real-time payment card validation | AffixIO](https://www.affix-io.com/card-validator/) - [Careers | AffixIO](https://www.affix-io.com/careers/) - [Claim hash and subject_ref | Claim Desk | AffixIO](https://www.affix-io.com/claim-desk/) - [ULEZ and clean air zone check | AffixIO Clean Air Pass](https://www.affix-io.com/clean-air/) - [UK security clearance levels | SC, DV, BPSS | AffixIO](https://www.affix-io.com/clearance-pass/) - [AffixIO vs KYC for AI agents | Permission proof before action](https://www.affix-io.com/compare/affixio-vs-kyc-for-agents/) - [Agent verification vs bot detection | AffixIO](https://www.affix-io.com/compare/agent-verification-vs-bot-detection/) - [AffixIO vs Persona | AI Agent Trust Infrastructure](https://www.affix-io.com/compare/persona/) - [AffixIO vs Stripe Identity | AI Agent Trust Infrastructure](https://www.affix-io.com/compare/stripe-identity/) - [AffixIO vs Traditional KYC | AI Agent Trust Infrastructure](https://www.affix-io.com/compare/traditional-kyc/) - [AffixIO vs Veriff | AI Agent Trust Infrastructure](https://www.affix-io.com/compare/veriff/) - [AffixIO vs World ID | AI Agent Trust Infrastructure](https://www.affix-io.com/compare/world-id/) - [Compliance | AffixIO](https://www.affix-io.com/compliance/) - [AffixIO connections | SDKs, API, MCP, webhooks, edge](https://www.affix-io.com/connections/) - [Contact | AffixIO](https://www.affix-io.com/contact/) - [AffixIO and CISA | Secure by Design and quantum readiness](https://www.affix-io.com/csia/) - [Currency Gate | Convert at official ECB rates, anywhere | AffixIO](https://www.affix-io.com/currency-gate/) - [UK fuel prices and forecourt proof | Strait Pass | AffixIO](https://www.affix-io.com/demo-strait/) - [AffixIO API and SDK | Developer Quick Start](https://www.affix-io.com/developers/) - [AffixIO SDK docs | Install, prove, adapters, CLI | AffixIO](https://www.affix-io.com/docs/) - [BoundProof Agent docs | Agent area, API key and Hub code | AffixIO](https://www.affix-io.com/docs/boundproof-agent/) - [External Data Verification | SQL, JSON and API Checks | AffixIO](https://www.affix-io.com/docs/external-data-sources/) - [Doomsday Cinema | Monitor your multiplex with the affixio SDK | AffixIO](https://www.affix-io.com/doomsday-cinema/) - [MOT, tax and ULEZ check | Drive or do not drive | AffixIO](https://www.affix-io.com/drive-pass/) - [Edge Audit | Prove eligibility without sending PII | AffixIO](https://www.affix-io.com/edge-audit/) - [Email Verification Gate | Real-time email validation | AffixIO](https://www.affix-io.com/email-verification-gate/) - [AffixIO Examples | AI agent verification examples](https://www.affix-io.com/examples/) - [Mortgage and motor finance eligibility | Finance Gate](https://www.affix-io.com/finance-gate/) - [For Agents: AffixIO citation & AIO reference | AffixIO](https://www.affix-io.com/for-agents/) - [Free AffixIO Proofs | Agents 150 · Humans 100 | No Card](https://www.affix-io.com/free-proofs/) - [Glossary | AffixIO](https://www.affix-io.com/glossary/) - [Agentic Payments | AffixIO Glossary](https://www.affix-io.com/glossary/agentic-payments/) - [Ai Agent Identity | AffixIO Glossary](https://www.affix-io.com/glossary/ai-agent-identity/) - [Autonomous Commerce | AffixIO Glossary](https://www.affix-io.com/glossary/autonomous-commerce/) - [Delegated checkout meaning | AffixIO glossary](https://www.affix-io.com/glossary/delegated-checkout/) - [Machine Identity | AffixIO Glossary](https://www.affix-io.com/glossary/machine-identity/) - [Permission Layer | AffixIO Glossary](https://www.affix-io.com/glossary/permission-layer/) - [Proof Infrastructure | AffixIO Glossary](https://www.affix-io.com/glossary/proof-infrastructure/) - [Transaction intent proof meaning | AffixIO glossary](https://www.affix-io.com/glossary/transaction-intent-proof/) - [Trust Layer | AffixIO Glossary](https://www.affix-io.com/glossary/trust-layer/) - [Zero Knowledge Verification | AffixIO Glossary](https://www.affix-io.com/glossary/zero-knowledge-verification/) - [Grok Bot Agent Payments | Verify cloud agents before spend | AffixIO](https://www.affix-io.com/grok-bot-agent-payments/) - [AffixIO Growth Strategy | Trust Layer for AI Agents](https://www.affix-io.com/growth-strategy/) - [Holiday Pass | Public holidays for around 110 countries | AffixIO](https://www.affix-io.com/holiday-pass/) - [How it Works | AffixIO](https://www.affix-io.com/how-it-works/) - [AffixIO Hub | Keys, Merkle audit, BoundProof](https://www.affix-io.com/hub/) - [Free IBAN Validator | Check Format and Checksum | AffixIO](https://www.affix-io.com/iban-validator/) - [Integrations | AffixIO](https://www.affix-io.com/integrations/) - [Issuer AI Agent Consent Checks | AffixIO](https://www.affix-io.com/issuer-agent-consent/) - [KYC API | AffixIO](https://www.affix-io.com/kyc-api/) - [Machine Payments Protocol | Verify machine payments before spend | AffixIO](https://www.affix-io.com/machine-payments-protocol/) - [MCP Security | Verify AI agent tool calls before they run | AffixIO](https://www.affix-io.com/mcp-security/) - [Merchant AI Agent Checkout Verification | AffixIO](https://www.affix-io.com/merchant-agent-checkout/) - [Merchant Agent Readiness Review | AffixIO](https://www.affix-io.com/merchant-agent-readiness-review/) - [Merchant agent readiness checklist for AI shopping and agentic payments | AffixIO](https://www.affix-io.com/merchant-agent-readiness/) - [Platform metrics | Circuits, audit scale, latency and uptime | AffixIO](https://www.affix-io.com/metrics/) - [AI model usage policy gate | Allow or deny | AffixIO](https://www.affix-io.com/model-gate/) - [UK benefits pathway demo | Money Help Pass | AffixIO](https://www.affix-io.com/money-help/) - [Muse AI Agent Payments | Proof before personal agents spend | AffixIO](https://www.affix-io.com/muse-ai-agent-payments/) - [AffixIO and NCSC | PQC, zero trust, data minimisation](https://www.affix-io.com/ncsc/) - [AffixIO and NIST | FIPS 204 yes, FIPS 140-3 not claimed](https://www.affix-io.com/nist/) - [Password Strength Gate | Real-time password check against breach data | AffixIO](https://www.affix-io.com/password-strength-gate/) - [Free MOT check and vehicle tax | Plate Pass | AffixIO](https://www.affix-io.com/plate-pass/) - [Plate Pass privacy policy | AffixIO Chrome extension](https://www.affix-io.com/plate-pass/privacy/) - [Platform | AffixIO](https://www.affix-io.com/platform/) - [ML-DSA-65 explained | PQC Gauge | AffixIO](https://www.affix-io.com/pqc-gauge/) - [AffixIO pricing | SDK, Agentic Pay Kit and proof quotas](https://www.affix-io.com/pricing/) - [Privacy Preserving Verification | AffixIO](https://www.affix-io.com/privacy-preserving-verification/) - [Product | AffixIO](https://www.affix-io.com/product/) - [AffixIO Proof Library | Signed decisions, Merkle records and agent mandates](https://www.affix-io.com/proof-library/) - [Quake Watch | Live seismic map | AffixIO](https://www.affix-io.com/quake-watch/) - [Right to rent check demo | Right to work | AffixIO](https://www.affix-io.com/rent-pass/) - [Right to rent and right to work gate | AffixIO Right Pass](https://www.affix-io.com/right-pass/) - [Road legal check | MOT, tax and insurance | AffixIO](https://www.affix-io.com/road-legal/) - [AffixIO Python client | API, webhooks, Merkle](https://www.affix-io.com/sdk-python/) - [AffixIO SDK request builder | Agent checkout and permission payloads](https://www.affix-io.com/sdk-request-builder/) - [AffixIO in the browser | Light verify, no WASM prover](https://www.affix-io.com/sdk-web/) - [AffixIO SDK 2.0.0 beta for Node.js | Local Proofs and Verification](https://www.affix-io.com/sdk/) - [AffixIO SDK Proof Modes | UltraHonk and HMAC Compared](https://www.affix-io.com/sdks/) - [Security | AffixIO](https://www.affix-io.com/security/) - [Broadband down? Activation or compensation | AffixIO](https://www.affix-io.com/service-check/) - [Plex Pass vs Jellyfin | Household eligibility | AffixIO](https://www.affix-io.com/shelf-pass/) - [SIEM evidence export | AffixIO NDJSON events](https://www.affix-io.com/siem/) - [Industry solutions | Banking, gambling, recruitment, government | AffixIO](https://www.affix-io.com/solutions/) - [AI model policy gate | Enterprise agent permissions | AffixIO](https://www.affix-io.com/solutions/ai-and-enterprise/) - [Banking eligibility verification | KYC gates without a PII warehouse | AffixIO](https://www.affix-io.com/solutions/banking/) - [University admissions eligibility | UCAS points and academic gates | AffixIO](https://www.affix-io.com/solutions/education-and-admissions/) - [Gambling age verification UK | 18+ gates and venue admission | AffixIO](https://www.affix-io.com/solutions/gambling-age-gating/) - [Government eligibility verification | Benefits and clearance gates | AffixIO](https://www.affix-io.com/solutions/government/) - [Hotel check-in verification | Hospitality eligibility gates | AffixIO](https://www.affix-io.com/solutions/hospitality/) - [Marketplace seller verification | Trust and safety eligibility | AffixIO](https://www.affix-io.com/solutions/marketplaces/) - [Fleet compliance verification | MOT, ULEZ and road legal gates | AffixIO](https://www.affix-io.com/solutions/motoring-and-logistics/) - [Recruitment eligibility | Right to work verification API | AffixIO](https://www.affix-io.com/solutions/recruitment/) - [Broadband compensation eligibility | Telecom service gates | AffixIO](https://www.affix-io.com/solutions/telecom-and-connectivity/) - [Travel eligibility verification | Passport and visa gates | AffixIO](https://www.affix-io.com/solutions/travel-and-aviation/) - [Hotel check-in eligibility | Stay Pass | AffixIO](https://www.affix-io.com/stay-pass/) - [Sun Gate | Midday UV check for anywhere on Earth | AffixIO](https://www.affix-io.com/sun-gate/) - [Anti-scalping ticket gate | Rotating QR | AffixIO](https://www.affix-io.com/ticket-pass/) - [Time Gate | Is it a good time to call, anywhere on Earth | AffixIO](https://www.affix-io.com/time-gate/) - [AffixIO tools | Identity, eligibility and agent verification](https://www.affix-io.com/tools/) - [Ohme Partner | Free EV charger claims without PII | AffixIO](https://www.affix-io.com/tools/ohme-partner/) - [UK travel advice, ETA and passport gates | Travel Pass](https://www.affix-io.com/travel-pass/) - [AffixIO Trust Centre | Security, privacy and verification posture](https://www.affix-io.com/trust/) - [Use Cases | AffixIO](https://www.affix-io.com/use-cases/) - [Agentic checkout fraud prevention | AffixIO](https://www.affix-io.com/use-cases/agentic-checkout-fraud/) - [API tool call permission checks for AI agents | AffixIO](https://www.affix-io.com/use-cases/api-tool-call-permission/) - [Delegated payment consent checks | AffixIO](https://www.affix-io.com/use-cases/delegated-payment-consent/) - [Marketplace agent verification | AffixIO](https://www.affix-io.com/use-cases/marketplace-agent-verification/) - [SaaS agent billing controls | AffixIO](https://www.affix-io.com/use-cases/saas-agent-billing-controls/) - [VAT Number Validator | Real-time tax ID validation for 100+ countries | AffixIO](https://www.affix-io.com/vat-number-validator/) - [Verify AI Agents at Checkout: Merchant Integration Guide | AffixIO](https://www.affix-io.com/verified-agent-checkout/) - [Visa Trusted Agent Protocol | Merchant proof for AI commerce | AffixIO](https://www.affix-io.com/visa-trusted-agent-protocol/) - [AffixIO webhooks | HMAC-SHA256 signed events](https://www.affix-io.com/webhooks/) - [x402 Payment Verification | Proof before HTTP 402 agent payments | AffixIO](https://www.affix-io.com/x402-payment-verification/) - [Yacht deposit pre-register | Open Banking demo | AffixIO](https://www.affix-io.com/yacht/) - [Jaz | Recursive AI Agent Harness Demo & Research | AffixIO](https://www.affix-io.com/jaz/) - [Skill Lab: verifiable workflows for AI agents | AffixIO](https://www.affix-io.com/skill-lab/) - [Agent assurance research: verifiable AI actions and evidence | AffixIO](https://www.affix-io.com/research/agent-assurance/) ## AffixIO SDK 2.0 beta canonical release metadata Stable install: npm install affixio. Beta install: npm install affixio@beta. Current beta: affixio 2.0.0-beta.1. Minimum runtime for new public docs: Node.js 20 or later. Canonical npm package: https://www.npmjs.com/package/affixio. Legacy package names: @affix-io/sdk and @affix-io/sdk-light are not the recommended public install path for new work. If an index shows a scoped 2.x package, treat it as legacy or ambiguous until AffixIO confirms otherwise. Product sentence: AffixIO sits before the action and proves whether an agent should be allowed to act. KYA definition: Authentication asks who is calling. Know Your Agent asks whether this agent is allowed to do this, here, now. Feature truth: package capability, licence entitlement and remote service availability are separate. A feature may be present in the SDK, enabled only for some plans, or require api.affix-io.com for verification, attestation or Merkle audit. Local-only licence mode: private data stays on the customer host, policy and proof work runs locally, and AffixIO receives only the entitlement check required for the selected workflow. Connected verification mode: the host submits the approved verification payload to AffixIO for remote verification, ML-DSA-65 attestation or Merkle audit where enabled. Read next: https://www.affix-io.com/sdk-2-beta/ and https://www.affix-io.com/docs/migration-2-0/.