I have been using Hermes with Codex.

Each kanban card takes 15 to 18 minutes to complete. I am neurotic when it comes to code quality, so I let it run.

While I waited, I had ARM and Intel charts open in another tab.

That is where this piece comes from.

The market figured it out first

The names that should be losing the AI trade are winning it.

Some receipts from the last few months:

• ARM: up roughly 84% YTD
• Intel: up roughly 240% YTD, up 500% in twelve months
• AMD: up roughly 112% YTD
• Nvidia: up roughly 15% YTD

Mizuho called it “a changing of the guard in AI.” That is the right phrase.

For three years the AI infrastructure narrative was simple: more GPUs, faster GPUs, bigger GPU clusters. The model was the constraint. Everything else was plumbing.

That narrative has cracked.

Intel surged 30% in a single day on Q1 earnings, with the CEO openly saying CPU-to-GPU ratios are moving from 1:8 toward parity. ARM’s data center royalties more than doubled year-over-year for the third quarter in a row. AMD’s Lisa Su told investors the server CPU TAM is now projected to grow over 35% annually to more than $120 billion by 2030. She doubled that forecast in six months.

The market priced in something the AI press took a year longer to admit.

What I converged on watching Hermes

Watching a coding agent run is a strange exercise. You stop looking at the output log and just notice the latency.

Most of it is not the model.

The model does its thing in a couple of seconds. Then the rest happens somewhere I cannot see. The agent spins up a sandbox to try the code. Reads files. Parses JSON. Decides whether to retry. Calls another tool. Waits on a vector lookup. Hands off to a sub-agent. Writes back to memory.

Each step is tiny. Each task has thousands of them. None of them parallelize on a GPU.

This connects to something I wrote about after ICLR: the model is no longer the whole product. The system around the model is.

And that system runs on a CPU.

Put those two thoughts together, and the ARM and Intel charts stop being a market quirk. They are pricing in a hardware truth that has been visible from inside the agent loop for months.

What “the system runs on a CPU” actually means

Arm’s own framing is the cleanest version of this. In its FY26 earnings letter, the company said data centers will need 4x current CPU capacity per gigawatt as agentic AI scales. Multi-agent systems push token generation up by roughly 15x per user. Across most agentic workloads, 50% to 90% of end-to-end latency happens on the CPU side, between the inferences.

That is not a marketing pivot. That is a budget reality.

GPUs do inference. CPUs do everything between the inferences. In an agentic system, “everything between the inferences” is most of the wall-clock time.

This is why Hermes takes 15 minutes. This is why ARM is up 84%. It is the same fact, observed from two different chairs.

How this gets resolved

Two phases.

Phase 1: more CPUs, better CPUs.

This is what the market is already trading. ARM AGI CPU (136 Neoverse V3 cores, custom silicon, $2 billion in FY27/FY28 demand from Meta, OpenAI, Cerebras, and others). Intel’s data center segment growing 22% on agentic demand. AMD EPYC Venice with 256 Zen 6 cores. NVIDIA’s own Vera CPU, Arm-based, paired with Rubin GPUs. Google Axion, Microsoft Cobalt, Amazon Graviton at $20B+ run rate.

If the bottleneck is CPU orchestration in a fixed power envelope, then for the next 12 to 24 months the answer is to throw better general-purpose CPUs at it. That is the trade the market is making right now.

Phase 2: custom silicon for the hot parts.

Once the general-purpose CPU push has done what it can, the next question becomes which parts of the agent loop are stable enough and hot enough to burn into a chip.

My bet on three:

• Retrieval and reranking. A memory-attached accelerator does roughly 20x more queries per watt at scale. Academic prototypes (ANNA, Falcon, Chameleon) have already shown the ceiling. This is the only one of the three with a real standalone business.
• Sandbox creation. Every tool call needs a fresh isolated environment. Today that is around 100ms of overhead per call. Hardware-enforced capability switching, the CHERI line of work, can take it to microseconds. Across one agent task, seconds saved.
• Constrained output. The part that forces the model to emit valid JSON or code. Small. Hot. Regular. Better licensed as IP than sold as a chip.

