Title: The End of API Keys: Transitioning to Transactional Authentication for AI

Summary: Static API keys are the weakest link in AI and agent ecosystems; the near-term path is transactional authentication that binds every call to a verified identity, signed intent, and enforceable policy. This piece outlines a pragmatic, standards‑based blueprint to get you there—without breaking delivery timelines or procurement.

Hook — the specific headache you’re feeling right now

• Your AI stack is a sprawl of API keys hidden in .env files, LangChain notebooks, MCP servers, and CI runners. When a contractor or agent leaks a key, you’re blind to which call, which user, and which data was exfiltrated.
• Security questionnaires now ask for sender‑constrained tokens (DPoP/mTLS), HTTP request signing, passkeys, and FIPS‑validated key storage—and your backlog doesn’t have runway for a ground‑up re‑write.
• Model Context Protocol (MCP) toolchains amplify the blast radius: servers often default to bearer keys and long‑lived sessions; recent write‑ups and patches underline the risk surface created by agent frameworks and connectors. Transaction‑scoped auth—not static keys—is the only containment boundary that scales. (modelcontextprotocol.io)

Agitate — the risk if you don’t fix it this quarter

• Compliance timers are real. The EU AI Act’s bulk obligations begin applying on August 2, 2026; high‑risk use cases and transparency duties start biting then, with further milestones through 2027. Controls for identity, auditability, and access governance will be scrutinized. (digital-strategy.ec.europa.eu)
• FIPS 140‑2 cryptomodules go historical on September 21, 2026. If your secrets or signing keys sit in non‑validated modules, new federal deals (and many enterprise buyers) will balk. (csrc.nist.gov)
• Cloud defaults are changing under you. Google Cloud now encourages orgs to enforce iam.disableServiceAccountKeyCreation and migrate to Workload Identity Federation; relying on service‑account keys will keep breaking as org‑level controls tighten. (cloud.google.com)
• Passkeys and WebAuthn Level 3 are going mainstream, resetting expectations for phishing‑resistant human auth; if your “admin portal” for AI controls is still passwords + TOTP, you’ll underperform on both UX and security metrics. (w3.org)

Solve — 7Block Labs’ methodology for Transactional Authentication for AI We replace static keys with a layered, standards‑first architecture that binds every AI/tool call to a signed, policy‑checked transaction and a hardware‑attested runtime.

Layer 1 — Identity sources (humans and workloads)

• Humans: Passkeys via WebAuthn; require device‑bound or synced FIDO credentials with attestation. Target WebAuthn Level 3 features as they reach Candidate Rec in 2026. Map to NIST SP 800‑63‑4 (final July 31, 2025) for phishing‑resistant AALs. (w3.org)
• Workloads: Adopt workload identities (SPIFFE/SPIRE or cloud‑native roles). For Google Cloud, enforce “no new service‑account keys” and use Workload Identity Federation for SaaS/CI integrations. On AWS, prefer short‑term role credentials; long‑lived access keys only as a legacy exception. (cloud.google.com)

Layer 2 — Transaction tokens (proof‑of‑possession > bearer)

• OAuth 2.0 DPoP (RFC 9449) for sender‑constrained access/refresh tokens—no valid proof, no replay. Many identity platforms (e.g., Okta, Keycloak) now ship DPoP support you can turn on rather than build. For server‑to‑server and regulated scenarios, bind with OAuth mTLS (RFC 8705). (rfc-editor.org)
• HTTP Message Signatures (RFC 9421) for per‑request integrity of targets, headers, and body—especially for MCP and tool calls crossing trust boundaries. This yields a cryptographic audit trail per transaction. (rfc-editor.org)

Layer 3 — Authorization and policy (runtime decisions, not hardcoded roles)

• Externalize authorization using:
  • OPA/Rego at the edge (Envoy ext_authz), for contextual decisions close to traffic. (openpolicyagent.org)
  • Fine‑grained permissions in a PDP such as Amazon Verified Permissions (Cedar), which gained new language features in 2025—useful for multi‑tenant, per‑tool scopes. (aws.amazon.com)
