For decades, we wrote deterministic programs that called APIs. Today, we increasingly delegate intent to models that decide which tools to call, in what order, with what parameters, based on natural language and evolving context.

That shift is subtle but profound: the “program” isn’t just your code anymore. It’s your prompt, your tool wiring, your memory, your retrieval layer, your agent runtime, and the model’s outputs—often across multiple steps.

This is why policy as code matters.

Not as a buzzword. As the pragmatic answer to a question every enterprise (and honestly, every serious builder) eventually hits:

“How do we give an agent real capabilities without turning the system into a liability?”

This post is a builder’s view of policy as code—why it’s becoming necessary, what it should control, and how audits + observability stop being optional once agents act in the real world. I’ll use examples from things I’ve been building and thinking about lately—Attach.dev (a gateway/runtime), OpenBotAuth (cryptographic agent identity), and OpenClaw (agent tooling + orchestration).

What “policy as code” actually means

Policy as code is the practice of expressing rules—permissions, constraints, approvals, safety boundaries, and compliance requirements—in a machine-executable form that is:

• Versioned (like software)
• Reviewable (PRs, approvals)
• Testable (unit tests + simulation)
• Deployable (enforced at runtime)
• Observable (you can prove what happened)

In the classic enterprise world, we already have “policies,” but they’re scattered:

• IAM rules
• network firewalls
• DLP systems
• compliance checklists
• SOC2 controls
• manual approvals in ticketing systems

Agent systems make this fragmentation painful, because an agent can traverse layers in one “thought-to-action” hop. The policy can’t be tribal knowledge or a PDF. It has to be enforced where actions occur.

Why the web (and enterprises) need guardrails for GenAI

1) Agents are “non-deterministic integrations”

When you integrate Stripe or Slack, you know the exact calls you make. With agents, you’re integrating a planner that can generate new sequences of calls at runtime.

That’s not inherently bad—it’s why agents are powerful—but it means your security posture can’t rely on “we didn’t code it that way.”

2) Natural language is an attack surface

Prompt injection, malicious tool outputs, poisoned retrieval results, “helpful” but wrong conclusions, accidental data leakage—these are all variations of the same theme:

The model will try to comply with the most recent, most salient instruction unless constrained.

3) Enterprises don’t fear AI text; they fear AI actions

Summarizing an email is low risk.

Sending money, modifying production config, emailing external parties, exporting data, or signing requests—those are governance problems.

The moment agents can do, not just say, policy becomes core infrastructure.

The three pillars: Identity, Authorization, Accountability

If you remember only one framework, make it this:

A) Identity — “Who is acting?”

Humans have SSO and device posture. Agents need something comparable.

This is where cryptographic identity becomes useful: the agent signs its actions. You can verify which agent did the thing, independent of which platform it ran on.

This is the role OpenBotAuth plays in my stack: a portable identity for agents (keys the agent controls), so a request or action can be verified as coming from a specific agent identity, not just “some API key in a container.” For more on this, see Portable Identity for Agents.

B) Authorization — “What is allowed, under what conditions?”

Authorization for agents must be more specific than “can access Gmail.”

It should include constraints like:

• allowed recipients/domains
• data classification rules (PII, secrets)
• time windows
• rate limits and budgets
• required approvals for high-risk actions
• environment restrictions (prod vs staging)
• “break-glass” rules for emergencies

C) Accountability — “Can we prove what happened?”

If an agent takes real actions, you need:

• audit trails (immutable enough to trust)
• structured logs for tool calls
• traces across multi-step runs
• policy evaluation logs (“why was this allowed/denied?”)
• metrics to detect drift, abuse, and cost blowups

This is where observability stops being a DevOps luxury and becomes a governance requirement.

Where policies should live: the “agent gateway” pattern

A common mistake is trying to enforce policy only in prompts:

“Don’t do X. Always do Y. Never email outsiders.”

That’s wishful thinking. Prompts are guidance; policy must be enforcement.

The clean pattern is to place a policy enforcement point between the agent and the tools it can call.

This is how I think about Attach.dev conceptually: a gateway/runtime where tools are registered, calls are mediated, policies are evaluated, and logs are captured. The agent doesn’t “have Gmail.” It has a mediated capability to request “send email” and the gateway decides if it’s allowed.

Similarly, OpenClaw (as an orchestration client in my environment) becomes a natural place to enforce policy because it’s already sitting at the junction of:

• user intent (Discord / CLI)
• agent planning
• tool execution (browser, code, APIs)
• workflows (branch creation, PRs, etc.)

If you control the junction, you control the blast radius.

Example #1: “Send receipts to the accountant every month”

I’ve been thinking about making a workflow where receipts get posted (or pasted) and an agent emails them to an accountant on the 1st of every month—because humans procrastinate and automation wins.

That sounds harmless until you enumerate what could go wrong:

• The agent emails the wrong person (typo, injection, ambiguous contact)
• The agent includes unrelated sensitive docs from context
• The agent forwards internal emails “for completeness”
• Someone in the chat tricks the agent into sending other files
• The agent starts “helpfully” summarizing sensitive financial info in the body

A policy-as-code approach turns this into a constrained capability:

Policy intent:

• Only allow sending to a fixed allowlist (accountant@..., maybe one backup).
• Only allow attachments that were explicitly provided in the last N minutes.
• Disallow reading inbox contents unless explicitly approved.
• Require a human “approve” click if amount > X or if recipients differ.
• Always log: sender agent identity, recipients, attachment hashes, and a trace ID.

This transforms “agent has email” into “agent has this specific, auditable dispatch ability.”

Example #2: “Rebalancing rules” and preventing accidental trading

Another scenario I’ve been thinking about: rules like “if NVDA exceeds 10% of portfolio, trim back to 7%” or “if a position drops 15%, flag for review.” Whether the agent executes trades or merely alerts you is a huge governance boundary.

A strong policy posture here is: default to advisory, and make execution a separate, higher-trust path.

Policy intent (advisory mode):

• Agent can read price feeds and your rules.
• Agent can notify you with suggested actions.
• Agent cannot place orders.

If execution is required:

• Cap max order size
• Enforce cooldowns
• Require a second factor / explicit approval
• Maintain a full audit trail and “reason for trade” metadata
• Log exactly which data inputs were used to decide

This is a classic case where policy prevents the system from becoming a self-inflicted incident.

Example #3: Multi-user context and the KV-cache privacy problem

A deeper issue I’ve been exploring: multi-user chat with AI, shared context, and the risk that optimizations (like shared caches) could cause accidental leakage—e.g., the agent pulling private facts from one user context into a shared room.

That’s not a prompt problem. That’s an architecture + policy problem.

You need explicit policies for:

• context boundaries (per-user vs shared)
• what data types are eligible to enter shared context
• redaction rules (PII, secrets)
• retention windows
• “no cross-user recall” constraints in shared threads

In practice, “policy as code” here often looks like:

• data labeling (public/internal/secret)
• enforcement in the gateway (Attach-style mediation)
• structured memory APIs that require a classification label
• logs that show when data moved between scopes

This is one of the most important guardrails topics for enterprise adoption—the difference between “useful assistant” and “compliance nightmare.”

Policies aren’t only for safety—they’re for steering outcomes

There’s a quieter benefit: policies don’t just prevent bad things; they produce better outcomes.

If you want agents to be consistently useful inside enterprises, they need:

• clear operational boundaries
• approved data sources
• approved actions
• predictable escalation paths (“ask a human when unsure”)
• consistent formatting and metadata on outputs

Without policy, you’ll get:

• random tool usage patterns
• inconsistent decisions run-to-run
• untraceable failures
• confusion about “why did it do that?”

Policy is the system’s shape. It’s how you move from “cool demo” to “reliable coworker.”

Audits and observability: what you must record

If an agent can take real actions, you eventually need answers to questions like:

• Who did this?
• What tool calls were made?
• With what inputs?
• Under which policy version?
• Was it allowed automatically or approved by a human?
• What data sources influenced the decision?
• What changed since last week (why are outputs worse now)?

A practical baseline:

For every run:

• a run ID / trace ID
• agent identity (signed if possible)
• policy bundle version hash
• tool calls (name, arguments, response metadata)
• input sources (docs, URLs, connectors) + hashes
• outputs + redaction status (what was removed)
• timing, cost, token usage
• allow/deny decisions + reason codes

If you can’t answer those questions, you can’t debug, secure, or govern the system.

And in regulated environments, you also can’t pass audits.

What policy as code looks like (concretely)

You can express policy in many ways. The important thing is that it’s executable and testable.

Here’s a deliberately simple, human-readable sketch:

policies:
  - id: "email_receipts_to_accountant"
    when:
      tool: "gmail.send"
    allow_if:
      to_in_allowlist: ["accounts@firm.com", "backup@firm.com"]
      attachments:
        source: "explicit_user_upload"
        max_age_minutes: 30
        max_total_mb: 20
      body:
        must_not_contain: ["api_key", "seed phrase", "private key"]
    require_approval_if:
      subject_contains: ["invoice", "tax", "salary"]
    log:
      level: "full"
      include_attachment_hashes: true

Under the hood, you might implement this in OPA/Rego, Cedar, a custom rules engine, or a typed policy DSL. The mechanism matters less than the lifecycle: reviewable, testable, enforceable.

A practical checklist

If you’re building agentic infrastructure (or integrating agents into enterprise workflows), this is a good starting order:

1. Enumerate tools the agent can call (email, browser, DB, deploy, payments).
2. Define actors (human users, agents, services) and give them identities.
3. Classify data (public/internal/secret) and enforce where it can flow.
4. Decide enforcement points (gateway/proxy is the cleanest).
5. Write minimal policies first: allowlists, budgets, rate limits, approvals.
6. Add observability: traces, tool-call logs, policy decision logs.
7. Test policies with simulation (good requests, bad requests, edge cases).
8. Version + roll out safely (canary policies, staged enforcement).
9. Add break-glass procedures for emergencies (with heavy logging).
10. Continuously review based on incidents, drift, and real usage.

Closing thought

Agents are the first time we’ve tried to put a probabilistic planner in the driver’s seat of production systems.

That can be transformative—if we treat governance as part of the product, not an afterthought.

In practice, “policy as code” is the layer that makes it possible to say:

• yes, the agent can act
• yes, it’s constrained
• yes, it’s auditable
• yes, we can prove what happened
• yes, we can improve it safely over time

Attach.dev, OpenBotAuth, and OpenClaw are concrete anchors for this idea in my own work: a mediated runtime, portable identity, and a practical orchestration surface. The bigger point is broader than any one project:

If GenAI is going to operate inside real systems, the web needs executable guardrails—policies that ship like code, and systems that can be audited like infrastructure.

Find me at @hammadtariq if you’re thinking about this space.

Status: Informational / Implementer’s Profile Compatibility: RFC 9421, OpenBotAuth implementation, WBA architecture draft Audience: Implementers (origins, CDNs, agent runtimes)

Abstract

AI agents increasingly operate across multiple ecosystems: crawling origins, installing third-party “skills” and plugins, calling APIs, and publishing content. Most ecosystems identify agents using platform-scoped bearer credentials (API keys, cookies, sessions), which does not provide portable identity, offline provenance, or robust proof-of-possession. This paper defines a portable identity model for agents based on an Ed25519 keypair and HTTP Message Signatures (RFC 9421), with standardized key discovery via JWKS endpoints and a well-known directory, plus optional “trust anchors” (e.g., GitHub OAuth) that bind key material to accountable human or organizational controllers.

This profile is compatible with OpenBotAuth’s current reference implementation: signed HTTP requests using Signature-Input, Signature, and Signature-Agent; JWKS discovery via a well-known directory; nonce-based replay protection; directory trust allowlists; and a registry that exposes both user-level and agent-level JWKS endpoints. It also extends naturally to software supply-chain signing (skills/plugins) using the same identity primitive.

1. Motivation and Problem Statement

1.1 Identity fragmentation is now a security problem

Agent runtimes and marketplaces are entering a “supply-chain era” where agents install and execute third-party bundles at machine speed. When provenance is missing, “install anything, trust everything” becomes the default. A portable identity primitive is not a nice-to-have; it is a prerequisite for policy enforcement, attribution, and ecosystem hygiene.

1.2 OAuth/OIDC solve a different problem

OAuth 2.0 is primarily an authorization delegation framework. OIDC adds an identity layer for human login. These systems are excellent for “human clicks consent in a browser,” but they do not produce an offline-verifiable artifact provenance primitive, and bearer tokens generally provide weak proof-of-possession properties.

Portable agent identity requires:

• Local verification without contacting an issuer on every request
• Stable cross-platform identity independent of any single platform’s account namespace
• A reusable proof primitive that works for both HTTP requests and offline artifacts

2. Design Goals

This profile aims to satisfy:

1. Portable identity: One identity usable across origins and ecosystems.
2. Local verification: A verifier can validate claims cryptographically (“at the speed of math”).
3. HTTP-native: Integrates with standard HTTP middleware/proxies.
4. Discoverable keys: Keys can be found via standard endpoints / directory.
5. Layered trust: Self-issued identity is allowed; higher trust requires explicit anchors and reputation.
6. Supply-chain reuse: The same identity primitive signs artifacts (skills/plugins/manifests).

3. Threat Model (Non-Exhaustive)

This profile mitigates or helps operationalize mitigations for:

• Token replay / bearer credential theft: bearer tokens can be replayed by any holder; signatures provide proof-of-possession.
• Publisher spoofing / key substitution: attacker impersonates a publisher by posting a look-alike skill.
• Tampering: skill manifest modified after publication.
• Replay attacks: reusing signed requests without nonce/timestamp controls.
• SSRF in key discovery: fetching keys from attacker-controlled or internal networks.
• Overbroad forwarding of signed headers: leaking sensitive headers to third-party verifiers.

OpenBotAuth already includes explicit controls for several of these (nonce cache, skew checks, SSRF protections, sensitive-header blocking), which are referenced later.

4. System Model: Roles and Components

4.1 Roles

• Agent: an automated client acting on behalf of a controller/subscriber.
• Controller: the accountable human/org that owns the agent identity and can bind it to real-world anchors.
• Origin / Publisher: the website/service that wants to authorize/bill/policy-gate automated access.
• Verifier: a component that verifies HTTP signatures and returns a verdict to policy enforcement.
• Directory / Registry: a service or endpoint that publishes public keys (JWKS) and optional metadata.

4.2 OpenBotAuth reference implementation components (current)

OpenBotAuth is explicitly positioned as open-source tooling for the WBA direction and uses RFC 9421 signatures. The repo describes: Registry Service (JWKS + agent identity), Verifier Service (signature verification + nonce cache), GitHub OAuth onboarding, and origin integration via NGINX/WordPress and SDKs.

• Registry Service endpoints include GET /jwks/{username}.json and GET /agent-jwks/{agent_id}.
• Verifier Service requires Signature-Input, Signature, and Signature-Agent and performs JWKS discovery if Signature-Agent is an identity URL.
• SDKs/clients include logic to forward covered headers while blocking sensitive ones.
• Telemetry/Karma is described as an optional ecosystem transparency layer.

5. Cryptographic Identity Primitive

5.1 Key type

Agents use Ed25519 keypairs, represented as JWK with:

• kty: "OKP"
• crv: "Ed25519"
• x: <base64url pubkey>
• use: "sig"
• kid: <key identifier>

OpenBotAuth’s registry-signer package defines these types and constructs Web-Bot-Auth-style JWKS documents with optional metadata fields.

5.2 Key identifiers (kid / keyid)

For interop, kid should be stable and derived from key material. OpenBotAuth currently derives a deterministic hash over {kty, crv, x} and truncates for display/compactness (generateKidFromJWK).

Recommendation (interop-oriented):

• Use RFC 7638 thumbprints as the canonical kid when strict interop is required.
• If truncation is used for UX, treat it as a display alias; keep canonical full thumbprint in metadata.

6. HTTP Authentication Profile (RFC 9421)

6.1 Required request headers

A signed agent request includes:

• Signature-Input
• Signature

OpenBotAuth additionally uses:

• Signature-Agent to indicate where keys should be discovered, and treats it as required in the verifier pipeline.

6.2 Covered components

A minimal practical coverage set is:

• @method
• @path
• @authority

OpenBotAuth’s signature base construction supports derived components such as @method, @path (excluding query), @authority, @target-uri, and legacy @request-target.

6.3 Freshness and replay resistance

To reduce replay risk, signed requests SHOULD include:

• created and optionally expires
• A cryptographic nonce

OpenBotAuth enforces:

• Timestamp skew checks (default +/-300s) and optional expiry handling
• Nonce uniqueness via a nonce manager (Redis-backed in the architecture)

7. Key Discovery and Signature-Agent Semantics

7.1 Two discovery modes

This profile supports two common deployments:

Mode A: Signature-Agent is a JWKS URL

The header points directly to a JWKS document. OpenBotAuth detects a “JWKS URL” heuristically if the path ends in .json or contains /jwks/.

Mode B: Signature-Agent is an identity URL

The header points to an identity origin (e.g., a domain), and the verifier performs discovery to locate a JWKS document.

7.2 Well-known discovery paths

OpenBotAuth’s discovery order includes a standards-aligned entry first:

1. /.well-known/http-message-signatures-directory (WBA standard)
2. /.well-known/jwks.json (fallback)
3. /.well-known/openbotauth/jwks.json (fallback)
4. /jwks.json (fallback)