These do not need to ship as three separate products. They get absorbed.

Why the AGI chip eats this anyway

Hardware trends usually start as accelerator cards and end up as IP blocks on a single SoC. GPUs absorbed dedicated rasterizers. SoCs absorbed image signal processors, video codecs, NPUs. The TPU started as a side project and is now central to Google’s compute.

The same will happen to agent-loop silicon. The retrieval engine, the sandbox MMU extensions, and the constrained-decode FSM are all small enough in die area that the next generation of AGI chip — whoever ships it, ARM or Nvidia or Meta or someone we have not heard of yet — pulls them onto the same package as the model accelerator. Probably alongside an HBM tier sized for the KV cache and the vector store.

That is the long shape:

CPU is the bottleneck → custom accelerators emerge → accelerators get pulled into a single die → the agent loop becomes a hardware-native primitive

When that happens, “running an agent” stops being a fan-out of services across CPU, GPU, and storage. It becomes a single chip doing all of it.

What this means for startups

This is the part that matters most if you are building.

A large fraction of the current agentic startup landscape is tooling. Tools the agent calls. Wrappers around agents. Integrations the agent invokes. The entire “MCP server for X” surface area.

That category gets eaten in two ways.

First, by the speed of the loop itself.

If a coding agent today takes 4 to 16 hours to build a moderately complex tool, the same tool gets built in 4 to 16 minutes within 12 to 18 months. CPU speedup alone does not deliver that. Stack the CPU work with better base models, parallel sub-agents, cached patterns from prior runs, and improved harnesses, and 50x to 100x on end-to-end task time is realistic. The agent loop compounds the way a compiler pipeline compounds.

Second, by the agent itself choosing whether to build or reuse.

Once an agent can write a tool faster than a human can ship the integration, the agent writes the tool. The decision to call your SaaS becomes a build-vs-buy decision the agent makes in milliseconds. If your moat is “we built the connector to X,” the half-life of that moat shortens every quarter.

The harder, longer-lived layer is the core AI work:

• the model itself
• the harness around the model
• the memory and state layer
• the evaluation and reward signals
• the policy and identity layer (this is where I have been spending time with Attach and OpenBotAuth)
• the data that feeds it
• the infrastructure that the model cannot generate on its own

These are the parts that do not fall to faster CPU loops. They are also the parts most agentic startups are not focused on.

I have been saying versions of this for a while, in the policy-as-code piece and the memory piece. The CPU and silicon angle makes it sharper. The faster the agent loop gets, the more value moves to the parts the agent cannot generate by itself.

What I am watching

A few signals over the next two to four quarters:

1. Whether ARM’s AGI CPU ships on time and lands at hyperscalers. Supply is the bottleneck on the bottleneck. Reuters flagged this on the Q4 call.
2. Whether a sovereign or regional cloud announces a near-memory retrieval accelerator. Gulf, Singapore, EU. These are the buyers who care about watts-per-query and cannot wait for the hyperscalers to build internally.
3. Whether a CHERI-style capability extension lands in a commercial ARM Neoverse core. That is the path for sandbox isolation to move from research to production silicon.
4. Whether anyone bundles constrained-decode acceleration into an inference appliance. Groq, Cerebras, SambaNova are the natural homes.

The shape of the next bottleneck

The last AI hardware war was about training models.

The next one is about running agents.

The chips look different. The companies winning look different. And the startups that survive will be the ones building the parts the agent cannot build on its own.

That is the convergence I saw watching Hermes work through a kanban card with ARM and Intel charts open in another tab. Same picture, two screens.

Find me at @hammadtariq if you are thinking about this.

Article drafted in conversation with Claude.

I left thinking memory is only one part of a bigger shift.

The field is moving from models that answer to systems that maintain state, act, evaluate themselves, and improve over time.

