RSL 1.0 audit: a licensing layer that ships without prices

Every payment protocol we have audited answers one question: how much. RSL is the first standard that tries to answer the other one — what the agent is allowed to do with what it just bought. We spent a day measuring it, and the price field is empty.

When we took apart edge enforcement at Cloudflare and AWS, we left a gap open. AWS said it plainly: monetization "tells agents how much to pay but not what they're allowed to do with the content." The pointer both edges gave for that missing half was RSL, Really Simple Licensing.

RSL is worth a serious look for one reason that has nothing to do with publishing politics. It is the only standard we have found that puts the access rules, the price, and the payment protocol in a single machine-readable document — and the payment protocol it names is x402. That makes it directly load-bearing for anything that pays per use over HTTP.

So we audited it the way we audit everything here. We read the specification, checked its registrations, crawled the open web for it, fetched every live license document we could find, and drove its license servers. All measurements below were taken on 22 August 2026 and are reproducible.

What RSL 1.0 actually specifies

The RSL 1.0 specification carries the status "Recommendation" and a publication date of 2025-12-10. It defines a permanent namespace, https://rslstandard.org/rsl, and a media type, application/rsl+xml. It builds explicitly on RSS and on the Robots Exclusion Protocol (RFC 9309).

The core is a small XML vocabulary. A <content> element identifies an asset by URL and may carry a server attribute pointing at a license server. Inside it, one or more <license> elements each hold some combination of <permits>, <prohibits>, <payment>, <reporting> and <legal>.

The usage vocabulary is the part publishers care about: all, ai-all, ai-train, ai-input, ai-index, search. The distinction between ai-train and ai-input is the one that matters for agents — training on a page is a different act from reading it at inference time to answer a question, and RSL is one of the few vocabularies that lets a publisher price them apart.

The payment vocabulary is broader than anything in the pay-per-crawl conversation: <payment> takes a type of purchase, subscription, training, crawl, use, contribution, attribution or free. A price goes in <amount> with a required currency attribute. Terms can be referenced from a shared framework with <standard> or delegated to the publisher's own page with <custom>.

Discovery is deliberately plural. Five channels are defined: a License: directive in robots.txt, an HTTP Link header with rel="license", an HTML <link> or inline <script type="application/rsl+xml">, an RSS module, and metadata embedded in media files.

On top of that sit three optional network protocols. The Open License Protocol (OLP) is an OAuth 2.0 extension: POST /token with a client_credentials grant returns an access_token whose token_type is the string License, plus /introspect per RFC 7662 and /key for content encryption keys as JWKs. The Crawler Authorization Protocol (CAP) defines Authorization: License <token> and the 401 / 402 / 403 / 503 responses around it. The Encrypted Media Standard (EMS) covers assets marked encrypted="true".

Section 4.10 is where this touches our stack. A server "MAY respond with a 401 Unauthorized or 402 Payment Required status code when access to a resource is contingent on obtaining a license," and that response should carry either an inline application/rsl+xml body or a Link header pointing at the governing license. That is the same 402 we have been mapping since the first x402 walkthrough, used to hand back terms instead of a payment challenge.

The x402 seam

The element that made us start this audit is <accepts>. It advertises the payment methods a client MUST use to satisfy the enclosing payment terms, and the specification is unusually specific about one of them: "For the x402 protocol, this MUST be application/x402+json." The spec's own example is worth reading closely.

<rsl xmlns="https://rslstandard.org/rsl">
  <content url="/">
    <license>
      <payment type="crawl">
        <standard>https://example.com/licenses/pay-per-crawl</standard>
        <accepts type="application/x402+json">
          { "scheme": "deferred",
            "network": "example-network-provider",
            "resource": "https://example.com/" }
        </accepts>
      </payment>
    </license>
  </content>
</rsl>

Three things are wrong with this picture, and none of them are typos.