• For human‑to‑AI attribute sharing, use Verifiable Credentials with selective disclosure:
  • OIDC4VCI 1.0 and OIDC4VP 1.0 are finalized (2025) for issuance and presentation. (openid.net)
  • SD‑JWT (RFC 9901, Nov 2025) lets users reveal only what’s needed (e.g., “employee in BU‑X”), bound to the request key. (rfc-editor.org)

Layer 4 — Runtime integrity and attestations (where your AI runs)

• Gate sensitive actions (PII retrieval, write‑back to CRM, code pushes) on attested environments:
  • Confidential VMs with Intel TDX or AMD SEV‑SNP and H100 GPUs on GCP A3 now support attestation workflows you can verify in‑band. Use Google Cloud Attestation to fetch EAT‑based claims and enforce via policy. (docs.cloud.google.com)
• Optional web3 trust anchor: Stamp high‑value approvals as on‑chain attestations (e.g., EAS) or signed EIP‑712 payload receipts, creating a tamper‑evident, cross‑org audit trail for regulated actions. (attest.org)

What this looks like in practice (reference flows)

1. Human approves a sensitive tool action

• User logs in with a passkey; your Authorization Server issues a short‑lived DPoP‑bound token.
• Client constructs an RFC 9421 signature over the outbound request to the MCP server and attaches a selective SD‑JWT presentation proving “Manager, Region=EU” without exposing birthdate or employee ID. (rfc-editor.org)
• Envoy calls ext_authz; OPA evaluates Rego using token claims, SD‑JWT disclosures, and runtime attestation (is the MCP tool running on an attested node?). Only then does the call hit the tool. (openpolicyagent.org)

1. Agent‑to‑system write‑back

• The AI agent requests a one‑time “write intent” from a Cedar‑backed PDP. That PDP issues a constrained capability (GNAP or OAuth transaction token), scoped to a specific resource and method, expiring in minutes. (rfc-editor.org)
• The agent calls the system API with: mTLS (or DPoP), HTTP Signature, and the capability token. The resource server verifies all three, then logs a cryptographic receipt (and, for critical changes, a signed EIP‑712 acknowledgement for immutable audit). (rfc-editor.org)

1. Workload identity (CI → model hosting)

• CI job assumes a workload identity (no keys). It fetches a DPoP‑bound token via OIDC federation and deploys a new MCP server build into a Confidential VM; startup includes attestation verification before the orchestrator routes any requests. (docs.cloud.google.com)

Practical implementation details you can lift

• DPoP proof on each call (Node/TypeScript pseudocode)

import { createPrivateKey, sign } from 'crypto';
import * as jose from 'jose';

const key = await jose.generateKeyPair('ES256'); // device-bound or stored in FIPS-validated HSM
const accessToken = process.env.ACCESS_TOKEN;

async function dpopProof(url: string, method: string) {
  const jkt = await jose.calculateJwkThumbprint(await jose.exportJWK(key.publicKey), 'sha256');
  const payload = {
    htm: method.toUpperCase(),
    htu: url,
    jti: crypto.randomUUID(),
    iat: Math.floor(Date.now()/1000),
    ath: jose.base64url.encode(crypto.createHash('sha256').update(accessToken).digest()),
  };
  return new jose.SignJWT(payload)
    .setProtectedHeader({ alg: 'ES256', typ: 'dpop+jwt', jwk: await jose.exportJWK(key.publicKey) })
    .sign(key.privateKey);
}

// usage:
const proof = await dpopProof('https://api.internal/tools/mcp/job', 'POST');
// send: Authorization: DPoP <accessToken>; DPoP: <proof>

• Envoy → OPA external authorization pattern (high level)

  • Envoy http_filter ext_authz forwards headers: Authorization, DPoP, Signature, Signature-Input.
  • OPA policy (Rego) validates:
    • DPoP iat/jti/htu/htm and ath matches presented token.
    • HTTP Message Signature covers method, path, host, date, digest.
    • PDP decision from Cedar/Verified Permissions for fine‑grained action.
    • Attestation claims allow “write” only from approved TCB. (envoyproxy.io)

