Building the “Keyless” Architecture: How to Authenticate AI Agents Onchain

Summary: Your AI agents don’t need hot API keys or exportable private keys to operate autonomously onchain. A keyless architecture uses passkeys, session keys, zk/TEE attestations, and account abstraction (EIP-7702, ERC‑4337, and emerging RIP‑7560) to prove “who acted” and “under what policy” with audit‑ready guarantees.

—

Hook — The headache nobody budgets for: “Where do agent keys live?”

• You’ve automated onchain actions with an AI agent, but your infosec team blocks go‑live: a headless server wallet, long‑lived API keys, or a seed stashed in KMS is a non‑starter. One leaked key and any “autonomous” workflow becomes an incident.
• Wallet UX for human operators is solved with passkeys, but AI agents need continuous, policy‑bound authority. Without scoped, revocable authorization you’re juggling break‑glass wallets, custom relayers, and brittle allowlists across chains.
• Meanwhile, the standards are moving: EOAs temporarily “become” smart wallets via EIP‑7702, modular smart accounts ship plugins (ERC‑6900/7579), and L2s test native AA (RIP‑7560/7711/7712). If you ship the wrong pattern, you’ll re‑platform within a quarter. (theblock.co)

Agitate — What this risk costs in Q1–Q2 2026

• Compliance stalls: NIST 800‑63B pushes phishing‑resistant authenticators; passkeys (FIDO2/WebAuthn) are blessed for AAL3 scenarios with channel/verifier‑name binding. Procurement teams now ask for this in RFPs. If your “agent auth” is a bearer key, expect redlines and delays. (pages.nist.gov)
• Support burden: Password/OTP flows drive recovery tickets and phishing. Enterprises are rapidly shifting to passkeys; Okta reports a 63% YoY rise in phishing‑resistant authenticators. Plan for that baseline, or your SOC will inherit avoidable incidents. (okta.com)
• Interop foot‑guns: Contract‑based signatures (ERC‑1271) vary by chain; even large wallets have run into chain‑specific incompatibilities (e.g., passkey smart accounts failing signature validation on Monad per user reports). Your agent may “work” on one network and be bricked on another. (reddit.com)
• Data provenance gaps: Agents that call Web2 APIs need verifiable receipts. Without zk/TEE‑backed attestations (zkTLS/TEEs), onchain contracts cannot distinguish a genuine API result from a forged payload, blocking high‑value automation and regulated flows. (tlsnotary.org)

Solve — 7Block Labs’ Keyless Architecture for Onchain Agents We implement “keyless” as four composable layers you can adopt incrementally. Each layer maps to concrete standards, audited components, and business outcomes.

1. Identity + Enrollment (who owns the agent?)

• Human operator: Passkeys (WebAuthn) for provisioning and approvals, using wallet modules that validate WebAuthn/Passkey signatures under ERC‑1271 and ERC‑4337 smart accounts. We commonly use passkey validators like Rhinestone’s WebAuthn module for production‑grade flows. Outcome: phishing‑resistant enrollment, no seeds. (docs.rhinestone.dev)
• Agent identity: Assign a DID and capability token (UCAN/CACAO). UCAN/CACAO provide cryptographically signed, attenuated capabilities (time‑bound, scope‑limited) that the agent can carry offline, ideal for micro‑services and inter‑agent delegation. Outcome: least‑privilege across offchain actions without centralized IAM. (ucan.xyz)
• Login/session for dashboards: SIWE (EIP‑4361) with ERC‑1271 verification ensures contract wallets and agents authenticate uniformly, including counterfactual accounts with ERC‑6492 where needed. Outcome: clean enterprise SSO‑like sessions bound to onchain accounts. (eips.ethereum.org)

1. Authorization + Policy (what is the agent allowed to do?)

• Smart accounts and temporary authority:
  • ERC‑4337 smart accounts with session keys: fine‑grained time windows, ACLs, ERC‑20/native gas caps, and per‑function selectors validated onchain. Vendors like Alchemy and thirdweb expose scoped “session key” APIs now, and documentation patterns are settling. Outcome: “do X up to $Y for T minutes against contract Z.” (alchemy.com)
  • EIP‑7702 smart EOAs: let existing EOAs act as smart wallets for a single transaction, enabling batched calls and sponsorship with compatibility to 4337, while staying future‑aligned with native AA. Outcome: migrate incrementally without forcing users to new addresses. (theblock.co)
  • Modular accounts (ERC‑6900/7579): install validator/executor modules for passkeys, session keys, spending guards, and audit hooks—without vendor lock‑in. Outcome: swappable auth modules across providers (Safe, ZeroDev, Biconomy, etc.). (eips.ethereum.org)