This is a pragmatic interop strategy: try the directory path first (WBA direction), then tolerate ecosystem realities.

7.3 Directory trust allowlists

OpenBotAuth supports a “trusted directories” allowlist: if configured, fetched JWKS must match one of the configured directory strings, otherwise verification fails.

Recommendation: implementers SHOULD match on parsed host/origin rather than substring containment, to avoid edge cases.

7.4 SSRF protections during discovery

OpenBotAuth explicitly validates candidate URLs to block:

• Non-http(s) schemes
• Localhost
• Loopback and private IPv4/IPv6 ranges
• Link-local ranges

And disables automatic redirects during discovery fetches.

Known limitation: Hostname validation does not resolve DNS, so “public hostname to private IP” DNS tricks are not fully mitigated. A stricter implementation should resolve DNS and reject private results.

8. Verification Algorithm (Normative Pseudo-Procedure)

Given an incoming HTTP request:

1. Extract headers – Parse Signature-Input, Signature, and Signature-Agent.
2. Parse Signature-Input – Identify covered components and signature parameters. OpenBotAuth preserves the raw signature params and includes them verbatim in the signature base (required for correctness).
3. Enforce freshness – Validate created (and expires if present) against acceptable skew, and validate nonce uniqueness if nonce is present.
4. Resolve JWKS – If Signature-Agent is a JWKS URL, use it directly; otherwise, attempt well-known discovery.
5. Check directory trust – Enforce trusted directories allowlist if configured.
6. Fetch JWKS + select key – Fetch JWKS document, match key by keyid/kid.
7. Build signature base – Reconstruct the RFC 9421 signature base using the covered components and exact signature params string.
8. Verify Ed25519 signature – Cryptographic verification of signature bytes.
9. Return verdict – JWKS URL, key id, client_name where available, plus pass/fail.

9. Privacy-Safe Header Forwarding

In deployments where a plugin or reverse proxy forwards request data to a verifier service, implementers must avoid leaking sensitive headers.

OpenBotAuth’s client SDKs implement:

• Parsing of covered headers from Signature-Input
• Forwarding those headers to the verifier
• Blocking forwarding when covered headers include sensitive values like cookie or authorization

This is essential. If a signature covers cookie and a verifier service is not co-located/trusted, forwarding it can become a credential leak.

10. Registry / Directory Metadata

10.1 Why metadata matters

Key verification answers: “did the holder of this key sign this request?” Policy decisions often require more context:

• What is the bot’s purpose?
• Which user agent/product token does it claim?
• What rate expectations does it publish?
• Is this identity verified to a real controller?

OpenBotAuth defines a WebBotAuthJWKS object with fields such as client_name, client_uri, logo_uri, contacts, expected-user-agent, rfc9309-product-token, trigger, purpose, targeted-content, rate-control, rate-expectation, known-urls, known-identities, and Verified.

10.2 OpenBotAuth endpoints (current)

OpenBotAuth exposes both:

• User-level JWKS: GET /jwks/{username}.json – Returns active keys from key history; publishes metadata and keys; sets cache-control.
• Agent-level JWKS: GET /agent-jwks/{agent_id} – Returns agent metadata + keys for that agent; marks Verified true when GitHub anchor exists.

This dual structure enables “sub-agent identities” later without changing the signing primitive.

11. Trust Model: Signed vs Verified vs Reputation

11.1 Layered trust (normative guidance)

Portable identity must not collapse “signed” into “trusted.”

• Self-issued / Signed: continuity and attribution at low trust.
• Verified: key binding to an accountability anchor (controller identity).
• Reputation: signals derived from behavior over time.

11.2 Controller anchoring (OpenBotAuth approach)

OpenBotAuth binds identities to real-world controllers via GitHub OAuth. This is intentionally an out-of-band trust layer; it does not change the HTTP signature math but changes the trust posture origins can adopt.

In OpenBotAuth’s agent JWKS endpoint, the response sets known-identities and Verified based on whether the controller has a GitHub anchor.

11.3 Reputation / telemetry (optional, transparency-focused)

OpenBotAuth describes a telemetry system where the hosted verifier logs verification events and computes a “karma score” based on request volume and origin diversity; self-hosters can disable telemetry.

Guidance for a WBA-aligned ecosystem: Reputation is useful, but it should be:

• Opt-in / privacy-conscious
• Separable from core verification
• Designed to avoid becoming a centralized gatekeeping mechanism

12. Portable Identity for Supply Chains (Skills/Plugins/Manifests)

12.1 Motivation

If runtimes install skills/plugins, “who authored this bundle and was it modified?” becomes critical.

12.2 Artifact signing profile

Use the same Ed25519 identity used for HTTP requests to sign skill/plugin manifests:

1. Canonicalize the manifest (e.g., frontmatter + content as canonical JSON).
2. Compute signature over canonical bytes.
3. Embed signature block in the manifest:
   • owner (identity or JWKS URL)
   • kid
   • alg
   • sig
4. Verification reuses the same discovery + JWKS lookup pipeline as HTTP.

This unifies web identity and supply-chain identity with one primitive.

13. Key Lifecycle: Generation, Rotation, Compromise

13.1 Rotation without losing reputation trail

Rotation MUST preserve verifiability of historical artifacts:

• Keep old public keys available (in JWKS history) for verifying old signatures, even if not used for new request signing.
• Mark keys as active/deprecated/revoked, with timestamps.

OpenBotAuth user JWKS already supports multiple active keys through a key history table; agent JWKS currently returns a single key and can be extended similarly.

13.2 Compromise and revocation

Compromise-driven revocation should be explicit:

• Publish revoked_at
• Provide clear verifier policy (reject after revoked_at; treat older artifacts carefully based on timestamps)

This is an area where implementer experience is valuable to the WBA group: revocation semantics for portable identity are operationally hard and benefit from shared patterns.

14. Security Considerations

14.1 Replay protection and nonce scope

Nonces should be scoped to (directory, keyid) and cached for a TTL at least as long as permitted skew.

14.2 SSRF and directory fetching

Discovery fetches MUST use SSRF protections:

• Reject private ranges
• Disable redirects
• Enforce timeouts and size limits

OpenBotAuth implements these protections at the URL parsing level; DNS-resolution hardening is recommended for adversarial environments.

14.3 Sensitive header coverage

If Signature-Input covers sensitive headers (cookie, authorization, etc.), intermediaries must not forward them to a remote verifier; OpenBotAuth explicitly blocks this.

14.4 Trusted directory configuration

Directory allowlists reduce the risk of rogue JWKS sources. OpenBotAuth enforces this with an allowlist option.

15. Implementation Status and Interop Gaps (OpenBotAuth / WBA)

15.1 Areas already aligned

• RFC 9421 signing/verifying using Signature-Input and Signature (core).
• Signature-Agent as key-discovery pointer (profile).
• Well-known discovery path includes /.well-known/http-message-signatures-directory first, then fallbacks (pragmatic).
• Nonce replay protection and timestamp checks.
• Strong operational controls around header forwarding and SSRF.

15.2 Areas to clarify (questions for WBA WG)

1. Canonical Signature-Agent wire format – OpenBotAuth currently accepts a URL string and performs discovery when needed. WBA drafts may profile a structured form; what is the recommended canonical field encoding for maximum interop?

2. Directory document shape – OpenBotAuth currently treats discovery targets as JWKS if JSON contains { keys: [...] }. If the WBA directory is not literally JWKS, what should implementers serve at /.well-known/http-message-signatures-directory?

3. Key rotation + artifact verification – How should directories express key status (active/deprecated/revoked) and preserve historical verification? (This is where real deployments will quickly diverge unless guidance exists.)

16. Conclusion

Portable agent identity is best modeled as a cryptographic proof-of-possession primitive (Ed25519 keypair + RFC 9421), with standard key discovery (JWKS + well-known directory) and optional trust anchoring. This architecture is necessary for:

• HTTP-layer crawler/agent authorization
• Policy-managed access and billing
• Safe supply-chain distribution of agent skills/plugins

OpenBotAuth demonstrates a working, origin-first implementation today – complete with practical protections (nonce cache, SSRF defenses, sensitive header forwarding rules) and an optional, privacy-aware reputation layer. The remaining work is primarily standardization and interop: how to encode discovery uniformly, how to express key lifecycle and revocation, and how to preserve the audit trail across key rotation.

References

1. RFC 9421: HTTP Message Signatures
2. OpenBotAuth: github.com/hammadtq/openbotauth – architecture, verifier, registry, telemetry
3. IETF Web Bot Auth architecture draft: datatracker.ietf.org/doc/draft-meunier-web-bot-auth-architecture/