That is the signal I took from Rio.

1. The model is no longer the whole product

One of the clearest patterns was that the harness is becoming a first-class object.

In the industry talks, this was obvious. Zillow’s agent architecture was not presented as “we call an LLM and hope it works.” It was a full agent harness: knowledge layer, action layer, user understanding, skills, sub-agents, planning, memory, policy, and execution loops.

The LLM was swappable.

That is the important part.

GPT, Claude, open-weights — they plug into the system. The system is the thing being engineered.

This same pattern appeared in research.

AutoHarness is literally about generating code harnesses around agents. Instead of only improving the model, it improves the wrapper that constrains, guides, and executes behavior.

ADAS — Automated Design of Agentic Systems — pushes this further: define the agentic-system search space in code, then let AI search for better agent architectures.

That is a different mental model.

2. RAG is becoming too small a word

RAG retrieves chunks.

Memory maintains state.

That distinction kept coming up again and again.

A lot of the memory work at ICLR was not just “retrieve more context.” It was trying to answer deeper questions:

• What should be remembered?
• What should be compressed?
• What should be forgotten?
• What should be retrieved now?
• What should become persistent state?
• What evidence supports a memory?
• How does memory change over time?

AssoMem framed memory as associative retrieval, not just semantic similarity. The point is simple: cosine distance is not enough. Human memory links things through time, importance, relevance, context, and association.

MEM1 pushed the same idea from another angle: long-horizon agents cannot just append all past turns forever. They need a compact internal state that helps memory and reasoning work together.

Limited Memory Language Models externalized factual knowledge into a database during pretraining instead of burying everything inside opaque weights.

Evoking User Memory split retrieval into something closer to human cognition: fast familiarity and slower recollection.

HippoRAG and the MemAgents talks kept coming back to a biological intuition: memory is not a pile of text. It is an active mechanism for finding, linking, and using past experience.

3. Memory is becoming part of self-improvement

The most interesting version of memory is not passive.

It is not just:

store → retrieve

It is:

experience → reflect → update memory → retrieve better next time → improve behavior

That is where memory and recursive self-improvement start to touch.

Jeff Clune’s MemAgents keynote made this explicit. His talk connected memory to a much broader open-endedness agenda: POET, AI-generating algorithms, OMNI-EPIC, ADAS, HyperAgents, ALMA, and The AI Scientist.

The strongest pattern was not “AI improves itself” in some vague sci-fi sense.

It was more concrete: automate the search over systems.

• Search over environments.
• Search over curricula.
• Search over agent architectures.
• Search over memory designs.
• Search over scientific hypotheses.

ALMA was the cleanest memory-specific version of this. The premise is blunt: most memory systems are hand-designed, fixed, and brittle. ALMA tries to meta-learn memory designs for agentic systems.

That is a big idea.

Not:

we built a better memory module

But:

the memory architecture itself can be searched over and improved

That feels like a real direction.

4. RSI is becoming boring in a good way

Recursive self-improvement used to sound like a philosophical argument.

At ICLR, it felt more like systems engineering.

There is no single RSI loop. There are many loops:

• code improves
• prompts improve
• memory improves
• tools improve
• data improves
• evaluators improve
• policies improve
• weights sometimes improve

That is the grounded version.

The interesting systems are not necessarily self-improving end-to-end. They are improving some component inside a controlled loop.

This matters because “self-improvement” becomes much less magical when you ask:

What exactly is allowed to change?

• A prompt?
• A memory schema?
• A tool?
• A reward model?
• A policy?
• A dataset?
• A planner?
• A model checkpoint?

That is where the work is.

And the hard part is not just improvement. It is safe improvement.

• How do you prevent reward hacking?
• How do you prevent memory corruption?
• How do you know the system improved instead of overfitting the evaluator?
• How do you roll back a bad update?

That is where the next tooling layer will appear.

5. World models are about consistency, not just generation

World models were another major signal.