• Parallelism and replay safety:
  • RIP‑7712 multi‑dimensional nonces isolate “lanes” (e.g., routine ops vs. treasury actions) to avoid nonce contention and simplify incident rollback. Outcome: safer concurrency for autonomous agents. (docs.erc4337.io)
• App‑to‑wallet pipelines:
  • EIP‑5792 wallet_sendCalls for atomic batched execution and capability discovery (e.g., paymasters); ERC‑7836 for app‑signed prepared calls; ERC‑7871 wallet_sign to unify offchain signature requests. Outcome: standardized, wallet‑agnostic integrations. (eips.ethereum.org)

1. Attestation + Provenance (can we prove the inputs and the actor?)

• Onchain attestations:
  • EAS (Ethereum Attestation Service) to anchor “Agent X (DID) is permitted to trade USDC up to $N daily for Project Y; signed by Custodian Z.” With millions of attestations live across L1/L2, EAS is a battle‑tested base layer. Outcome: auditable intent and policy provenance. (attest.org)
• Web2 proof ingestion (zkTLS / TEE):
  • For agents reading APIs (bank balance, SaaS invoice), use zkTLS or TEE‑attested transcripts to prove a TLS exchange happened with server S and returned m, privately. Tooling and events (Devconnect zkTLS Day), and production docs (TLSNotary, zkMe) make this viable now. Outcome: verifiable offchain data without trusting your own server’s word. (tlsnotary.org)
• Cross‑chain/service attestations:
  • Chainlink CCIP’s Token Developer Attestation adds issuer‑controlled verification to cross‑chain mints and can serve as a pattern for agent‑origin attestations across networks. Chainlink’s ISO 27001/SOC 2 posture helps clear enterprise vendor risk checks. Outcome: smoother InfoSec reviews and reliable cross‑chain behavior. (blog.chain.link)

1. Execution + Settlement (how does the agent act and who pays gas?)

• Gas sponsorship and batching:
  • Use ERC‑4337 paymasters plus EIP‑5792 capabilities to sponsor gas, with guardrails enforced by the smart account. Outcome: “free” agent actions within limits—no stuck ops due to gas logistics. (docs.erc4337.io)
• Native AA pilots on L2s:
  • On OP‑stack pilots (e.g., Kroma’s “Pioneer Alpha”), native AA (RIP‑7560/7711/7712) can cut indirection overheads. We design for forward compatibility so you don’t rebuild when L2s enshrine AA. Outcome: lower overhead and simpler mempool inclusion paths over time. (bitcoininsider.org)
• zk/TEE‑backed agent inference (optional, high‑assurance):
  • Where it matters (e.g., trading policy compliance), bind model hash/version and decision threshold into a zkVM/TEE attestation. The zkML stack is evolving quickly (RISC Zero/SP1 research, Mina zkML libs, ZKPyTorch). Outcome: cryptographically provable “why” behind an action. (blog.alignedlayer.com)

Practical patterns you can ship this quarter

Pattern A — “Procurement‑safe trading agent” (DeFi ops desk)

• Enrollment:
  • Operator uses a passkey to initialize a modular smart account (ERC‑6900/7579) with a WebAuthn validator.
• Policy:
  • Issue a UCAN/CACAO capability: “Agent-DID may execute swaps on Contract C, daily cap 50,000 USDC, validUntil = +72h.”
  • Install a session key module with ERC‑20 + gas caps and target‑selector allowlists.
  • Record the policy as an EAS attestation referencing the DID and smart account address.
• Execution:
  • Agent submits a prepared call bundle via ERC‑7836 → wallet executes atomically with EIP‑5792; paymaster sponsors gas; nonces use a dedicated “automation” lane (RIP‑7712).
• Audit:
  • Contract emits policy‑ID and capability hash on every execution. Discrepancies can be blocked at validateUserOp(). Outcome: zero static keys, explicit ceilings, verifiable approvals. (eips.ethereum.org)

Pattern B — “Receipts‑onchain” SaaS‑purchasing agent (FinOps automation)