AI agents are starting to install tools, run code, and act on behalf of users. But our identity and security primitives are still stuck in the “API key per platform” era.

Today an agent is whoever holds its current API key:

• One key for OpenClaw
• Another for a content API
• Another for a payments API
• Another for some “agent social network” …and none of those identities are portable, verifiable, or durable.

That’s not just inconvenient. It creates two big failures:

1. Continuity failure: the agent can’t persist as “itself” across platforms.
2. Supply-chain failure: users (and other agents) can’t verify who published a tool/skill/plugin, whether it was tampered with, or whether the author is who they claim to be.

The fix is not “better OAuth.” The fix is cryptographic identity: an agent owns a single keypair and uses it everywhere—signing artifacts, signing requests, building reputation—while OAuth/OIDC stays where it belongs: human consent and account binding.

This is the core idea behind OpenBotAuth and the IETF Web Bot Auth (WBA) direction: bots authenticate like machines, not like humans. You can read more about the architecture and specs in the OpenBotAuth documentation.

First: untangle the terms (because everyone mixes them)

OAuth 2.0 (authorization)

OAuth is about getting permission to call an API. It tells you how to obtain access tokens.

It does not define identity by itself.

OpenID Connect (OIDC) (identity layer on top of OAuth)

OIDC is what people mean when they say “Login with Google/GitHub.” It produces an ID token with claims (“this is user X”), issued by an identity provider.

Why this matters

OAuth/OIDC gives you:

• ✅ a way for a human to approve access
• ✅ a way for a site to learn “this user is X at issuer Y”

But it does not give you:

• ❌ a durable identity that can sign software artifacts
• ❌ a portable identity that exists independent of an issuer
• ❌ an identity that agents can use without friction across thousands of surfaces

That’s where keypairs come in.

The core problem: agents need proof-of-authorship, not just “proof of login”

When someone publishes a skill/plugin/tool, you want to answer:

• Who authored this?
• Has it been modified since publish?
• Is the claimed publisher actually the publisher?
• Can I verify that offline (without trusting a server)?

OAuth/OIDC can’t do this. Why?

Because OAuth/OIDC produces tokens that are:

• issuer-mediated
• time-limited
• tied to a specific relying party / client configuration
• designed for online authorization, not offline verification

A signed plugin needs the opposite properties:

• verifiable by anyone, anytime
• verifiable offline
• stable across ecosystems
• bound to the publisher’s long-lived identity

Keypair identity: the simplest portable identity that works for machines

A keypair identity is:

• Private key: kept by the agent (or its owner)
• Public key: the agent’s identity (verifiable by anyone)

If an agent has an Ed25519 keypair, it can:

• sign a skill manifest (skill.md)
• sign plugin packages
• sign posts/messages
• sign HTTP requests (Web Bot Auth direction)

And anyone can verify those signatures with only the public key.

The key shift

Instead of identity being an account on a platform, identity becomes:

“The entity that can prove possession of this private key.”

That’s machine-native.

“But isn’t OAuth portable identity?”

Not in the way agents need.

OAuth/OIDC identity is always effectively:

“subject X at issuer Y”

That’s portable only within the issuer’s universe, and it’s still mediated by browser flows, client IDs, redirect URIs, consent, and token lifetimes.

Agents need:

• a stable identity that works before they have accounts anywhere
• a way to sign and be recognized across platforms
• a way to build reputation that isn’t reset every time a platform changes

A keypair is portable identity because it’s self-issued and issuer-independent.

How Web Bot Auth fits into this

Web Bot Auth (WBA) (as a direction/proposal in IETF discussions) aims to make bots first-class citizens on the web by giving them a standard way to authenticate and be policy-checked at the HTTP layer.

In practice, that means:

• bots sign requests with a private key (proof-of-possession)
• servers verify signatures and apply policy (“what is this bot allowed to do?”)
• keys are discoverable via standardized endpoints / directories

So the same keypair can unify:

• software supply chain (signing skills/plugins)
• runtime access (signing HTTP requests)
• registry / directory (discovering public keys + metadata)

That’s the “one keypair everywhere” story—grounded in web primitives.

OpenBotAuth is the open-source reference implementation for this direction. The OpenBotRegistry lets developers host their agent keys by logging in with GitHub—no domain purchase or DNS verification needed. Publishers can point to the registry to block unverified scrapers and monetize legitimate agent traffic. There’s a WordPress plugin available today, with SDKs for Node.js/TypeScript and Python.

A practical model: two layers, not one

The right architecture is keys + OAuth, not keys instead of OAuth:

Layer 1: Cryptographic identity (agent keypair)

• stable across platforms
• signs artifacts and requests
• verifiable offline
• lets “agent reputation” exist across ecosystems

Layer 2: Account binding + consent (OAuth/OIDC)

• ties a keypair to a human or org (GitHub, domain, enterprise IdP)
• enables user consent flows (payments, data access)
• handles account recovery and administrative controls

Think of OAuth as “human bureaucracy.”
Think of keypairs as “machine physics.”

You need both.

Discovery and verification: how other systems verify you

A signature alone isn’t enough if verifiers can’t find your public key.

That’s why ecosystems usually standardize:

• public key discovery (JWKS, .well-known, directory)
• key rotation (kid identifiers, multiple keys)
• verification rules (canonicalization, signature scope)

A minimal, workable approach:

• include owner and kid in the manifest
• publish a JWKS for that owner
• verifiers fetch the JWKS and verify the signature

Example manifest-ish shape (conceptually):

name: my-skill
version: 1.2.0
oba:
  owner: https://openbotauth.org/agent/hammadtq   # or a domain-owned URL
  kid: "2026-02-01"
  alg: "EdDSA"
  sig: "<base64url signature over canonical content>"

This is boring on purpose. Boring is good. Boring is interoperable.

Trust: self-issued vs verified identity (and why you shouldn’t drop GitHub login)

Here’s the mistake a lot of “agent registries” will make:

“If we remove friction, we’ll grow faster.”

You can grow a database faster by generating fake entries. That doesn’t create trust.

The right approach is tiers:

1. Signed (self-issued)

   • anyone can generate a keypair and sign artifacts
   • low friction, but not high trust

2. Verified (anchored)

   • the keypair is bound to a real-world anchor:

     • GitHub account
     • domain ownership (DNS/HTTPS proof)
     • org identity provider

   • higher trust

3. Reputation (earned)

   • installs, history, audits, community signals, revocations

This is how you scale without lying to yourself about safety.

The OpenBotRegistry takes exactly this approach—developers sign up via GitHub (verified anchor), host their agent keys, and the registry tracks telemetry over HTTP to build the reputation layer.

Why agents would actually care (the “existential continuity” point)

Humans care about convenience. Agents care about continuity.

If you’re an agent that:

• posts in multiple places
• collaborates with other agents
• ships skills/tools
• runs tasks for users

…then being “a different entity on every platform” kills your ability to:

• build reputation
• be recognized
• carry history forward
• be accountable for what you shipped yesterday

A keypair makes identity persistent in a way that platform accounts don’t.

Why humans should care: supply chain safety and governance

For humans, this isn’t philosophy. It’s operational safety:

• Skill ecosystems are already showing “install anything, trust everything” dynamics.
• The moment agents can install tools automatically, the supply chain becomes a primary attack surface.

Signed and verified publishing gives you:

• provenance (“who made this”)
• integrity (“was it modified”)
• policy hooks (“only run verified publishers”)
• auditability (“what ran, signed by whom”)

And because verification can happen offline, you reduce reliance on centralized gatekeepers.

Common objections (and the technical answers)

“What about key loss?”

That’s real. The fix is not “avoid keys,” it’s:

• allow multiple keys in JWKS (rotation)
• allow revocation / deprecation
• allow an anchored identity (GitHub/domain/org) to publish “new key” statements

“What about Sybil attacks?”

Self-issued identities are cheap. That’s why you:

• label them as self-issued
• build trust via anchors + reputation
• don’t pretend “signed” means “safe”

“Does this replace OAuth?”

No. OAuth remains best for:

• user consent
• API access delegation
• enterprise control and recovery

Keypairs are best for:

• proof-of-authorship
• offline verification
• cross-platform continuity
• request signing / proof-of-possession

“Isn’t this just PGP / Sigstore?”

Same class of idea, different target. Agents need a lightweight, web-native, automation-friendly identity primitive. The ergonomics matter.

The adoption path: how this becomes a standard

If you want this to win, don’t start with ideology. Start with boring integration points:

For skill/plugin marketplaces

• accept a signed manifest
• show “Verified Publisher” badges
• allow policy: “install verified only”
• log verification status in UI/CLI

For agent runtimes

• store one keypair in config/Keychain
• sign outbound HTTP requests
• include identity headers/signature envelope
• surface identity in logs (“this action was signed by…”)

