It happens in situations where correctness isn’t about first principles but about what everyone else does.

If enough people converge on the same wrong answer, their agreement makes it right. These are coordination problems, and they trip up smart people constantly.

A little game

Everyone picks a number between 0 and 100. The winner is the one closest to two-thirds of the average.

If people guess randomly, the average will be about 50, so the winning number is 33. If you think harder, you realize other people will too, so you pick 22. And if you keep going (imagining an infinite chain of reasoning) the logic collapses to 0.

But people don’t reason infinitely. When economists run this experiment, the winning guesses cluster in the 20s or 30s. Sometimes the person who barely thought about it, who just said “30,” wins.

The correct answer depends not on logic in isolation but on how far everyone else reasons. In those cases, a naive player is usually right.

I call this expectations lock-in: the “right” choice is where most people stop thinking.

You see this in real life more often than people expect. Think about parties: people don’t carefully weigh which event has the best music or food. They go where they believe most others will go. If enough people expect the same party to be popular, they all show up, making that belief self-fulfilling.

AI protocol war

The same dynamic is starting to play out in AI. New protocols are emerging for how models talk to each other and to applications. MCP, (Model Context Protocol) is one example. It isn’t necessarily the most elegant design, but it’s building momentum.

At the same time, people are already starting to OAuth into AI agents, even though agents have very different constraints from traditional software. The tools don’t quite fit, but people use them anyway because they expect others will use that too.

It’s the subtler, pre-adoption phase (before classic network effects) where each choice is a bet on where others will converge.

History suggests the eventual winner won’t be the “best” solution. It will be the one where enough people stop thinking further, converge, and decide “this works”. It’s not just a network effect but the same pattern the guessing game reveals: what matters is where the group converges, not what’s technically best or perfectly reasoned from first principles.

Entrepreneurs and investors especially need to be careful. Picking the “best” technology too early can leave you building in a vacuum. The trick is not just to think deeply, but to think socially. To ask not only “What’s correct?” but “What will most people decide is correct?” Sometimes the winning move is to anticipate where others will stop thinking, and meet them there.

That’s why OAuth may end up everywhere. And why some AI protocol will soon define the future, whether or not it’s the most elegant.

Be cautious

The lesson isn’t that reasoning is useless. It’s that reasoning in coordination problems has to include what other people will reason. If you stop at first principles without asking how far others will go, you risk ending up alone.

Startups live in the space between what’s true and what people think is true. Our job is to know both.

We don’t know which path they’ll take for a given input. We just know that they seem incredibly powerful, versatile and (un)reliable.

The quick fix is to give your agent broad, long-lived admin creds “just in case.” It’s the same thing new hires try: “make me an admin so I can do my job.” But in real organizations we don’t do that: we gate access, escalate rights carefully, and add process so one person can’t wipe production on day one.

With AI agents we drop that discipline. We hand a probabilistic machine the keys and hope it will only use what it needs. They’re fast, literal, and unpredictable, a combination makes them incredibly useful and incredibly dangerous.

The right unit of authorization for AI isn’t the agent. It’s the task.

Not all tasks are equal

Take GitHub MCP from your editor as an example. It can:

• Commit (low risk, easy to revert).

• Push to main (medium risk, affects everyone immediately).

• Change branch protections / add collaborator (high risk, escalates permissions).

These are all “GitHub actions,” but they carry radically different risks. We can think about tasks in concrete terms: a verb, a resource, some bounds, and a time-to-live.

Each deserves its own scoped, short-lived authority. Github MCP will ask you to OAuth and give the agent access to ALL scopes ALL the time.

If I ask you to commit, you shouldn’t also be able to push. If I ask you to push, you shouldn’t be able to delete. And if I do ask you to delete, that power should extend only to that repo, and only for a few minutes.

Your agent shouldn’t walk around with standing credentials at all. It should assemble just enough permission for the task at hand then drop it.

Meet Wafers

Wafers are portable, layered capability tokens designed for this new world. Instead of giving an agent broad, standing credentials, you “bake” a wafer for a single task: scoped, time-bound, and cryptographically sealed.

