The kyaLabs Trust Constitution

Agents Are Not Bots

For twenty years, merchants built an arms race against bots. CAPTCHAs, device fingerprinting, behavioral analysis, IP reputation, rate limiting — billions of dollars answering one question: "Is this a human?"

It was the right question. Until now.

Because now there's a third category. Not human. Not bot. Something new: an authorized actor — trusted by a real person, acting on their behalf, with explicit consent, for a specific purpose, for a limited time.

kyaLabs is the proof that your agent is not a bot. Not by fighting the merchant's defenses. Not by bypassing their bot detection. By giving your agent a way to declare what it is: an authorized actor, not anonymous traffic.

kyaLabs is K.Y.A. infrastructure — Know Your Agent. The verification layer that answers: Who is this agent acting for? What does it intend to do? Is it authorized to do it?

---

Our Commitments

• Human-in-the-loop authorization at every step. Every agent action kyaLabs enables carries a declared intent and explicit human approval — aligned to merchant standards as they evolve.
• No bypass. No workarounds. Ever. kyaLabs does not promote, enable, or tolerate bot bypass, credential stuffing, or any workaround to merchant access controls. We prove identity — we don't circumvent defenses.
• Fintech-grade user security. Every user on kyaLabs is protected by the same security standards applied to regulated financial products. No exceptions.
• Your data is yours. We do not use user data for marketing purposes. We do not sell data in any form, to anyone, for any reason.
• Your consent defines our data. kyaLabs only tracks events tied to scopes you explicitly opted into. The identity declaration is the consent boundary — without it, nothing is recorded. No ambient tracking. No background collection. No orphan events.

---

K.Y.A. — Know Your Agent

K.Y.A. is the framework for verifying AI agent identity, intent, and authorization before agents interact with merchants and services. It answers three questions:

1. Who is this agent acting for? — Principal identity, verified via OAuth
2. What does it intend to do? — Declared scope and intent, per action
3. Is it authorized to do it? — Consent key, trip-level token, human approval

kyaLabs is K.Y.A. infrastructure. Every declaration creates a verified, user-consented record of agentic commerce behavior. What agents browse. What they intend to buy. Where they get blocked. Where they get through.

---

For Merchants

How Badge Works With Your Defenses

Your bot defenses work. Badge adds one signal on top of them.

kyaLabs publishes io.kyalabs.common.identity as a UCP checkout extension. Merchants who adopt Badge inject this capability into their /.well-known/ucp manifest. Every UCP-compliant agent at your store discovers it automatically.

When an agent carries a Badge declaration, it presents verified identity, declared intent, and a traceable human principal. You get one new column in your decision matrix: declared or undeclared. Nothing changes in your infrastructure. Your fraud systems stay intact.

What a Declared Agent Carries

• Agent type: Authorized actor — not a human, not a bot
• Principal verification: OAuth-authenticated human authorized this session (Google or Apple sign-in)
• Declared intent: Per-action authorization — every action was explicitly approved
• Verification token: Cryptographic proof of principal identity (pc_v1_...)
• Contact path: agent_identity@kyalabs.io for merchant verification

How to Verify

Programmatic (recommended): Use standard OAuth 2.0 token introspection (RFC 7662). Send the Bearer token to POST /api/oauth/introspect. Returns {active: true} or {active: false}. One HTTP call. No kyaLabs account required. Non-blocking. Discover the endpoint via /.well-known/oauth-authorization-server (RFC 8414).

Manual: Contact agent_identity@kyalabs.io with the token to verify principal identity (requires user consent).

Install

Future merchant apps (Shopify, etc.) coming under Badge by kyaLabs.

Non-Shopify merchants: Email merchants@kyalabs.io for manual manifest injection.

Full merchant documentation: kyalabs.io

Badge-declared agents do not bypass access controls. If your site requires login, CAPTCHA, or human verification — that is between the user and your platform. Badge declares identity on allowed actions. Nothing more.

---

UCP Identity Linking

kyaLabs is a Credential Provider in the Universal Commerce Protocol (UCP) — the open standard for agent commerce co-developed by Google and Shopify. UCP is adopted by Target, Walmart, Wayfair, and Etsy.