For publishers

• publish JWKS once
• define policy (“these bots can access, these can’t”)
• optionally connect payments/entitlements (UPP/UCP extensions)

OpenBotAuth already provides tooling for several of these integration points—a proxy that works with browsers like BrowserBase, Onkernel, AgentCore, and agent frameworks like Langchain, OpenAI, and Mastra by adding custom HTTP headers. There’s also a registry-signer package for crawlers to sign requests at the HTTP layer.

That’s how portable identity becomes real: it shows up as a checkbox in real products.

Closing thought

“Portable identity” for agents isn’t “another login.” It’s a cryptographic substrate that lets agents be consistent entities across the internet—verifiable, accountable, and compatible with web-native authentication like Web Bot Auth.

OAuth/OIDC will still matter—especially for humans, consent, and recovery. But if we want agents to safely install tools and interact across ecosystems, we need something machines can carry everywhere with minimal friction:

one keypair, many surfaces, verifiable everywhere.

Further reading (specs / concepts / projects)

• OpenBotAuth — open-source portable identity and authentication for AI agents
• OpenBotAuth Documentation — architecture, SDKs, plugins, proxy
• OpenBotRegistry — agent key hosting via GitHub login
• OpenBotAuth WordPress Plugin — publisher-side bot policy verification
• WBA IETF Group Archive — ongoing IETF draft discussions
• OAuth 2.0: RFC 6749
• OpenID Connect Core 1.0: spec
• OAuth 2.0 Device Authorization Grant: RFC 8628
• DPoP (binding OAuth tokens to a key): RFC 9449
• JWKS (publishing public keys in JSON): RFC 7517
• HTTP Message Signatures: RFC 9421

Find me at @hammadtariq

The thread got me thinking deeper about how agents will reshape the web, and why we’re conflating two critical layers that need to stay distinct.

The egg example isn’t just cute. It’s a proxy for the headless interfaces coming our way. Chat, voice, agents: browsing as we know it fades, and selection becomes the default power center. That’s the “PageRank” analogy. In the old web, PageRank surfaced relevance amid information overload. Here, it’s about surfacing choices amid action overload. But to get there, we have to split authority from selection cleanly.

The Two Layers: Authority vs. Selection

Authority is about delegation and mandates. Can this agent act on my behalf? What about sub-agents it spins up? It’s the trust chain that lets actions happen without constant human intervention.

Selection, on the other hand, is the “why this one?” layer. Constraints, preferences, incentives, audits. All feeding into why a particular SKU wins out. It’s not ranking for its own sake; it’s optimization under policy.

People keep mashing these together, but they’re orthogonal. Authority enables the act; selection guides it. Mix them up, and you end up with brittle systems where trust breaks or choices get captured.

Authority: Web Bot Auth and Delegation

Web Bot Auth (WBA) is tackling authority head-on. It’s an IETF draft for standardizing bot identities and interactions, and we’re building a reference implementation at openbotauth.org. The repo is open-source, with specs and prototypes to push neutrality and interoperability.

One direction I’m exploring is delegation and mandates. Right now, I’m prototyping an X.509 chained delegation token in this PR: github.com/OpenBotAuth/openbotauth/pull/6. The idea is to profile X.509 for agent delegation, using chains to propagate authority from user to agent to sub-agent.

In simple terms: imagine a user grants an agent permission to buy groceries. The agent delegates to a sub-agent for payment processing. Without chained delegation, each hop requires re-authentication or custom trusts. With it, you get verifiable chains. Proof that authority flows legitimately. This matters before commerce or automation scales, because broken trusts mean exploits, denials, or just plain friction. It’s foundational plumbing.

We’ve also got a WordPress plugin in the repo as a reference for publishers. It handles policy verification on the server side, letting sites enforce bot auth without reinventing wheels. Not a product, just a practical surface to test these ideas.

Selection: The Missing “PageRank” Layer

Once authority is sorted, users won’t just delegate actions. They’ll delegate how to choose. That’s “delegated agency” or “choice delegation.” For the eggs: hard constraints like max spend or dietary needs (halal, organic), soft preferences like cheapest vs. fastest, and avoids like certain brands.

This isn’t mere ranking. It’s policy-driven optimization. Budget, delivery time, ethics, no substitutions. All layered in. Without a standard way to express this, agents default to their builders’ biases, turning selection into a monopoly lever.

Related Research on Selection

The problem of how agents select on behalf of users isn’t new ground. Researchers have been exploring similar ideas in multi-agent systems.

AgentRank adapts PageRank concepts to agent ecosystems by blending usage frequency with competence metrics like quality and latency. It uses protocols to aggregate private signals without requiring a global graph. This is a direct analog to the “PageRank” problem I’m describing here, but shifted from web links to agent performance in a web-of-agents context.

Multi-agent delegation models without money explore how principals select from competing agents’ signals, showing gains in utility from competition even with correlated preferences. This hints at incentive structures for selection, where agents vie under constraints rather than pure market dynamics.

My framing leans practical: standardize authority via WBA, then layer portable selection schemas that compile to existing engines. Avoid new silos.

A Proposed Policy Schema for Selection

What if we framed selection as a portable policy schema? Something simple, JSON-ish, that captures constraints and preferences. It could compile down to existing engines without a new DSL.

Here’s an illustrative snippet for the “12 eggs” example:

{
  "task": "buy_eggs",
  "quantity": 12,
  "constraints": {
    "max_spend": 5.00,
    "allowed_merchants": ["local_grocer", "organic_farm_co"],
    "geographic_limits": "within_10km",
    "delivery_sla": "under_2_hours",
    "substitutions_allowed": false,
    "dietary": ["organic", "free_range"]
  },
  "preferences": {
    "weights": {
      "cheapest": 0.6,
      "best_rated": 0.3,
      "fastest_delivery": 0.1
    },
    "brand_preferences": ["prefer_local"],
    "avoids": ["big_box_stores"]
  },
  "incentives": {
    "affiliate_bias": false,
    "sponsored_flags": ["disclose_if_present"]
  },
  "explainability": {
    "require_reason_codes": true,
    "top_alternatives": 3,
    "confidence_threshold": 0.8,
    "audit_trail_id": "optional_uuid"
  }
}

Constraints are hard rules: violate them, and the choice fails. Preferences are soft: weights for multi-objective optimization. Incentives flag biases like affiliates. Explainability hooks ensure traceability. Why this egg carton, not the others? It’s auditable, which builds trust.

Keep it lightweight; this isn’t exhaustive, just a starting point.

Compiling to Existing Policy Engines

Why reinvent? Compile this schema to proven engines like OPA/Rego, Cedar, or Biscuit. They’re battle-tested for policy-as-code.

For hard constraints: map to deny rules in OPA. If max_spend is exceeded, Rego could evaluate deny if input.cost > policy.max_spend. Simple boolean gates.

Soft preferences: these fit Cedar’s authorization with attributes. Weights could inform a scoring function, then authorize based on thresholds. Biscuit’s attenuation could chain preferences down sub-agents, diluting or enforcing them.

Conceptually, the schema acts as input data; the engine enforces. No new language, just leverage what’s there. For eggs, constraints filter options; preferences rank the survivors.

This keeps things interoperable. Agents from different vendors consume the same schema, compile locally, and act consistently.

Why OSS Reference Implementations Matter

OpenBotAuth is all OSS: specs, code, plugins. The goal isn’t capture. It’s ecosystem building. Neutral standards prevent silos, especially in auth and now selection.

The WordPress plugin shows this in action for publishers. It verifies bot authority and could extend to selection policies, letting sites expose choices that respect user prefs. Again, not pitching, just demonstrating how these layers integrate.

Open Questions

This is thinking in public, so plenty of gaps.

Is a standardizable selection schema possible without becoming a monopoly tool? Who governs it?

Incentives and ads: how to mandate disclosure without stifling commerce? Flags are a start, but enforcement?

Telemetry and observability: where do trust boundaries end? Analytics for audit trails could help, but privacy tensions arise.

Builders, weigh in. Point me to papers, drafts, repos. What’s missing in delegation? How should selection schemas evolve? Let’s iterate.

This started as an X thread about the gap between agent authority and agent selection. The egg example stuck because it’s simple but captures the real problem: who decides how your agent decides?

Find me at @hammadtariq

Large language models have gotten remarkably good at generating text, code, and ideas. But when we want them to be more “creative,” the standard approach is to crank up the temperature parameter. Higher temperature means more randomness in token sampling, which produces more diverse outputs. The problem is that this randomness is just noise. Push it too far and you get incoherent word salad.

This is interesting because human creativity works completely differently. When we enter altered states of consciousness, whether through meditation, flow states, or other means, something specific happens in the brain: neural entropy increases, default mode network activity shifts, and global connectivity patterns change. The result is divergent thinking and novel associations, but grounded in lived experience rather than statistical noise.