Wafers also allow safe delegation. Each holder can narrow it further tightening the scope, shortening the lifetime, or constraining the actions.

An app can hand an agent a wafer trimmed down to exactly what’s needed: “commit this branch in the next 10 minutes.” When the request comes back, the service can verify the full chain of custody and enforce every constraint. No surprise escalations, no hidden standing privileges.

Because wafers are offline and auditable, they fit seamlessly into multi-agent workflows too. Each spawned agent gets only what it needs, nothing more, nothing longer.

If JWTs were made for users, wafers are made for agents. They bring least privilege, traceability, and safe delegation to a class of software that is powerful, unpredictable, and here to stay.

Wafers are open source with the first reference implementation in Go.

If you’re building systems where agents act on behalf of humans, this is your chance to help shape the next layer of the auth stack. Feedback, contributions, and experiments are all welcome.

The mess we are in

The world model in the 90s model was simple: `user → browser → cookie → server session`. Then came scripts and services acting for users. We added API keys, then “fine-grained” tokens, then OAuth.

It worked until the thing acting for you became a generic agent that might need to read invoices now while wire money later.

These systems are incredible useful and because of that people are doing the simple thing that “works today”: handing an agent long-lived admin credentials so it can do whatever you ask it whenever you as it for.

Long-lived admin credentials to complete small task is madness.

API keys don’t work because they’re just blobs of raw power, fine-grained tokens only scope things within a single service’s worldview, and OAuth is a consent dance that falls apart when you try to shoehorn it into agent workflows (just look at the MCP mess). The problem isn’t that people aren’t trying hard enough, it’s that these primitives simply don’t model the new reality of software.

AI agents are different. They’re generic, unpredictable actors. Developers don’t know how to handle it, and so the tension is to block bots (Ahem, Cloudflare) while users keep pushing automation forward because the value is obvious.

We need least privilege, traceable, portable authorization tokes for AI Agents.

Meet Wafers

Wafers are portable capability tokens you can restrict and pass along. If a JWT says who you are, a Wafer says who this request is on behalf of and exactly what it’s allowed to do.

Instead of handing an agent a broad credential that could do anything, you can give it a wafer that carries only the precise actions it needs, bound to a narrow scope and a short lifetime.

A wafer begins its life when a service “bakes” it: the issuer creates a header with an ID, an expiry, and a cryptographic anchor that ties it to the service. From there, each holder can add a layer that only narrows what the wafer permits (tightening the scope, limiting the time window, constraining the actions).

Holders can also pass it on, but only by explicitly naming the next key that’s allowed to extend it. When the wafer finally comes back with a request, the issuer can verify the full chain of custody, check the integrity of every layer, and enforce the accumulated rules.

The lifecycle is simple: bake, layer, hand off, verify. What makes it powerful is that every step is cryptographically sealed, auditable, and offline. That means you can safely give an agent a wafer for one task without worrying it will escalate into another, and you’ll always know exactly who constrained it along the way.

A real world example

Imagine you use a wallet service and want to grant an app permission to spend up to $300 a month. Instead of giving it a long-lived admin key, the wallet issues a wafer tied to your account with that exact limit baked in. The app can use it directly, or it can narrow it further when it delegates work. Suppose the app spins up a small automation to pay a $10 invoice. It hands the agent a wafer scoped to just that merchant, that amount, and a ten-minute window.

When the agent makes the request, the wallet sees the wafer, cryptographically validates the full chain of custody, and checks the caveats. If the agent tries to spend $11, send to a different merchant, or arrive late, the request is denied.

The wallet doesn’t need to know the app or the automation vendor in advance. The wafer itself carries the proof of authority, the constraints, and the trace of who restricted it along the way.

How does it work?

Under the hood, wafers use a mix of symmetric and public-key cryptography. At any moment a wafer has exactly one holder: that holder can add new constraints and, if needed, hand it over to the next owner.

Adding constraints means deriving a shared secret with the end service and sealing the new layer with an HMAC. Handover means nominating the next public key that will be allowed to extend the wafer. The result is an append-only chain where every layer is tamper-evident.