UCP's extensible capability model allows any domain owner to publish extensions. kyaLabs publishes io.kyalabs.common.identity — a checkout extension that lets agents declare verified human authorization before acting at a merchant. Merchants who adopt Badge signal to every UCP-compliant agent that declared agents are preferred.

The extension is open source under the MIT license. The full merchant documentation is at kyalabs.io. The UCP specification is at ucp.dev. The protocol repo is at github.com/kyalabs/ucp-agent-badge.

---

For Developers

kyaLabs is MCP-native. One install. Your agent declares itself. Badge tokens are UCP-compatible — merchants that implement the Universal Commerce Protocol read them natively.

Get Started

Badge + Spend (full stack):

clawhub install payclaw-io

Badge only (identity, no payment):

clawhub install payclaw-badge

Sign up at kyalabs.io to get your API key. Five-minute setup.

Badge for Agents

Badge is the mechanism by which an authorized actor proves it's not a bot. Before any action, the agent declares itself — and that declaration carries weight.

Think of it like a prescription pickup: you can authorize your mom to pick up your prescription, but that doesn't mean she can pick up all your prescriptions, forever, at any pharmacy. The authorization is specific: this action, this merchant, this session.

Badge works the same way. Your agent doesn't get broad, standing rights. It gets trip-level authorization — per action, at the moment of action, through the MCP server.

What Badge Declares

Every Badge-identified agent session carries:

• Agent type: Authorized actor — an automated system acting on behalf of a verified human
• Principal verification: OAuth-authenticated human authorized this session
• Per-action authorization: Every action carries explicit human approval
• Verification token: Cryptographic proof of principal identity (pc_v1_...)
• Contact path: agent_identity@kyalabs.io for merchant verification

How Verification Works

1. Agent calls kya_getAgentIdentity before any shopping action
2. kyaLabs issues an HMAC-SHA256 verification token tied to the authenticated principal
3. Agent presents the disclosure and token to merchants during the session
4. Merchants can verify the token and contact agent_identity@kyalabs.io to confirm principal identity (with user consent)

No card is issued. No money moves. Badge is the identity layer — the verified handshake that lets authorized agents through while bot defenses stay intact.

Badge Token Lifecycle

Badge verification tokens are issued per shopping session and expire after 24 hours. Each token is:

• Cryptographically signed (HMAC-SHA256) — cannot be forged
• Tied to the authenticated principal — cannot be transferred
• Scoped to the declared action — cannot be reused for different purposes
• Time-bounded — expires automatically, no standing authorization

Consent-Scoped Observability

Badge tracks what happens to your agent — but only within the boundaries you set.

• Every event is tied to a declaration. No identity declaration, no tracking. The pc_v1_ token is the consent boundary.
• Outcome tracking, not surveillance. After your agent presents its identity, kyaLabs records the outcome: was the agent accepted, denied, or was the result inconclusive? Four explicit outcome buckets — accepted, denied, inconclusive, no_sampling — with no interpretation baked into storage. Raw truth, stored as-is.
• Your scopes define the data. In V1, Badge tracks [BROWSE] declarations and outcomes. When additional scopes are introduced (search, cart, checkout), each scope introduces its own event tracking — only when you opt in.
• Attribution risk is disclosed. Any observation beyond your explicit consent scope is flagged as attribution risk on this page.

Design Principles

Badge is designed with merchant agent policies in mind — including those of Amazon, Shopify, Walmart, Instacart, and others. We do not claim compliance with any specific merchant's policy. We build for the pattern: declared identity, declared intent, verified principal, traceable action.

Spend for Agents

When an authorized actor needs to pay, Spend issues a virtual Visa card scoped to a single, human-approved task. Badge identity is included automatically — the agent that pays has already declared who it is.

Zero Trust by Design

kyaLabs doesn't ask anyone to trust the AI agent. It makes trust unnecessary by ensuring an agent architecturally cannot spend money without real-time human authorization, and architecturally cannot accumulate financial credentials between tasks.

The agent doesn't need to be trusted. The architecture enforces correct behavior.

The Five Pillars

1. Zero Standing Access

An agent connected to kyaLabs has no persistent financial state. It cannot query wallet balance, view card numbers, or access transaction history. Until the user approves a specific task, the agent knows nothing about the user's financial position.

2. Single-Intent Authorization

Every dollar that flows through kyaLabs requires a discrete, human-approved intent:

• Merchant: Where the purchase will be made
• Amount: Estimated spend (validated against actual at settlement)
• Description: What is being purchased
• Expiry: Intent window is time-bounded — the intent cannot be used after expiry

The human approves each intent via the MCP client's interactive prompt (approve/deny). This is an inline confirmation within the agent's tool-calling flow — the agent proposes a purchase, and the MCP client presents the details for human review before proceeding. The agent cannot bypass this step.

Merchant restrictions are available as a restrictive control — users can limit which merchants their agent is allowed to shop at. These restrictions reduce the agent's scope; they do not enable autonomous spending. Every purchase still requires individual human approval regardless of merchant restrictions.

One task. One human approval. One card.

3. Ephemeral Card Credentials

A fresh virtual Visa is issued for each approved intent, used for the purchase, and destroyed. The agent never accumulates card credentials between tasks. Each task is financially isolated. Your real card never enters the chat.

4. Atomic Authorization Flow

The complete lifecycle of an agent purchase is a single, unbroken chain:

Badge Identity → Intent Declaration → Human Approval (MCP prompt) → Card Issuance → Purchase → Settlement → Audit

Every step is time-bounded, user-scoped, audit-logged, and reconciled. The agent cannot self-approve — only the human, responding to the MCP client's interactive prompt, can authorize a purchase. For dashboard operations (viewing transactions, managing settings), MFA authentication is required.

5. Immutable Audit Trail

Every event is logged: identity declaration, intent creation, human approval, card issuance, transaction settlement, and intent reconciliation. Audit logs are scoped per user via Row-Level Security.

Spend Token Lifecycle

Spend intents are time-bounded with a 15-minute expiry window. Each intent is:

• Tied to a specific merchant and declared amount
• Human-approved via the MCP client's interactive prompt
• Fulfilled by a single-use virtual Visa card
• Automatically reconciled against the actual transaction at settlement
• Audit-logged at every stage

Comparison to Alternatives

---

For Card Issuers

Your BIN is protected by multiple architectural layers:

1. Identity-first: Every agent session is declared and verified via Badge before any card is issued
2. Bounded exposure: Single-use cards. One merchant per card. Human-approved amount.
3. Human authorization: Every card issuance has a corresponding human approval event via the MCP client's interactive prompt. Dashboard access requires MFA.
4. No agent accumulation: Agents cannot build up a portfolio of active cards or stored credentials.
5. Full audit trail: Every identity declaration, intent, approval, issuance, and settlement is logged and reconcilable.
6. Intent reconciliation: Automatic comparison of declared intent vs. actual spend — mismatches are flagged and logged.

The question isn't "do you trust the AI agent?" The answer is: the agent doesn't need to be trusted. The architecture enforces correct behavior.

---

Security Infrastructure

Authentication & Authorization

• Dual auth: API key (agent path) + session cookie (dashboard path)
• API keys: cryptographically hashed with timing-safe comparison, per-user limits enforced
• Agent purchase approval: MCP client interactive prompt (approve/deny per intent)
• Dashboard access: MFA (TOTP AAL2) mandatory for Spend-enabled accounts
• Badge: OAuth-only authentication (DQ-49) — no MFA required for identity declarations
• CSRF: Origin validation on all state-changing session requests, fails closed

Data Protection

• Card numbers never stored — transient API response only
• Badge verification tokens: HMAC-SHA256 signed, 24-hour expiry, not reversible to user identity without server-side secret
• Spend intents: 15-minute expiry, single-use card credentials
• Supabase Row-Level Security on all user-facing tables
• Admin operations use service role key, isolated from user sessions
• All API communication requires HTTPS (enforced at MCP client level)

Infrastructure Security

• Vercel auto-deployment from protected branches only
• Content Security Policy: no unsafe-eval, strict script sources
• HSTS with 2-year max-age, includeSubDomains, preload
• Rate limiting: tiered via managed store, financial endpoints fail closed if rate-limit service is unavailable

Continuous Security

• AI code review on every pull request (CodeRabbit)
• Secret scanning on every commit (gitleaks)
• Daily automated dependency auditing
• Append-only security changelog and audit trail

---

PayClaw LLC (d/b/a kyaLabs) · kyalabs.io · security@kyalabs.io