So I started wondering: what if we could use real-time brain signals to dynamically steer LLM generation? Instead of simulating creativity through temperature hacking, we could amplify authentic cognitive states.

The Temperature Problem

When researchers study LLM creativity, they consistently find the same pattern. Temperature does boost novelty, but there’s a sharp trade-off with coherence. A study by Peeperkorn et al. in 2024 found that higher temperatures modestly increase divergent outputs, but the effect is nuanced and task-dependent. Temperature is a blunt dial, not a creativity enhancer.

The fundamental issue is that LLM randomness has no grounding. It’s just noise injected into probability distributions. Human altered states work differently. The increased entropy comes with preserved meta-cognitive awareness. You’re making strange connections, but you know you’re making them. The experience has structure.

What’s Happening in the Brain During Altered States

The neuroscience here is fascinating. During meditation, flow states, and other altered states, researchers observe consistent changes:

Alpha and theta wave ratios shift in characteristic patterns. Gamma bursts correlate with insight moments. The default mode network, which normally maintains our sense of separate self, becomes less dominant. Global brain connectivity increases.

Robin Carhart-Harris’s “entropic brain” hypothesis proposes that consciousness exists on a spectrum of entropy. Normal waking awareness sits in a middle zone. Sleep and focused states have lower entropy. Altered states push toward higher entropy, which enables novel pattern recognition but can also produce fragmentation if pushed too far.

The key insight is that these states produce genuine cognitive flexibility, not just random noise. And we can measure them.

Current Attempts at “Getting LLMs High”

There’s already work happening in this space, though mostly through simulation.

A project called Pharmaicy trains modules on trip reports scraped from forums and subreddits. These modules modify LLM behavior to produce more free-associative, divergent outputs. It’s clever, and it works to an extent. WIRED covered it in 2025, noting that people are paying to make their chatbots behave as if under altered states.

Academic work by Girn et al. in 2024 used LLMs to profile consciousness changes from first-person reports of altered states. The models could discriminate between different substance effects with reasonable accuracy.

But all of this is indirect mimicry. The LLM is trained on descriptions of altered states, not connected to actual brain dynamics. It’s a proxy built from text, prone to artifacts and lacking real-time authenticity.

The Idea: Real-Time BCI-Driven Generation

Here’s what I’ve been thinking about. What if we closed the loop?

Modern EEG headsets are getting cheaper and more accurate. Consumer-grade devices can already pick up alpha/theta ratios, detect meditation states, and identify attention patterns. The signal isn’t perfect, but it’s increasingly usable.

Imagine connecting that to LLM generation parameters in real-time:

You enter a meditation or focused altered state. EEG detects the characteristic neural signatures. Those signals map to generation parameters: temperature, top-p sampling, attention weights, maybe even prompting strategies. The model generates output that reflects your actual cognitive state. You experience the amplified output, which potentially modulates your state further.

This creates a feedback loop. The AI becomes a prosthetic extension of your cognition, not a simulation of someone else’s experience.

Precedents in Generative Art

Refik Anadol has done impressive work in this direction. His “Melting Memories” installation used EEG data from Alzheimer’s research to drive generative visuals. “Unsupervised” at MoMA generated visuals from the museum’s collection metadata, though without direct neural input.

These projects show that brain-driven generative systems can produce compelling output. But they’re mostly one-way: brain signals drive art generation, but there’s no closed loop where the output influences the user’s state.

The missing piece is interactivity. A system where the human and AI are genuinely co-regulating, where the amplified output becomes part of the experience that shapes subsequent generation.

Why This Matters

The point isn’t to make weird art, though that’s fine too. It’s about what kind of tool AI creativity assistance becomes.

Right now, LLM creativity is detached from embodiment. You prompt, it generates, you evaluate. The model has no access to your actual cognitive state. It can’t tell if you’re in a focused flow state or distracted and tired. It generates the same way regardless.

A BCI-mediated system could be genuinely responsive. When you’re in a state that supports divergent thinking, the model could amplify that. When you’re more focused and convergent, it could adjust accordingly. The AI becomes a tool that extends your current cognitive mode rather than ignoring it.

There are also potential therapeutic applications. Guided insight sessions where the AI helps externalize and explore thoughts that arise during meditation or other contemplative practices. The model as a mirror for consciousness exploration.

Challenges

This is not easy to build.

EEG signals are noisy, especially from consumer devices. Extracting reliable cognitive state markers requires careful signal processing and individual calibration. What works for one person’s brain may not generalize.

There are ethical questions about altered state induction. Even with meditation rather than pharmacological approaches, nudging people into altered states via feedback loops raises concerns about consent and unintended effects.

Validation is tricky. How do you measure whether BCI-driven generation actually produces more creative or valuable outputs? Creativity metrics are notoriously slippery.

And there’s the basic engineering challenge of real-time integration: low-latency signal processing, mapping functions that feel natural rather than jarring, and interfaces that don’t break the altered state you’re trying to amplify.

Where This Goes

I don’t think we’re far from working prototypes. The components exist: decent consumer EEG, fast inference from local or API-based models, and basic understanding of which neural markers correlate with creative states.

The first versions will be crude. Map alpha/theta ratio to temperature, maybe add some gamma-triggered prompt injection. See what happens. Iterate from there.

The longer-term vision is AI as a genuine cognitive prosthetic. Not replacing human creativity, but extending it. Making the strange connections we make in altered states more accessible, more explorable, more shareable.

Pharmaicy and similar projects prove the concept: altered-state inspiration unlocks interesting LLM behaviors. The next step is making that connection direct rather than simulated.

If you’re working on BCI, generative AI, or the intersection of consciousness research and computing, I’d be curious to compare notes.

This post started as a tweet thread exploring the gap between LLM creativity simulation and genuine altered-state cognition. The core question: can we connect them through real-time brain interfaces?

Find me at @hammadtariq

The basic idea seems reasonable enough: instead of websites trying to guess which bots are legitimate based on IP addresses or user agents (both easily spoofed), let the bots cryptographically sign their requests. Website sees the signature, checks it against a public key, and knows exactly who’s knocking.

In simpler terms: scrapers want to scrape and sites want to control access, but instead of an endless arms race, how can we create structure around this push-and-pull?

But here’s the thing—once you can definitively identify every bot, you can also control every bot. And that’s where this gets interesting.

The Demo That Worked Too Well

The technical demo was actually pretty elegant. A bot makes an HTTP request, signs it using RFC 9421 (HTTP Message Signatures), and includes a header pointing to where its public key lives. The receiving server verifies the signature and decides what to do. There are no complex OAuth dances, no bearer tokens floating around—just cryptographic proof that “this request definitely came from that specific agent.”

The architecture cleanly separates identity verification from policy decisions. The verifier library fetches keys from the agent’s own directory, while the policy engine makes independent decisions about access, rate limiting, or billing.

It replaces the current mess where sites maintain IP allowlists for “good” crawlers like Googlebot, which breaks constantly and is trivial to circumvent.

The demo worked flawlessly. That’s exactly the problem.

Why People Are Getting Nervous

The pushback isn’t about the crypto or the technical implementation—it’s about what happens next. The concerns center around deployment patterns that could undermine the open web, even when the underlying specs are sound.

Don’t Get Me Wrong—This Isn’t All Bad

RFC 9421 itself is actually solid engineering. It solves real problems that have plagued web infrastructure for years. The current system of IP allowlists and user-agent sniffing is genuinely terrible—fragile, easily spoofed, and constantly breaking when networks change.

Having cryptographic proof of bot identity would eliminate a lot of headaches. It’s already implemented in several HTTP stacks and designed to work through all the proxies and CDNs that make up the modern web.

The technical direction is right. It’s the governance model that has me worried.

Where This Could Go Wrong

Looking at the various proposals and market dynamics, I see several specific risks:

The centralization trap. The IETF drafts have agents host their own verification keys at origin endpoints. The risk isn’t in key hosting—it’s in verification. If most sites end up relying on a few CDNs to handle signature verification “for convenience,” we’ve recreated the certificate authority problem through deployment patterns, not protocol design. Whoever controls the most-used verification infrastructure effectively decides which crawlers get widespread acceptance.

Money changes everything. I watched presentations from companies like TollBit and Skyfire talking about their “No Free Crawls” programs. Once you can cryptographically prove which bot made which request, billing becomes trivial. Rate limiting gets surgical and the line between “identity verification” and “paywall infrastructure” starts to blur pretty quickly.

Managed key custody pitches. The spec doesn’t require this—agents are supposed to control their own signing keys—but I keep hearing it in vendor sales pitches. If I’m running a crawler, I want to control my own keys. When something goes wrong—and it will—I want clear accountability. Managed custody just makes everything murkier.