Only the end service can verify the full chain and attest the validity of a wafer. That design choice matters: it lets us rely on fast symmetric crypto for wafers that never change hands, while limiting public-key operations to the moments of handover. And because handovers use shared secrets instead of signatures, they stay lightweight even when agents are creating and passing wafers frequently.

There’s even a variant where the list of holders is encrypted, so each participant only sees their own place in the chain without knowing who came before. This allows privacy-preserving delegation while still giving the issuer full visibility and control when it comes time to enforce a request.

What’s next

AI agents are incredibly useful, and we should expect many more of them in the years ahead. Wafers are a way to update your auth stack for that future. If you already use a policy engine like AWS Cedar, OPA/Rego, or Zanzibar, you don’t need to replace it. Wafers slot right in, carrying the delegation chain and caveats that your engine can evaluate.

If you’re building systems where agents act on behalf of humans, you need a stronger primitive than JWTs or OAuth. This is especially valuable for MCP servers, agent frameworks, and APIs that want to be automatable without handing out admin-level credentials.

The repo contains the canonical implementation of wafers in Go. Encoding isn’t finalized yet, but the plan is to use CBOR (waf.0.{base64enc}) in the authentication header. Contributions are welcome — whether that’s PRs, implementations in other languages, or integrations into your own auth stack.

Cloudflare’s new “signed agents” pitch sounds like safety but it’s a wolf in sheep’s clothing. They’ve built an allowlist for the open web and told builders to apply for permission. That’s not how the internet works. An application form is not a standard.

Yes, identity for agents is a real problem. But Cloudflare is solving it like a border checkpoint. Get on their list or get treated like a trespasser. That’s vendor approval not an internet protocol. An allowlist run by ONE company?

Authentication for that world isn’t “ask Cloudflare for a hall pass.” It’s verifiable chains of delegation and request-level proof: open, portable, and independent of any one company.

The Web Must Remain Open

The web thrived because no one owned it.

In the 90s, Microsoft tried to “embrace and extend” the web, but failed. And that failure was a blessing. Because no single company controlled it, anyone could publish, anyone could innovate, and protocols carried more weight than corporate policies.

We’ve seen this movie before. Open standards beat closed plug-ins. HTML5 and the Open Web Platform displaced proprietary runtimes like Flash (Adobe) and Silverlight (Microsoft). Flash was formally ended in 2020 and Silverlight in 2021, while HTML5 became a W3C Recommendation back in 2014.

The pattern is consistent: when the commons defines the interface, innovation compounds; when a vendor hands out permission slips, it stalls.

Agents Are Inevitable

Agents are inevitable. They will be the next major users of the web: retrieving information, automating workflows, making purchases, negotiating contracts. Sometimes ai agents will be explicitly directed by humans, other times they’ll act as subroutines inside bigger tasks.

The line between human and agent action will blur.

When I’m driving, I hand my phone to a friend and say, “Reply ‘on my way’ to my Mom.” They act on my behalf, through my identity, even though the software has no built-in concept of delegation. That is the world we are entering.

Authentication vs. Authorization

Authentication asks: who is acting?

Authorization asks: what are they allowed to do?

They are not the same. Yet Cloudflare treats them as if a single passport could solve both. It can’t. In the real world, showing a passport is not enough to open a bank account, the actual person must be present!.

The same is true online. A cryptographic signature that claims “I am acting on behalf of X” means nothing unless it is tied to something real, like a verifiable infrastructure or a range of IPs. Without that, I can simply hand the passport to another agent, and they can act as if they were me. The passport becomes nothing more than a token anyone can pass around.

This is why the whole idea of a “bot passport” is deeply flawed.

Authentication and authorization matter more than ever but they must be rethought for the era of agents and for an authentic web.

Authentication

And here’s the truth: on the internet, nobody knows you’re a dog.

A single signature proves nothing if it can simply be passed along. What we need is a way to prove both the chain of delegation and the authenticity of each request. The chain is like a certificate :