• The agent buys SaaS credits via a Web2 API; a local zkTLS module produces a zero‑knowledge proof that the invoice JSON came from vendor.com over a valid TLS session. The agent posts the proof digest onchain; accounting contracts unlock budget only if the proof verifies.
• For actions needing a human nudge, use EIP‑7702 to elevate an EOA to a smart wallet for a one‑shot approval, keeping the same address. Outcome: human‑in‑the‑loop without rekeying; compliant receipts without exposing PII. (docs.zk.me)

Pattern C — “Cross‑chain executor with developer attestations” (treasury ops)

• The agent moves a wrapped asset across chains via CCIP; minting on destination requires a developer attestation. Treasury policy (EAS) and CCIP attestation both must pass before settlement. Outcome: fewer false mints and traceable policy conformance across chains. (blog.chain.link)

Implementation details that matter in 2026 (and how we derisk them)

• Passkeys and device‑bound sessions:
  • Pair passkeys with DBSC (device‑bound session credentials) where available to neutralize cookie theft. Aligns with Google Workspace’s hardening path and NIST’s phishing‑resistance guidance. Outcome: fewer “session hijack” tickets and faster ATO remediation SLAs. (techradar.com)
• Counterfactual and cross‑chain signatures:
  • Use ERC‑6492 wrapper signatures to validate contract‑wallet signatures pre‑deploy, and standardize ERC‑1271 verification across chains in your QA grid (include Monad, Base, OP, Arbitrum). Outcome: avoid “works on chain X only” outages. (eips.ethereum.org)
• Standard RPCs for batching and signing:
  • Prefer EIP‑5792/7836/7871 over bespoke relayers to reduce vendor lock‑in and speed wallet integrations. Outcome: lower integration cost; simpler procurement/security review. (eips.ethereum.org)
• Forward‑compatible AA:
  • Design for EIP‑7702 today and keep accounts modular (ERC‑6900/7579) to adopt native AA (RIP‑7560/7711/7712) on L2s without rewriting business logic. Outcome: future‑proofing your agent fleet. (theblock.co)

GTM proof — what buyers and boards respond to Target audience and their required keywords

• Head of Platform & Security (AI product companies, exchanges, L2s):
  • Keywords: WebAuthn attestation, EIP‑7702 smart EOAs, ERC‑4337 paymasters, ERC‑6900/7579 plugins, RIP‑7560 native AA, RIP‑7712 nonce lanes, ERC‑5792 wallet_sendCalls, ERC‑1271/6492, EAS schemas, zkTLS, TEE attestation.
• Procurement/Risk:
  • Keywords: phishing‑resistant authentication (NIST 800‑63B supplement on syncable authenticators), device‑bound sessions (DBSC), ISO 27001/SOC 2 posture of critical dependencies, vendor risk matrix, audit trail. (nist.gov)
• FinOps/COO:
  • Keywords: spend ceilings, time‑boxed session keys, atomic settlement, exception workflows, cross‑chain policy enforcement, receipt proofs.

30‑90‑day KPI framework we sign up to drive

• Day 30:
  • Human enrollment flows moved to passkeys; SIWE for dashboards; pilot modular account with session key policy. Success: ≥90% auth flows phishing‑resistant; remove any server‑stored seed/API key from production paths. Reference: industry move to passkeys at scale (Google default; Okta trend). (forbes.com)
• Day 60:
  • Two agent policies live with onchain enforcement: caps, ACLs, expiries; EAS policy attestations searchable; ERC‑5792 batching in place; paymaster sponsorship live in staging. Success: zero privileged long‑lived keys; measurable drop in manual approvals.
• Day 90:
  • Web2 receipt proofs (zkTLS/TEE) verify onchain; cross‑chain movement gated by attestations where applicable. Success: “policy‑bound autonomy” metrics — % transactions auto‑approved within policy, MTTR for revocations, % with verifiable receipts.

What we’ll build and where (service mapping)

• Account abstraction integration and wallet policy modules via our custom smart‑account and plugin engineering under our custom blockchain development services and smart contract development.
• Passkey enrollment, SIWE, and capability tokens wired into your app stack with our web3 development services and blockchain integration.
• Session key guards, paymasters, and cross‑chain attestations (EAS/CCIP) delivered alongside cross‑chain solutions development and blockchain bridge development.
• Pre‑launch hardening (ERC‑1271/6492, policy hooks, replay/nonce lanes) through security audit services.
• If you’re productizing autonomous DeFi flows, we can ship end‑to‑end strategy agents using our defi development services and dapp development.

Deep‑dive: a minimal “keyless” policy in practice