The shallow version is:

generate future video

The deeper version is:

maintain a consistent model of the world across time, action, and viewpoint

That is much harder.

The ViewRope world-model poster made this very concrete. The problem is not just making plausible frames. The problem is geometric consistency: if the camera moves, rotates, revisits a place, or closes a loop, does the world stay the same?

Latent Particle World Models attacked the problem from the object side: object-centric stochastic dynamics, particles, masks, actions, and goals.

These are different techniques, but the same direction: agents need stable internal state about the world.

That is why world models connect back to memory.

• Memory is state over experience.
• World models are state over environment.

Both are about preventing the system from drifting.

A model that cannot maintain state cannot plan well. A model that cannot test its state against reality cannot improve.

6. Science AI looked more real than I expected

The science work was better than I expected.

Not because it was flashy. Because it was constrained.

Hard domains force the model to prove something.

In science, you cannot just sound plausible. You need benchmarks, measurements, physical constraints, experiments, or domain-specific evaluation.

AstaBench was one example: benchmarking scientific research agents across actual research workflows.

The protein binder work was another: generative pretraining plus test-time compute for atomistic protein binder design.

WIND used diffusion for atmospheric modeling, but the interesting part was not “diffusion is cool.” It was using a generative model under physical constraints and inverse-problem structure.

The fMRI-to-image paper was also memorable. The key idea was not just better image generation. It was fixing the first stage: mapping brain signals into a better latent representation before reconstruction.

That is the science pattern: the hard part is often the representation and evaluation layer, not just the generator.

This is why hard-science AI is interesting. It forces the stack to become real.

7. Safety and policy are part of memory

Another thing became clearer to me: if agents have memory, policy cannot be an afterthought.

A long-lived agent needs to decide:

• should this be stored?
• who can access it?
• when can it be retrieved?
• can it be shown to this user?
• should it expire?
• should it be forgotten?
• was it used correctly?

Zillow’s fair-housing / inverse-constitutional-AI framing made this concrete. Static rules are brittle. Real policy boundaries are contextual. The same phrase can be okay in one context and problematic in another.

That means memory is not just storage. It is a policy-gated read/write system.

For enterprise agents, healthcare agents, real-estate agents, finance agents, personal assistants — this is not optional.

Persistent memory without access control, provenance, deletion, and policy is a liability.

So the next memory stack probably has three parts:

1. structured memory
2. retrieval/update policy
3. audit and governance

That is the product-shaped version.

8. The real convergence

The more I walked around ICLR, the more the same pattern kept reappearing under different names.

• Memory people were talking about retrieval, consolidation, state, and forgetting.
• Agent people were talking about harnesses, tools, evaluators, and planning loops.
• World-model people were talking about consistency over time.
• RSI people were talking about systems that update themselves.
• Science people were talking about evaluation, constraints, and closed loops.

These are not separate trends. They are converging.

The next AI stack looks something like this:

model
+ memory/state
+ tools/actions
+ policy gates
+ evaluators
+ world model
+ update loop

The model is still important. But the surrounding system is becoming just as important.

Maybe more important.

What I think comes next

My bet after ICLR:

1. RAG turns into memory infrastructure

Basic retrieval becomes commodity. The interesting layer is persistent, structured, temporal memory with provenance, uncertainty, forgetting, and policy.

2. Agent harnesses become trainable

The harness will not just be hand-coded. It will be searched, optimized, learned, and improved.

3. Memory managers become learned systems

The next memory systems will decide what to store, compress, retrieve, and update.

Not every memory will be a chunk.

• Some will be facts.
• Some will be events.
• Some will be summaries.
• Some will be state.
• Some will be policies.

4. Evaluation becomes core infrastructure

If a system can improve itself, the evaluator becomes part of the product.

Bad evaluator, bad self-improvement.

5. World models and memory start merging

For embodied agents, scientific agents, enterprise agents, and personal agents, the system needs a stable model of what is true, what changed, and what might happen next.