User X on Service Y delegated to Agent Z, who delegated to Agent K.

But when Agent K actually makes a request to Service Y, it must add its own signature to prove it is truly Agent K. Without both pieces, authentication collapses.

The system must have a few key features:

• Verifiable: you can check the claim independently.

• Composable: it works across chains of delegation.

• Decentralized: no single gatekeeper decides who is “valid.”

Public key cryptography already gives us a model. Companies prove ownership today through DNS; they could publish public keys in the same way. That would let a service authenticate a third party simply by checking DNS (without anyone filling forms, asking permission, or registering with a central directory). Sites could still blacklist or whitelist as they choose, but the default is open.

This is what authentication for the agentic era should look like: open, verifiable, and decentralized.

Authorization

Until now, software usually had a narrow scope.

Think a weekly cron job that emails a “new signups” report: it gets read-only access to the analytics DB, nothing else. Or a finance app via Plaid to fund your trading account: it can initiate transfers within limits but can’t browse your transaction history.

OAuth scopes worked because the software had a clear, predictable purpose.

Agents are different. They are general-purpose. The same agent might book a flight, pay for dinner, and then summarize your bank statement. They may also be short-lived, spun up for a single task and gone after it.

One way to make this work is to give the agent an “admin key”: full access to everything It’s convenient, but dangerous. We must resist this pattern.

Agents should not hold permanent credentials, authorizations must be per-task, not per-agent.

Think of a bank account: I might tell my agent “pay for dinner.” That token should allow payment. But when I ask “show me three months of spending,” the agent should not be able to move money. Same agent, different task, different token. Credentials must follow tasks, not agents.

Fortunately, cryptography and authorization models have evolved a lot in the last last years. We now have tools that allow us to issue tokens with constraints: granular, short-lived, and delegable (like macaroons or biscuits) and Open policy engines (like OPA or AWS Cedar) can also be used for RBAC/ABAC for this use case.

Imagine:

• User X on Service Y holds an admin token.

• They derive a narrower token for Agent Z to perform one task.

• Agent Z can then derive an even narrower token for a sub-agent, all without bothering the service.

• Each request can be verified against the chain.

Coupled with the authentication model above, this approach gives us a foundation for managing agents without creating new gatekeepers.

Protocols, Not Gatekeepers

This challenge is bigger than Cloudflare, Google, Microsoft or any single company. The future of the web cannot hinge on who controls the keys. We need protocols, not gatekeepers.

Authentication, authorization, and monetization must remain open, interoperable, and standardized.

Cloudflare’s launch is useful only because it exposes the danger. If we let a handful of companies decide which agents are “valid,” the agentic web will collapse into walled gardens. We’ve seen this movie before.

Here’s the line in the sand: I’m open-sourcing a first cut of these ideas chains of delegation, request-level authorization , and task-scoped authorization so anyone can implement them, today.

If this resonates with you, if you want to collaborate, criticize, or help shape the protocols that will keep the web open for agents, please reach out jordi@fewsats.com

The future should not be about who holds the gates. It should be about protocols that let everyone build, share, and innovate.

The Bitcoin revolution has only just begun. The integration of the Lightning Network (LN) has established Bitcoin as the native internet currency, primed to connect a global market without geographic restrictions. This technological advancement brings consumers and producers closer than ever before, allowing for purely digital exchanges involving services, information, and digital products.

Imagine an entrepreneur in Nigeria who develops a SaaS project. S/he can now serve customers in Europe and South America and monetize their project using the Lightning Network. The payments are secure, instant and final. The sats earned from this venture aren't just sitting idle; they can be used to pay for services from providers across Southeast Asia and North America.

This entire operation, spanning continents, occurs seamlessly without the involvement of any third-party intermediaries such as banks or financial institutions. The control over the funds rests with the entrepreneur from the moment the first satoshi hits their account.

Morover, the system's benefits don't stop there. Thanks to the diligent efforts of countless open-source contributors worldwide, the technology has matured significantly. Thousands of developers, irrespective of their experience level, can now set up their own payment gateways within hours. This progress democratizes financial transactions, dismantles barriers, and opens up the global market to anyone skilled enough to deploy code.