• Verifiable Credentials in practice

  • Issue employment/role credentials via OIDC4VCI; store in enterprise wallet.
  • At request time, present via OIDC4VP with SD‑JWT to disclose only the attributes required by policy (e.g., “Line‑of‑Business = Pharma, Role = Qualified Person”). (openid.net)

• MCP hardening quick wins

  • Require OAuth with DPoP for MCP connectors; drop bearer keys.
  • Enforce HTTP Message Signatures on tool requests/responses to defeat injection via tampered intermediaries.
  • Bind high‑risk tools to attested runtimes; reject calls if attestation token or GPU/TEE claim is missing/invalid. (docs.anthropic.com)

Why this is a business outcome, not just “more crypto”

• Better conversion and lower support cost: Enterprises adopting passkeys report materially higher sign‑in success and fewer resets; case studies show 30k fewer support calls/month and multi‑x success‑rate lifts—this lands as higher activation and lower CAC/COGS. (fidoalliance.org)
• Faster security reviews and fewer vendor redlines: Mapping to NIST SP 800‑63‑4, RFC 9449/9421/8705, and FIPS‑validated modules shortens procurement cycles with risk teams that now explicitly ask for “sender‑constrained tokens,” “HTTP signatures,” and “no long‑lived keys.” (pages.nist.gov)
• Compliance runway: EU AI Act enforcement and FIPS 140‑2 sunset dates create a crisp, defensible plan for auditors and boards (controls, timelines, artifacts). (digital-strategy.ec.europa.eu)
• Incident containment: With per‑request proofs and policy decisions logged, you can scope any compromise to a handful of transaction IDs instead of a week’s worth of bearer‑token traffic.

Target audience and the keywords your teams actually search for

• Who: Heads of AI Platform, CISOs, Directors of Identity & Zero Trust, Enterprise Architects, Procurement leads owning AI risk.
• Keywords to include in your internal RFCs and RFPs:
  • OAuth 2.0 DPoP (RFC 9449); OAuth mTLS (RFC 8705); HTTP Message Signatures (RFC 9421) (rfc-editor.org)
  • WebAuthn Level 3; Passkeys rollout metrics (2025) (w3.org)
  • NIST SP 800‑63‑4 (AAL/IAL/FAL mapping) (pages.nist.gov)
  • OIDC4VCI 1.0, OIDC4VP 1.0; SD‑JWT (RFC 9901) (openid.net)
  • Verified Permissions (Cedar 4.x), OPA/Rego with Envoy ext_authz (aws.amazon.com)
  • SPIFFE/SPIRE workload identity; GCP Workload Identity Federation controls (disable key creation) (cloud.google.com)
  • Confidential Computing attestation (Intel TDX/AMD SEV‑SNP), GPU attestation on H100/A3 (docs.cloud.google.com)
  • EU AI Act timeline; FIPS 140‑3 CMVP adoption deadlines (digital-strategy.ec.europa.eu)

What “good” looks like in 60–90 days (without boiling the ocean)

• 0–30 days
  • Inventory all API keys; classify by system/agent and rotate to short‑lived tokens.
  • Enable DPoP and mTLS on one high‑risk integration (choose an IdP with native support). (okta.com)
  • Stand up Envoy ext_authz + OPA for a single MCP tool path; start emitting decision logs. (openpolicyagent.org)
• 31–60 days
  • Roll out passkeys for your AI admin and data‑tooling surfaces; target ≥90% WebAuthn coverage for admins. (fidoalliance.org)
  • Issue a Verifiable Credential (OIDC4VCI) for “Data Steward” and require OIDC4VP presentation + SD‑JWT for any dataset export. (openid.net)
• 61–90 days
  • Enforce iam.disableServiceAccountKeyCreation on GCP folders hosting AI infra; migrate CI to Workload Identity Federation. (cloud.google.com)
  • Gate PII write‑backs on Confidential VM attestation (A3/TDX); reject if claims don’t match your policy. (docs.cloud.google.com)
  • Produce an audit demo: show a full transaction proof (DPoP + HTTP Signature + PDP decision + attestation claim) in under 3 clicks.