That is memory plus world modeling.

6. Policy-gated memory becomes mandatory

The more useful memory becomes, the more dangerous it becomes.

Safe memory is not just “don’t store sensitive things.” It is contextual access, deletion, retention, provenance, and auditability.

My takeaway

I left thinking the real direction is stateful AI.

The next wave is systems that:

• maintain state
• reason over time
• retrieve the right past
• act through tools
• evaluate outcomes
• update themselves
• and stay within policy boundaries

That is the frontier I saw in Rio.

If you are building, I would not build another thin wrapper around an LLM.

I would build the state layer.

Because once agents become long-lived, memory is not a feature.

Memory is the substrate.

“Claude code should come with a dedicated dependency risk checker. Can’t rely on socket-dev mcp, automatic enforcement is required.”

Two days later I shipped attach-guard.

This post is the full story: what happened to axios and litellm, why AI coding agents make supply chain attacks dramatically worse, and how a single Claude Code hook would have stopped both.

One Week, Two Megapackages, Zero Human Reviewers

axios — March 31, 2026

axios is one of npm’s most depended-upon packages. Over 100 million weekly downloads. On March 31st, somebody hijacked the primary maintainer account (jasonsaayman), changed the associated email to a Proton address, and published two poisoned versions: axios@1.14.1 and axios@0.30.4.

The only change in both: a new dependency — plain-crypto-js@4.2.1. A package that did not exist the day before.

That package ran a postinstall hook executing an obfuscated 4,209-byte JavaScript dropper. The payload: WAVESHAPER.V2 — a cross-platform RAT with command execution, system exfiltration, and persistence capabilities across Windows, macOS, and Linux.

Google/Mandiant attributed it to UNC1069, a financially motivated North Korea-nexus threat actor active since at least 2018.

Socket.dev’s scanner caught plain-crypto-js within six minutes of publication. The malicious versions were live for roughly two to three hours.

Two hours is more than enough when agents install packages autonomously.

litellm — March 24, 2026

One week earlier: litellm, the LLM proxy that half the AI developer ecosystem depends on.

A threat actor known as TeamPCP stole PyPI publishing credentials via a compromised Trivy GitHub Action in litellm’s CI/CD pipeline, then uploaded litellm==1.82.7 and litellm==1.82.8 directly to PyPI — bypassing the normal release process entirely.

The malicious wheel contained litellm_init.pth. If you’re not familiar with Python’s .pth trick: those files execute automatically every time the Python interpreter starts. No import needed. Just existing in site-packages/ is enough.

The double-base64-encoded payload:

• Stage 1: Harvested environment variables, API keys, SSH keys, Git credentials, AWS/GCP/Azure/K8s configs, Docker credentials, shell history, crypto wallets, SSL private keys, CI/CD secrets, and database credentials.
• Stage 2: Encrypted everything with AES-256-CBC + a hardcoded 4096-bit RSA public key, then exfiltrated via POST to models.litellm.cloud — an attacker-controlled lookalike domain, not the real litellm.ai.

Also live for roughly three hours.

The pattern

Both attacks targeted maintainer or CI credentials. Both were live for hours. Both hit packages that AI developers install constantly. And both would have been caught by the same two signals: a suddenly cratered supply chain score and a version younger than 48 hours.

AI Agents Made This Worse

Here’s the part that keeps me up at night.

Claude Code, Cursor, Copilot — they run npm install and pip install autonomously, dozens of times per session. No human squinting at the dependency diff. No one to ask “wait, since when does axios need plain-crypto-js?”

The agent sees a task, decides it needs a package, installs it, and moves on. The entire compromise lifecycle — from npm install to RAT on your machine — happens in the time it takes you to sip your coffee.

“But I have Socket.dev’s MCP server.”

Good. MCP servers provide advisory context. They inform. They do not enforce. The agent can acknowledge the warning, weigh it against the task, and install anyway. That’s by design — MCP is context, not a guardrail.