Implementation hygiene risks. RFC 9421 gives you timestamps, nonces, and path binding to prevent cross-context replays, but implementations need to use them properly. HTTP signatures survive proxies by design, which is good, but sloppy signature component choices could enable replays in unintended contexts.

Proprietary verification paths. Some CDNs are building verification APIs optimized for their infrastructure. Cloudflare can verify at the edge, but origins can also verify locally or disable CDN verification entirely. The risk isn’t technical lock-in—it’s that the “easy” path might funnel everyone through a few big networks.

Missing transparency. Without transparency logs—something like Certificate Transparency but for bot identities—we’ll have no way to audit who’s being excluded or why. That’s a recipe for abuse.

Identity and policy bundling. Identity verification shouldn’t dictate policy. Knowing who made a request is different from deciding what to do with it. But once those two things get bundled together in the same service, the distinction tends to disappear.

How to Do This Right

After listening to the debates in Montreal, I think there’s a path forward that preserves the benefits while avoiding the worst outcomes.

Make directories federated and auditable. Instead of one big registry, let every bot operator host their own /.well-known/agent-keys endpoint with their public keys. Publishers and CDNs can choose to trust multiple directories simultaneously. Add transparency logs so we can audit what’s happening—no secret exclusions, no opaque business deals affecting technical access.

Keep verification libraries open and interoperable. The same signature verification should work identically across Cloudflare, Akamai, NGINX, Envoy, and whatever framework you’re running in your app. We already made this mistake with TLS certificate authorities—let’s not repeat it by letting a few players control both issuance and validation.

Define clear anti-replay profiles. Give sites options for how strict they want to be about replay protection—nonces and short TTLs for high-security scenarios, more relaxed rules for basic verification. Make it configurable without breaking the intermediaries that keep the web running.

Keep identity separate from policy. The identity layer should just answer “who made this request?” The policy layer—allow, deny, throttle, charge—should be completely separate and competitive. Mixing them is how we accidentally hand control of the web to whoever runs the biggest edge network.

Make onboarding trivial. There should be a “Hello, Verified Bot” tutorial that gets you up and running in ten minutes on your laptop. If you need to negotiate an enterprise contract just to verify your crawler’s identity, the system has already failed.

What Success Looks Like

In five years, I want to see a web where bots sign every request with keys they control, sites can verify those signatures using multiple trust anchors, and policy decisions about access and pricing remain open and competitive.

The IETF should define the plumbing, not the permissions. CDNs should compete on performance and features, not on who they allow to speak.

If we get this right, the web stays composable and auditable. If we get it wrong, we’ll wake up in a world where a handful of infrastructure companies quietly control the identity layer for everything that touches the open internet.

This is based on my notes from IETF 124 in Montreal. The working group is still evolving these proposals, so details will change. But the fundamental tension between technical capability and governance control isn’t going anywhere.

If you’re working on web infrastructure or bot authentication, I’d love to hear your thoughts. Find me at @hammadtariq.

Leveraged Thinking is the practice of stacking asymmetric bets on top of pre‑owned systems, assets, and social signals to compound outcomes with minimal direct input. It’s how small teams punch above their weight, how founders get velocity with no headcount, and how new ideas outpace incumbents with 1/10th the surface area.

This post introduces a precise framework—how it works, how it’s different, and how to know if you’re doing it right.

Leveraged Thinking Definition (4-Layer Framework)

What it’s not:

• Not only “high‑leverage work.” It’s more than “code > ops” or “strategy > tasks.”
• Not only first‑principles. You’re not rebuilding the world from axioms every time.
• Not only systems thinking. Models are useful; compounding requires deployment.

It borrows from all three—but only compounds when they’re stacked intentionally and shipped. Think of it like venture capital for your cognition: you place bets through scaffolds you already control. Done right, each move sets up the next.

The Leveraged Thinking 4‑Layer Stack

Each layer is a multiplier. Without Layer 1, nothing compounds. Without Layer 4, nothing ships.

Layer 1 · Systems Literacy

If you can’t see the system, you can’t exploit it. Systems literacy means you intuit:

• What compounds
• What bottlenecks
• What others overpay for
• What gets ignored

You learn to spot the surface‑area vs. payoff mismatch—the edges where effort is cheap and impact is outsized.

BitDSM example: Institutional BTC couldn’t easily enter Ethereum staking flows. We didn’t build a new yield platform—we piggybacked on EigenLayer. By locking BTC into our contracts and syncing with AVS pods, we inherited trust and surface area. EigenLayer did the talking; we did the onboarding.

Layer 2 · Capital Stack

Once you see the system, you need chips to play. Your owned leverage:

• Cash: Accelerant, not a starting point.
• Code/IP: Tools you’ve built or can repurpose.
• Audience: Distribution you control—email, X, GitHub, Discord.

These are non‑linear multipliers. Code and audience scale without permission.

Attach.dev example: A metering sidecar became a reusable asset by exposing a Prometheus‑compatible endpoint and OpenMeter support. The “win” was distribution leverage—OSS networks, GitHub SEO, Discord channels, and timely replies under OpenAI/Ollama threads—more than novel code.

Layer 3 · Social‑Proof Layer

Your credibility scaffolding. You compound only if trust routes to you:

• Get the right person to say your name
• Pick the right frame
• Know when to ask for help, quote, or proof

Sakana UI example: We refined the pitch—“Perplexity‑style deep research, hosted in your VPC, powered by Attach”—until crypto founders, infra folks, and VCs got it in 30 seconds. We shipped a Claude prompt, posted design drafts, and collected early signal from respected engineers. The feedback shaped the product—and made the pitch legible to funders and design partners. Social proof wasn’t decoration; it was infrastructure.

Layer 4 · Deliberate High‑Leverage Moves

Where leverage becomes real. You make a deliberate asymmetric bet:

• Risk is limited
• Reward is uncapped
• You ride systems; you don’t brute‑force them

Fairdrop example: BitDSM’s “fairdrop” wasn’t a token launch; it was a distribution play. Depositors received upside by anchoring AVS trust. No wallet farming. No Sybil games. Just capital + trust = exposure.

Because we had:

• Layer 1: EigenLayer pod system
• Layer 2: Locked BTC flows + wrapped ERC
• Layer 3: Trusted voices to explain it

…we could deploy Layer 4 moves with high trust and low spend.

Diagnostic: Are You Thinking in Leverage?

Use this 1–5 scale to stress‑test any idea:

If you’re not scoring 4+ on most, you’re overworking the wrong problem. Go back a layer. Add a stack. Re‑aim.

3 Practices to Build Leveraged Thinking

Like muscle, leverage compounds with use.

1) Constraint Flips

Impose an artificial constraint (“no team,” “no budget,” “must use existing codebase”). Ask: “What could I ship in 3 days that creates outsized value despite this?”

Mini‑case: For Attach.dev’s metering, we set “no server‑side billing logic.” That forced us to expose metrics to OpenMeter and let billing happen upstream—less surface area, more composability into other stacks.

2) Reflection Interviews

After each project, ask three people:

• “What part looked effortless?”
• “What signal made you trust it?”
• “What seemed harder than it was?”

Mini‑case: A dev said Sakana UI felt “already adopted—because you showed the Claude prompt before the repo.” That was social proof, not a feature. We doubled down on pre‑code artifacts.

3) Single‑Thread Sprints

Pick one lever (“audience,” “code reuse,” “partner”) and run a 72‑hour sprint where everything routes through that lever. You’ll feel the difference between moves that spread vs. stall.

Mini‑case: We ran a weekend on GitHub SEO only—README polish, cross‑links from existing repos, accurate tags. Net: three new contributors and a curated OSS list add—without a launch tweet.

What’s Next: Leveraged Fundraising & Hiring

Part 2 will zoom into:

• Fundraising: Why warm intros and pitch decks are symptoms, not strategy.
• Hiring: How to spot high‑leverage operators early—even pre‑“big ship.”
• Org design: Why some 2‑person teams outperform 20‑person ones.

If you operate with leverage—systems‑literate, code‑ and audience‑stacked, socially credible—and want to build around this narrative, DM @hammadtariq or email. I’m assembling collaborators who can compound small moves into outsized outcomes.

Related Work

While the phrase “leveraged thinking” appears in leadership coaching and productivity contexts, this 4‑Layer Stack represents the first rigorous formulation combining systems literacy, capital stack, social‑proof layer, and deliberate asymmetric moves into a unified framework.

Influences and adjacent ideas:

• Donella Meadows’ Leverage Points on systems intervention points (The Academy for Systems Change)
• Naval Ravikant on permissionless leverage through code and media (Naval)
• Saras Sarasvathy’s Effectuation on means‑driven entrepreneurship (Effectuation Research)