Where blockchain and ZK add pragmatic value (no hype)

• For regulated approvals (e.g., pricing changes, supply‑chain releases, KYC overrides), stamp an immutable receipt:
  • Sign an EIP‑712 “ApprovalReceipt” with the approver’s enterprise key and record a minimal on‑chain attestation (EAS) for inter‑org verification—no PII on‑chain, just hashes and timestamps. This augments—but does not replace—your off‑chain logs. (eips.ethereum.org)
• For privacy‑preserving proofs in agent flows, combine SD‑JWT’s selective disclosure with zk‑friendly circuits only where needed (e.g., “over‑18” or “resides‑in‑EEA” without the exact DOB or address). Start with SD‑JWT (now an RFC) and evaluate ZK later for high‑assurance markets. (rfc-editor.org)

GTM proof points you can quote in your business case

• Passkey adoption and impact:
  • 69% of consumers report enabling a passkey on at least one account; enterprises cite measurable drops in account recovery and call volume (e.g., Aflac: 30k fewer calls/month; Microsoft: 3x higher success, 8x faster sign‑ins). (fidoalliance.org)
• Standards momentum:
  • WebAuthn Level 3 entered Candidate Recommendation in January 2026; OIDC4VCI/4VP finalized in 2025; SD‑JWT became RFC 9901 in November 2025; DPoP is RFC 9449 and is rolling out in mainstream IdPs. (w3.org)
• Cloud and compliance pressure:
  • GCP’s “disable service‑account key creation” default for new orgs and migration guidance signals the end of static keys; EU AI Act mid‑2026 obligations and FIPS 140‑2 sunset in Sept 2026 lock the timeline. (cloud.google.com)

How we engage (and where we plug into your roadmap)

• Transactional Auth Accelerator (2–3 weeks)
  • Deliverables: reference architecture, Envoy/OPA policy starter kit, DPoP enablement for one IdP/client, HTTP Message Signatures libraries, SD‑JWT/OIDC4VP demo, and attestation gate prototype.
  • Mapped controls: NIST SP 800‑63‑4 (AAL2/3), RFC 9449/9421/8705, VC 2.0, OIDC4VCI/4VP.
• Build + Integrate (6–8 weeks)
  • Harden an MCP toolchain with DPoP + HTTP signatures; wire Cedar or OPA for fine‑grained scopes; enforce Workload Identity; add Confidential VM gating; produce auditor‑ready artefacts.
• Optional: On‑chain receipts
  • Minimal, regulation‑aware EAS/EIP‑712 receipts for cross‑org approvals without exposing sensitive data.

Relevant 7Block Labs services you can engage today

• Our end‑to‑end web3 development services for credential wallets and selective disclosure.
• Enterprise‑grade blockchain development services for EIP‑712/EAS audit receipts and integration with identity systems.
• Independent security audit services covering DPoP/mTLS/HTTP Signatures, OPA/Cedar policy, and MCP hardening.
• Systems blockchain integration with existing IdPs, gateways, and confidential compute.
• Solution accelerators for smart contract development, asset management platforms, and asset tokenization where on‑chain attestations add defensible audit.

A final word on sequencing

• Do not try to “replace keys everywhere” on day one. Pick the single riskiest path: agent write‑backs to critical systems or dataset export. Land DPoP + HTTP Signatures + policy + attestation there, prove the logs, then templatize.

Personalized CTA If you’re the Director of AI Platform or the CISO for a Fortune 1000 rolling out ≥5 agentic use cases by Q3 2026 and you need a concrete, auditor‑ready plan to kill static keys without slipping delivery dates, book our 45‑minute “Transactional Auth for AI” working session. We’ll map one of your live flows to DPoP + HTTP Signatures + OPA/Cedar + Confidential VM attestation and return a 10‑day pilot plan, RFP‑grade controls, and a procurement‑friendly cost model. No slides—bring a problematic endpoint and we’ll whiteboard the fix.