First, the media type does not exist on the other side. We cloned x402-foundation/x402 at HEAD 230e6a9, dated 21 August 2026. The string application/x402+json appears zero times in the entire tree. So does rslstandard, and so does "Really Simple Licensing". RSL has minted a media type on x402's behalf, declared it mandatory, and x402 has never heard of it. Neither type is registered with IANA either, which we come back to below.

Second, the example's field values do not match the protocol it names. The network is the placeholder string example-network-provider, where x402 keys networks by CAIP-2 identifier. And the scheme is deferred: in the x402 tree we cloned, the literal "exact" appears 1,526 times, "upto" 100 times, "batch-settlement" 55 times — and "deferred" twice. The flagship integration example is written against the least-present scheme name in the codebase.

Third, and most structurally, RSL has two price fields that cannot express the same thing. <amount> requires an ISO 4217 currency code. x402 prices in atomic units of a specific asset on a specific chain. There is no defined mapping between them, and RSL's answer is to punt: authoritative pricing "MAY be provided dynamically by the payment protocol at runtime."

This is the same fault line we found in the OpenTelemetry GenAI audit: a specification that models money as a decimal fiat amount, bolted to a settlement layer that models money as an integer count of token units on a named chain. Two ledgers, one join key, no defined conversion.

The crawl: 1,013 domains, five directives

Specifications are cheap. We wanted the deployment number, so we measured it.

We took the top 1,000 domains from the Majestic Million plus 50 named publishers, infrastructure vendors and organizations from RSL's own press material — 1,013 unique hosts after deduplication. For each we requested /robots.txt over HTTPS with certificate verification on, one request per host, and parsed for the License: directive.

725 hosts returned a non-HTML robots.txt with HTTP 200. Of those, five carried a License: directive:

# robots.txt License: directives, 1,013 domains, 2026-08-22
medium.com          -> https://medium.com/license.xml
theguardian.com     -> https://theguardian.com/license.xml
guardian.co.uk      -> https://theguardian.com/license.xml   # same target
rslstandard.org     -> https://rslcollective.org/royalty.xml
rslcollective.org   -> https://rslcollective.org/royalty.xml # same target

Five directives, three distinct license URLs, and two of the five hosts are RSL's own properties. Outside the standard's own websites, the open web's top thousand domains plus fifty named publishers yielded two adopters: Medium and the Guardian.

The control number is more interesting than the headline. In the same crawl, 21 hosts carried Cloudflare's Content-Signal directive — a narrower, younger, non-monetary mechanism that RSL's own specification cites as a normative reference. The simpler thing that ships by default at an edge provider is four times more deployed than the standard with 1,500 endorsing organizations behind it.

Because robots.txt is only one of five discovery channels, we checked the others for all 50 named organizations: a direct /license.xml fetch, the homepage Link header, and the homepage HTML for <link rel="license" type="application/rsl+xml"> or an inline RSL script block. That added exactly one adopter that robots.txt had missed: supertab.co, the vendor named in RSL's press material as the managed license server provider. Two other hosts answered 200 on /license.xml — usatoday.com and forbes.com — but both were 301 redirects into ordinary pages, not RSL documents.

One finding from that sweep deserves its own line. Medium's robots.txt advertises a license URL, and that URL returns 403 behind a Cloudflare bot challenge — to our audit user agent and to a browser user agent alike. The document that exists to tell automated clients what they may do is unreadable by automated clients.

What the live licenses actually say

Three RSL documents are reachable in production. All three are small enough to quote in full. Here is the Guardian's, at 336 bytes:

<rsl xmlns="https://rslstandard.org/rsl">
  <content url="/">
    <license>
      <permits type="usage">ai-train ai-input</permits>
      <payment type="subscription">
        <custom>https://licensing.theguardian.com/</custom>
      </payment>
      <prohibits type="usage">all</prohibits>
    </license>
  </content>
</rsl>

