DEV Community

L_X_1
L_X_1

Posted on • Originally published at policylayer.com

Know Your Agent (KYA): We're Building the Infrastructure

#compliance

The bottleneck for the agent economy is shifting from intelligence to identity.

In financial services, "non-human identities" now outnumber human employees 96-to-1—yet these identities remain unbanked ghosts. The critical missing primitive? KYA: Know Your Agent.

As Sean Neville (cofounder of Circle, architect of USDC, CEO of Catena Labs) put it:

"Just as humans need credit scores to get loans, agents will need cryptographically signed credentials to transact—linking the agent to its principal, its constraints, and its liability."

We've been building exactly this infrastructure.

The KYA Primitive

The KYA framework defines three things an agent needs cryptographically bound:

Component Purpose
Principal Who does this agent work for?
Constraints What is this agent allowed to do?
Liability Who's accountable when things go wrong?

Without this, merchants will keep blocking agents at the firewall. No credential means no trust. No trust means no transaction.

How PolicyLayer Implements KYA

We've been building these primitives into our policy enforcement layer:

Principal Binding

Every agent in PolicyLayer operates with a scoped identity:

Organization (orgId)
  └── API Key (apiKeyId)
        └── Policy Group
              └── Spending Rules
Enter fullscreen mode Exit fullscreen mode

When an agent requests a transaction, its identity is cryptographically verified. The API key binds the agent to an organization. The organization owns the liability.

This isn't just authentication—it's principal attestation. Every policy decision is logged with the agent's identity, creating an immutable record of who authorized what.

Constraint Enforcement

Constraints aren't suggestions. They're cryptographically enforced limits:

Spending Controls:

  • Per-transaction maximums
  • Hourly velocity limits
  • Daily spending caps
  • Recipient whitelists (only approved addresses)
  • Transaction frequency limits

Enforcement Mechanism:

Agent Intent → Policy Engine → Constraint Check → Signed Approval → Local Signing
                                      ↓
                              Intent Fingerprint (SHA-256)
                              Policy Hash (SHA-256)
                              Decision Signature
Enter fullscreen mode Exit fullscreen mode

The constraints aren't stored in the agent's prompt (which can be manipulated). They're stored in a deterministic policy engine that the agent cannot bypass.

Liability Trail

Every transaction creates a cryptographic proof chain:

{
  "apiKeyId": "agent_customer_support_01",
  "orgId": "org_acme_corp",
  "intentFingerprint": "7c5bb4a3...",
  "policyHash": "ba500a3f...",
  "signature": "hmac-sha256:...",
  "timestamp": "2025-12-16T14:32:01Z",
  "decision": "APPROVED",
  "limits_applied": {
    "per_transaction": "$500",
    "daily_remaining": "$4,250",
    "recipient_whitelist": true
  }
}
Enter fullscreen mode Exit fullscreen mode

This isn't just logging—it's liability infrastructure. When regulators ask "who approved this $10,000 transfer?", the answer is cryptographically verifiable:

  • Which agent (API key)
  • Under which constraints (policy hash)
  • At what time (timestamp)
  • With what authorization (signature)

The Two-Gate Model as KYA Enforcement

Our two-gate enforcement architecture implements KYA at the transaction level:

Gate 1: Identity + Intent

  • Agent presents credentials (API key)
  • Declares transaction intent (amount, recipient, asset)
  • Policy engine verifies constraints
  • Returns signed authorization token with intent fingerprint

Gate 2: Verification + Execution

  • SDK recalculates intent fingerprint from actual transaction
  • Compares with token's fingerprint (tamper detection)
  • Verifies token hasn't been consumed (replay prevention)
  • Only then: local signing with private keys

Any modification between gates—changed recipient, increased amount, altered memo—triggers fingerprint mismatch. Transaction blocked.

This is KYA in action: the agent's identity, constraints, and accountability are verified at every transaction, not just at onboarding.

What's on Our Roadmap

The industry has "months to figure out KYA." Here's where we're headed:

EdDSA Signatures (In Progress)

Moving from HMAC to EdDSA signatures enables public verification. Anyone can verify an agent's constraints without calling our API. The credential becomes portable.

Exportable Proof Bundles

Complete transaction proofs that can be:

  • Archived for compliance (7-year retention)
  • Shared with auditors
  • Verified independently
  • Submitted to regulators

Cross-Platform Recognition

The endgame: merchants accept PolicyLayer attestations as trust signals. "This agent has verified constraints" becomes the equivalent of "this human has a credit score."

The Merchant Perspective

Right now, merchants have two choices with AI agents:

  1. Block them entirely (losing revenue)
  2. Accept unlimited risk (potential fraud/drain)

KYA infrastructure creates a third option:

  1. Accept agents with verified constraints

A merchant can say: "I'll accept this agent because I can verify it has a $500 per-transaction limit, a $5,000 daily cap, and a cryptographic trail linking it to Acme Corp's liability."

That's the unlock. That's what turns "unbanked ghosts" into economic actors.

Why Non-Custodial Matters for KYA

One critical design choice: PolicyLayer never holds private keys.

PolicyLayer sees:     chain, asset, recipient, amount, memo hash
PolicyLayer NEVER sees: private keys, signed transactions, seed phrases
Enter fullscreen mode Exit fullscreen mode

This matters for KYA because:

  1. Liability stays with the principal. The organization that holds the keys holds the liability. PolicyLayer provides the constraints, not the custody.

  2. No single point of failure. Compromising PolicyLayer doesn't compromise funds—only the policy enforcement layer.

  3. Regulatory clarity. We're a policy service, not a money transmitter. The principal maintains custody and regulatory responsibility.

KYA doesn't require centralized custody. It requires verifiable constraints. Those are different things.

Building in Public

We're not waiting for a standard to emerge. We're building the infrastructure now.

  • Open source SDK: github.com/PolicyLayer/PolicyLayer
  • Live dashboard: Configure constraints without code
  • Multi-chain: Ethereum, Base, Solana, all EVM-compatible chains
  • Multi-wallet: ethers, viem, Coinbase, Privy, Dynamic, Solana

The KYC infrastructure took decades to build. The KYA infrastructure needs to be ready in months.

We're building it.

Want to give your agents verifiable credentials?

Reach out: We're actively looking for design partners building agent-first financial products. Contact us.

Top comments (0)