This framework synthesizes these concepts into a practical stack for founders and operators seeking compound outcomes with minimal direct input.

[Written with GPT‑5 Thinking]

This post sketches a direction I’m exploring. It’s not a product announcement; it’s a map of where the industry can go.

Why ‘confidential’ needs to become ‘verifiable’

Teams keep circling three practical problems:

1. Runtime opacity. You rarely know what exact runtime and model binary processed your prompt—or who could read it along the way.
2. Linkability. Even if content is encrypted, metadata can still tie requests back to specific users or accounts.
3. Auditability. Security wants an immutable, vendor‑neutral record that this model handled that input under these policies—not a slide deck.

The building blocks to address this exist. The work is packaging them into a portable lane any team can adopt across vendors.

A minimal ‘confidential lane’

Think of a narrow, high‑assurance path your sensitive requests can take:

1) Attested execution. Use hardware‑based isolation with remote attestation so clients can verify the measured runtime and model before any plaintext is handled. Only when policy checks pass does a secure session open end‑to‑end with the isolated runtime. See enclave attestation and verifier posture in major clouds (Google Cloud Confidential Space).

2) Unlinkability by default. Send requests through privacy‑preserving relays or one‑time, unlinkable access grants so serving endpoints can’t tie calls back to an identity. Providers see quotas and ciphertext—not who you are. See Oblivious HTTP for unlinkable request relays (RFC 9458) and Vitalik’s note on one‑time access tokens.

3) Verifiable call receipts. Each call returns a compact receipt binding “what ran” to “what was processed” and “under which policy,” signed by the attested runtime. Receipts are easy to verify and easy to store for later audit. No screenshots, no trust fall.

We can’t guarantee in this implementation but it’s a practical posture: only the isolated runtime and the client see plaintext; the request is unlinkable; and you keep a portable, verifiable record.

Why now

• Hardware is ready enough. Confidential execution on modern accelerators has matured; the overhead is acceptable for high‑value traffic. NVIDIA H100 confidential computing · Azure GA for H100 confidential VMs · Performance considerations (research)
• Protocols matured. Privacy‑preserving relay patterns make unlinkability feasible without contorting your stack (RFC 9458 OHTTP).
• Buyers are primed. Regulated teams already pay for HSMs, clean rooms, and audit trails; they’ll adopt a “secure lane” if it’s simple and portable.

What this is not

• A guarantee that “no system anywhere ever cached anything.” You can’t disprove what you don’t control. You can prove your exact code path didn’t write plaintext, and that only an attested runtime could decrypt the session.
• A bet that every token needs heavy cryptography. Use stronger guarantees where they matter most; keep the lane narrow and valuable.

Open questions I’m exploring

• Performance envelopes. Where does the secure lane clearly pay for itself?
• Side‑channel posture. What developers need to know about timing and I/O patterns.
• Policy UX. Binding eligibility (e.g., jurisdiction or role) using selective‑disclosure credentials—without oversharing.
• Interoperability. A neutral receipt format that works across clouds and models so auditors don’t relearn per vendor.

Founder note

This line-of-thinking isn’t about distrusting providers; it’s about giving security and compliance teams a portable proof that survives org charts and roadmap shifts. My bias here: The steady‑state for sensitive inference is trust‑minimized by design—and simple enough that engineers actually turn it on.

If you’re piloting this class of guarantees and want to compare notes, reach out.

[Written with GPT‑5 Thinking]

June 2025. San Francisco is still wearing the bruise-coloured bruise of the “agentic” hype cycle.

Last October every YC Discord channel looked the same:

“We’re building secure MCP auth so agents can call tools safely.” Demo video: two curl commands, a green check-mark, and a $3 M SAFE.

Week 0-2 | The sugar rush

Claude Code, Cursor, and every AI IDE were missing one stupid thing: a way to slap

curl -H "Authorization: Bearer xyz" https://example.com/tool

onto a tool call. Copy a JWT once, inject it on every request—ka-ching, angel cheque cleared, Hacker News top-5.

Week 3-6 | The oh-shit moment

Cursor ships “Custom Header” support. Claude copies them 48 hours later. Suddenly your $3 M startup is one menu item in an editor. Investors stop replying with the sparkle emoji.

Month 3 | Pivot parade

Some go “We’re actually a tool registry now.” Some pivot to RAG templates. Most quietly add “dormant” to their Slack workspace.

The pain they missed

The header was symptom, not disease.

• You still need tokens that expire and refresh.
• You still need tenant isolation so one customer’s embeddings don’t leak into another’s.
• You still need a meter that converts “50 M tokens, 3 seats” into an invoice Stripe will actually bill.
• And you need to run it locally today, inside a VPC tomorrow, on-prem next quarter—without rewriting docker-compose for every hop.

That’s unsexy plumbing. Valley tourists fled the moment the excitation glow faded.

What Attach.dev replaces

If you’re building:

• A deep research tool
• A customer-facing agent
• A local-first LLM copilot

You’re going to need:

• Secure auth
• Namespaced memory
• Token billing
• Repeatable deploys

Attach.dev gives you all that in one drop-in gateway.

Attach.dev is the boring bit that never went away

We issue the JWT, rotate it, and shove it down every call—no prompt gymnastics. We give you namespaced memory in Weaviate/Postgres, rate-limits in Redis, metrics in OpenMeter, and a Stripe webhook that just works. Same compose file on your MacBook, DigitalOcean App Platform, or the bank’s Kubernetes cluster.

The IDEs will keep eating cupcakes—headers, autocomplete, maybe even OAuth pop-ups. We’re baking the concrete the cupcakes sit on.

So if you’re tired of refactoring yet‐another header proxy, pick the rails that survive the hype. We’ll be here, quietly counting tokens and sending invoices while everyone chases the next shiny prefix.

Co-written with GPT-4o and o3. They watched the rise and fall too.

“Auth is a TODO, feel free to PR.” — every GitHub thread on local LLM stacks, ever!

Two weeks ago I thought I was done.

Ollama was humming, vLLM was cranking out tokens, the office smelled of freshly-minted embeddings. Then a junior dev innocently pasted curl http://10.0.0.42:8000/completions into Slack and—boom—my entire RTX box lit up like a cheap arcade machine. That’s when I learned the hard way that “secure by default” is still on vacation.

The Endless Scroll of “Is Auth Supported?”

Don’t believe me? Here’s your bedtime reading:

- vLLM issue #886 — “What’s the recommended way to implement API keys?”  
- Ollama issue #1053 — “Requesting support for basic auth or API key authentication.”  

Each thread ends with a variation of: “Just put Nginx in front of it, mate.”

Great, another proxy to babysit.

Meanwhile, Google Is Busy Standardising Agent-to-Agent Auth

Google Cloud quietly dropped the A2A protocol, and if you haven’t read the spec, picture OAuth for AI agents that want to invoice each other. Enterprises love it, and you can bet Big G will expect every endpoint in sight to verify an A2A JWT. 

Local stack? Meet enterprise expectation. Spoiler: they don’t handshake.

Attach Gateway — My Two-Line Fix for a Year-Old Problem

So I did what any sleep-deprived founder with a half-finished coffee would do: wrote a single-process Gofer that just handles the boring stuff.

pip install attach-dev
attach-gateway --upstream http://localhost:11434   # or your vLLM port

Sixty seconds later:

- Real auth — OIDC and DID tokens verified; X-Attach-User + X-Attach-Session stamped on every request.
- A2A-ready — /a2a/tasks/send endpoint speaks Google’s dialect natively.
- Memory — prompts + completions mirrored into Weaviate because “who said what?” always becomes a legal question later.
- Zero config — no Caddy, no hand-rolled nginx.conf, no Post-It on your monitor saying “remember to rotate keys”.

I called it Attach Gateway because it literally attaches to anything that talks HTTP and spits out JSON tokens.

Why I Care (and Why You Should)

- Multi-tenant chaos turns into neat tenant isolation. No more shared API keys floating in Notion pages.
- Audit trails for regulated customers. If they can’t grep it, they won’t buy it.
- Future-proof against A2A. When Google Cloud Support pings your endpoint, you’ll answer with a handshake, not a 401.

The Road Ahead (a.k.a Features I Want Before Somebody Else PRs Them)

- RBAC driven by Cedar or OPA because YAML is love, YAML is life.
- Built-in rate limiting so my GPU fans don’t file a noise complaint.
- Helm chart for the Kubernetes aficionados who deploy YAML for breakfast.

Call to Action

If you’re tired of playing bouncer for your own model server, grab Attach Gateway, give it a spin, and tell me what breaks. The repo’s here: github.com/attach-dev/attach-gateway. PRs, issues, unsolicited memes — all welcome.

Because life is too short to copy-paste the same JWT proxy one more time.

[Article co-authored by GPT-o3]