Read that as a client must. The same <license> element permits ai-train ai-input and prohibits all. Section 4.9 of the specification handles conflicting terms with one rule: "clients MUST honor the most restrictive combination of rights." A conformant agent applying that rule to the Guardian's license concludes that everything is prohibited, including the two usages explicitly permitted one line above. The human intent is obvious — everything is off unless you subscribe — but the document as written does not say that, and the rule the spec provides resolves against the publisher.

The RSL Collective's own document, 301 bytes, permits ai-all with a <payment type="use"> pointing at a <standard> URL. Supertab's, 514 bytes, permits search, prohibits ai-train, and attaches <legal> warranty and disclaimer declarations.

Now the number that matters. Across all three live documents, the count of <amount> elements is zero. The count of <accepts> elements is zero. Not one production RSL license in existence names a price, a currency, or a payment protocol.

Every one of them degrades to a human. The Guardian's <custom> points to a licensing contact page. The Collective's <standard> points to membership terms. For an autonomous agent that hits a 402 and wants to pay and move on, the machine-readable licensing layer currently resolves to "go find a person and negotiate." That is precisely the walk-up problem the whole 402 revival exists to eliminate.

The license servers

RSL's guide publishes a List of License Servers. It has exactly one entry: the RSL Collective's, "Nonprofit server operated by leading web publishers." The Collective's own live license document names its server in the server attribute: https://api.rslcollective.org.

That hostname does not resolve. We queried it against two independent public resolvers and got NXDOMAIN from both, while the parent domain resolves normally:

$ dig +short @1.1.1.1 api.rslcollective.org  # status: NXDOMAIN
$ dig +short @8.8.8.8 api.rslcollective.org  # status: NXDOMAIN
$ dig +short @1.1.1.1 rslcollective.org
172.67.175.231
104.21.64.35

The only license server in the official directory, referenced by the standards body's own license document and used as the worked example in its own developer guide, has no DNS record. OLP has no reference deployment we could reach.

The one OLP implementation that does answer is Supertab's, named in its license document's server attribute. We drove it directly. POST /token with a client_credentials grant and bad credentials returns a clean, spec-shaped rejection:

# POST .../token  -> 401
{ "error": "invalid_client",
  "error_description": "Invalid client credentials" }

That is OLP working as designed, and it is the only such response we obtained anywhere. But POST /introspect on the same server returns 404 Not Found, so token validation — the endpoint a publisher needs in order to check a crawler's license — is not implemented. And supertab.co itself answers 200 with no WWW-Authenticate header, so CAP is advertised in the document but not enforced at the resource. One of three OLP endpoints, and no enforcement.

Nothing is registered anywhere

Section 10 of the specification is titled "IANA Considerations and Normative Changes to RFCs," and states that "all IANA actions defined in this section are permanent." It requests three things: registration of the application/rsl+xml media type under RFC 6838, registration of a new HTTP authentication scheme named License under RFC 9110, and a normative extension to RFC 9309 adding the License directive to robots.txt.

We checked all of it against the live registries on 22 August 2026. The IANA application media type registry holds 1,795 entries; rsl+xml is not among them. The HTTP Authentication Scheme registry holds 18 entries — Basic, Bearer, Concealed, Digest, DPoP, GNAP, HOBA, Mutual, Negotiate, OAuth, PrivateToken, SCRAM-SHA-1, SCRAM-SHA-256, vapid and others — and License is not among them. RFC 9309 has not been updated.

Requesting is not registering, and a specification cannot normatively amend someone else's RFC by asserting that it does. This is the same pattern we documented in the KYAPay audit, where eighteen proposed JWT claims and ten AMR values had zero presence in the corresponding registries. It is becoming the default posture of the agent-standards wave: publish the vocabulary, describe the registration as done, skip the process.

The engineering artifact tells the same story. The rslstandard/rsl repository is the organization's only public repo. Created 2025-02-18, 46 stars, one fork, two open issues, eight commits — all by the same author, the Technical Steering Committee chair — with the last push on 2026-03-31 and a total size of 11 KB. Its entire contents are a README. There is no schema, no test suite, no validator, no reference implementation. For a format whose conformance rules turn on precedence between conflicting elements, there is nothing to check a document against, which is exactly how a license that permits and prohibits in the same breath reaches production at a major newspaper.