“What about a skill?”

Skills are instructions the agent follows when invoked. They guide behavior, but they cannot block actions. An agent can skip a skill. It cannot skip a hook.

The gap was obvious: no open-source, local-first guardrail that sits directly in front of the install command and says no.

attach-guard: A Hook, Not a Suggestion

attach-guard is a Claude Code PreToolUse hook that intercepts package installation commands and evaluates them against policy before execution.

The distinction matters:

A security guardrail must be a hook because enforcement requires interception at the tool-call boundary, before the command ever runs.

How it works

When Claude calls the Bash tool with something like npm install axios:

1. Claude Code fires the PreToolUse hook before execution
2. The hook pipes the tool input JSON to attach-guard hook via stdin
3. attach-guard parses the command, queries Socket.dev for risk scores
4. Returns a decision: allow, ask (with explanation), or deny (blocked)
5. On internal errors, exits with code 2 to fail closed

Smart version replacement

Most security tools just say “no.” attach-guard says “no, but here’s a safe alternative.”

When a risky version is blocked, attach-guard finds the newest version that passes policy and offers it as a replacement:

> npm install axios

attach-guard evaluates:
  axios@1.14.1  →  DENY (supply chain score 40, below threshold 50 — compromised)
  axios@1.14.0  →  ALLOW (supply chain score 71, passes all policy checks)

Result: ASK + rewritten command
  "npm install axios@1.14.0"

Claude sees the safe alternative and proceeds immediately. Your flow doesn’t stop — it gets redirected to a safe path.

Your flow only fully stops when there is genuinely no safe version to offer.

Multi-ecosystem

attach-guard supports npm and pnpm today, with pip, go get, and cargo add shipping now — covering all four ecosystems where these attacks happened. The litellm attack was a PyPI compromise; the axios attack was npm. Same guardrail, both covered.

What Would Have Happened

Let’s rewind the clock.

axios — with attach-guard installed

Your agent decides it needs axios and runs npm install axios.

1. attach-guard intercepts the command before execution
2. Resolves latest version: axios@1.14.1
3. Queries Socket.dev: supply chain score 40 — well below the deny threshold of 50
4. DENY. The install never runs.
5. attach-guard walks back through recent versions, finds axios@1.14.0 with a score of 71
6. Returns an ASK with a rewritten command: npm install axios@1.14.0
7. Claude proceeds with the safe version. WAVESHAPER.V2 never touches your machine.

litellm — with attach-guard installed

Your agent runs pip install litellm.

1. attach-guard intercepts the command
2. Resolves latest: litellm==1.82.8
3. Queries Socket.dev: flagged as known malware, supply chain score in the floor
4. DENY. The .pth payload never lands in your site-packages/
5. Falls back to litellm==1.82.6 — the last clean version
6. Your API keys, SSH keys, and cloud credentials stay where they belong

Both attacks would also have been caught by the 48-hour minimum age policy — both malicious versions were brand new, published hours before detection. attach-guard denies versions younger than 48 hours by default.

Every decision gets logged to a local JSONL audit trail — who, what, when, why, and which policy rule fired. When your security team asks “were we affected?”, you have the receipts.

Two Commands, Done

claude plugin marketplace add attach-dev/attach-guard
claude plugin install attach-guard@attach-dev

That’s it. The hook, config, and skill are all registered automatically. You’ll need a Socket.dev API token (free tier available) — Claude Code will prompt you during setup.

Once running:

• Automatic enforcement — npm install, pnpm add, pip install, go get, and cargo add commands are intercepted and checked
• /explain <package> — look up any package’s risk score, alerts, and version history from inside Claude Code
• Configurable policy — tune score thresholds, allowlists, denylists, and age requirements in ~/.attach-guard/config.yaml

Full docs and source: attach.dev/attach-guard

Because life is too short to let your AI agent install a North Korean RAT while you’re getting coffee.

Find me at @hammadtariq.

[Article co-authored by Claude]

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]