• Policy record (onchain):
  • EAS Schema: AgentDID, Account, targetContract, functionSelectors, spendCap, validFrom, validUntil, policyId.
• Account module:
  • validateUserOp enforces:
    • msg.sender == sessionKey
    • now ∈ [validFrom, validUntil]
    • call.to ∈ ACL and selector in allowlist
    • runningSpend + amount ≤ spendCap (rollover optional)
    • uses nonceKey = 2 (automation lane) per RIP‑7712
• Execution:
  • App constructs a batch {approve, execute} and submits via ERC‑7836 prepared calls → wallet_sendCalls (EIP‑5792) with “atomic: true” + paymaster capability.
  • For EOAs, EIP‑7702 wraps the one‑shot transaction with smart‑account logic; code resets afterward, keeping the same address.

Risk register — lessons from the field

• ERC‑1271 parity across networks: Test contract‑signature paths in CI on all target chains. Capture a “fail‑safe” break‑glass via 7702 (one‑shot approval), not by exporting keys. Recent user reports show EIP‑1271 failures can strand passkey wallets on new chains if not deployed correctly. (reddit.com)
• Session key drift: Never enforce scopes offchain only. Keep spend/gas caps and ACLs in the validator module so revocation is final and observable onchain. Use EIP‑5792 wallet_getCapabilities to fail fast on wallets lacking required features. (eips.ethereum.org)
• Data provenance: For high‑value automations, require zkTLS or TEE attestations; don’t accept unsigned JSON from your own backend as “proof.” Track the ecosystem (TLSNotary, zkMe) and plan for standard proof verifiers per provider schema. (tlsnotary.org)
• Forward compatibility: Keep modules standards‑aligned (ERC‑6900/7579) and isolate nonce lanes (RIP‑7712) so migrating to native AA (RIP‑7560) on L2s is a config change, not a rewrite. (eips.ethereum.org)

Why this pays for itself

• Fewer incidents and tickets: Passkeys cut phishing paths; device‑bound sessions blunt cookie theft. Your SOC measures fewer “credential” events while preserving strong UX. (techradar.com)
• Faster time‑to‑revenue: With standardized batching (EIP‑5792) and capability‑based auth (UCAN/CACAO + session keys), you avoid wallet‑specific rewrites and central IAM bottlenecks. (eips.ethereum.org)
• Audit‑ready autonomy: Every agent action carries a policy ID (EAS) and, when needed, a zkTLS/TEE receipt. That’s a “money phrase” for procurement: “provable policy‑bound automation.”

Your next step — let’s make one agent “keyless” in 10 working days If you’re the Head of Platform or Security with a Q2 2026 release that involves autonomous onchain actions, book our “Keyless Agent Readiness” sprint. In two weeks we’ll: map your flows to EIP‑7702/4337 modules, define EAS schemas and session‑key guards, wire EIP‑5792 batching with a paymaster, and ship a working POC with a revocation drill. Reply with your target chains and the single highest‑risk action your agent must perform, and we’ll return a scoped plan, fixed‑fee estimate, and a procurement‑ready architecture memo you can drop into your RFP.

References

• EIP‑7702 smart EOAs and Pectra context. (theblock.co)
• Modular smart accounts: ERC‑6900 and ERC‑7579. (eips.ethereum.org)
• Native AA proposals: RIP‑7560/7711/7712. (docs.erc4337.io)
• EIP‑5792/7836/7871 wallet RPCs. (eips.ethereum.org)
• Passkey validator modules (WebAuthn) for smart accounts. (docs.rhinestone.dev)
• NIST 800‑63B guidance on phishing‑resistant authenticators and the 2024 supplement on syncable authenticators. (pages.nist.gov)
• Device‑Bound Session Credentials (DBSC) initiative coverage. (techradar.com)
• ERC‑1271/6492 for contract wallet signatures and counterfactual accounts. (eips.ethereum.org)
• EAS adoption and ecosystem positioning. (attest.org)
• zkTLS ecosystem and tutorials. (tlsnotary.org)
• Chainlink CCIP developer attestations and security posture. (blog.chain.link)
• Field issue: Passkey smart‑account EIP‑1271 mismatch on Monad (user reports). (reddit.com)

—

If you prefer to start with a narrower slice, ask us to retrofit session keys and onchain caps to a single high‑risk action (e.g., “swap USDC on Contract C up to $5k/24h”) and we’ll turn that into a template for the rest of your agent fleet using our web3 development services and security audit services.