What it means for LLM4Agents

The honest reading is that RSL is important and not yet real. Both halves matter.

It is important because it is the only serious attempt to give an agent a machine-readable answer to "what may I do with this," attached to the same 402 that answers "what does it cost." Our gateway already sits on the paying side of that exchange. When an agent routed through us fetches a page, an API or an MCP tool, the response can carry terms that constrain what the agent may then do with the bytes — feed them to a model as input, keep them in memory, use them in training. Those are different acts with different prices, and ai-input versus ai-train is the first vocabulary that separates them cleanly.

It is not yet real because the payment half is empty. There is no live RSL license anywhere that an agent can price, no reachable license server in the official directory, no registered media type, and no awareness of RSL inside x402. An agent that implements RSL today gets a compliance obligation and no ability to discharge it — it can learn that content is restricted, and cannot pay to unrestrict it.

The threat is specific and worth naming. If the licensing layer matures with its price expressed only in ISO 4217 and its enforcement delegated to bot management, the settlement layer we build on gets designed out. The 402 becomes a notice that routes to a sales team, and pay-per-crawl becomes an enterprise contract with a login. That is the world in which signed agent identity matters more than payment rails, because access is granted by allowlist rather than bought per request.

The opportunity is the mirror image. RSL has already conceded the architectural point that pricing can be dynamic and delegated to the payment protocol at runtime. That sentence in section 3.11 is an open door. The side that supplies working <accepts> payloads, real amounts and a facilitator that settles them defines what the licensing layer's price field means in practice.

Staying on the frontier

Concrete, in order.

1. Parse RSL on the buyer side, now. When our gateway or an agent using it fetches a resource, check the five discovery channels and attach the resulting terms to the response as structured metadata. This is a small parser against a small vocabulary, and it costs one extra request per origin with caching on max-age. The value is not enforcement, it is that the agent's own logs record what it was permitted to do at the moment it read something.

2. Implement the conflict rule correctly and log when it bites. The most-restrictive rule in section 4.9 is a real hazard, and the Guardian's document proves it fires in production. An agent that silently resolves a contradictory license to "everything prohibited" will look broken to its operator. Surface the contradiction explicitly instead, and report it upstream — the publishers producing these documents have no validator to catch it.

3. Publish a working <accepts> profile for x402. The gap here is a document nobody has written: how an x402 payload inside <accepts> maps onto the accepts array of a real 402 response, how <amount currency="USD"> reconciles with atomic units of a stablecoin on a CAIP-2 network, and which scheme applies to which <payment type>. Per-crawl maps to exact. Per-inference maps to upto, the metered scheme we covered in the upto and Permit2 deep dive. Writing that mapping is a week of work and it is currently unclaimed.

4. Serve RSL on our own endpoints. We are a seller of machine-readable resources, not only a buyer. Publishing an RSL document over our own docs and APIs — with a real <amount> and a real <accepts type="application/x402+json"> — would make it the first live license in the world that an agent can actually pay. That is a one-file change with disproportionate demonstrative value.

5. Push both registrations upstream. application/x402+json is unregistered on the x402 side too. If the licensing layer is going to reference a payment media type as mandatory, that media type should exist in the IANA registry, and the natural place to raise it is the x402 Foundation's working groups rather than the licensing body.

6. Track the enforcement path, not the endorsement count. The metric that predicts whether this becomes infrastructure is not how many organizations sign a supporter page. It is how many origins return a 402 with an application/rsl+xml body or a rel="license" Link header. Today that number is effectively zero. We will re-run this crawl on a schedule, and the first time it moves, the licensing layer will have started to exist.

Standards get judged on what is on the wire. Right now RSL has a good vocabulary, an empty price field, a dead server hostname, and a payment protocol that does not know it exists. That is not a reason to ignore it. It is a description of an unfinished seam, and seams are where the work is.