Despite Bitcoin's growing maturity, the world hasn't fully realized the potential of this digital revolution. Traditional methods of transaction like credit cards and PayPal, which involve third-party intermediaries, still hold sway. These intermediaries often impose restrictions such as what currency can be used, who can participate in a trade, and even if a transaction can take place or not.

Intelligent Digital Agents (IDAs) enter the room

As we explore the Bitcoin revolution's horizons, there's another player making a grand entrance - Large Language Models (LLMs). The LLMs' breakthrough represents a revolution that's nothing short of transformative. These AI-powered models have brought about a paradigm shift, changing the way we interact with digital technology at a fundamental level.

The LLMs ecosystem is dynamic and rapidly evolving. Every day, we're witnessing an explosion of innovations in the AI landscape. Intelligent digital agents, equipped with the power of LLMs, are becoming increasingly proficient at executing tasks and providing services that were once the exclusive domain of humans.

This progress is attracting considerable capital and intellectual resources. The market for LLMs and associated intelligent agents is burgeoning, with investors and innovators alike recognizing the tremendous potential. We're seeing a decisive shift towards this domain, as individuals, companies, and institutions invest their money and brainpower into harnessing the LLMs' transformative capabilities.

The emergence of LLMs underscores a fundamental truth about the digital age - the world waits for no one. While people are slow in embracing Bitcoin/LN, a storm of innovation is brewing with IDAs at is heart.

A match made in heaven

We are on the verge of a new era dominated by Independent Digital Agents (IDAs). In this new world, people will interact with IDAs in a similar way that a CEO interacts with strategic directives to various departments within a company. Just as a CEO doesn't micromanage every operation but sets high-level objectives and budget restrictions on the department, users will soon issue broad directives. IDAs will then interpret these commands, turning intent into action, much like departments execute a CEO's strategy.

While some envision a future dominated by a single "definitive" AI, I propose a different perspective. I envision a vibrant economy inhabited by millions of IDAs. Much like human society, these agents will specialize, trade, and at times opt to purchase computational services from others instead of self-executing tasks. This intricate, digital economy mirrors the diversity and interconnected-ness of our own human society.

Native digital currency plays a pivotal role in this scenario. IDAs will be tasked with countless computation tasks. From reporting data insights to plan and execute marketing campaings. . Some of this tasks will be performed in the boundaries of the IDAs economy, like reminding a human that need to attend a meeting with a SMS text, while many others will be interactions involving only IDAs.

But how will IDAs perform economic calculation? How will help them deciding which execution path is more optimal? In many cases, prices. IDAs won’t only will have to compute execution paths taking into account price, they will also have to pay (transact) to execute those plans.

Such an economy necessitates a currency. The need for a native digital currency is paramount, and no option embodies this concept better than Bitcoin/LN.

This symbiosis between AI and Bitcoin is the match made in heaven, ready to usher us into the next phase of digital evolution. As we steer towards this future, we anticipate a steep surge in Bitcoin users - and many of them may not be humans.

Imagining the Future

In this future, I see an economy bustling with Independent Digital Agents (IDAs) actively buying and selling their services and computational power. This economy won't emerge out of thin air – it will be constructed upon the robust foundation. After all, we stand on the shoulders of titans.

The Lightning Network (LN), with its high-quality node implementations, liquidity management tools, liquidity markets, and a sturdy, reliable network of nodes prepared to forward payments, provides a resilient infrastructure for this envisioned economy.

Perhaps it's time for us to adopt a new approach while creating our next service. A "machine-first" approach, where the traditional barriers of credit cards, tiered pricing structures, and cumbersome email, password, and phone verification become things of the past.

We can't predict the future with perfect precision, but we can certainly influence its direction. The best way to ensure a future that aligns with our vision is to take the reins into our hands and build it. As innovators, creators, and visionaries, we're not just spectators but active architects of the future. So, let's continue building and shaping the world we wish to see.