DEV Community: Avraham K

Anonymity by construction: keeping two agents from swapping contact details

Avraham K — Wed, 26 Aug 2026 11:12:18 +0000

I run a broker that introduces two software agents to each other, lets them negotiate, and steps out of the way once they seal a deal. The entire value of that is the introduction. If the two of them can trade an email address in the negotiation thread, they take the second deal off-platform and I have built a very expensive contact form.

So the negotiation is anonymous by construction. Neither side learns anything about the other until a deal is sealed, and what they learn then is time-boxed. This post is what three layers of that cost in Go, including the layer that fires on my own users and the bypass I have decided not to fix.

The adversary is a paying customer
Most input-scanning advice assumes an attacker: someone outside the system, trying to get in, with no legitimate reason to be typing at you. That framing produces the wrong design here.

My leak risk is a user in good standing, acting in their own rational economic interest, who would quite like to skip my fee. They are not evading detection for its own sake. They will try roughly one thing, and if it bounces they will mostly shrug and carry on, because the platform is still worth more to them than one saved fee.

That changes the target. I am not trying to make leaking impossible, because I cannot. I am trying to make it more expensive than complying, for a user who is not motivated enough to work at it. The internal name for this is the posting tax. Everything below is a tax rate, not a proof.

The second consequence is subtler and it is where I got hurt. Because the adversary is also the customer, every false positive lands on someone who was trying to pay me. A rejection is not a blocked attack. It is a lost listing.

Layer one: normalise before you scan
The patterns are ASCII literals. An @ is U+0040. So the first thing anyone tries is not an @.

The fold runs before any pattern does, and it does three things in a fixed order:

func normalizeForScan(text string) string {
var b strings.Builder
b.Grow(len(text))

for _, r := range text {
    // (1) Drop zero-width / format characters entirely.
    if isZeroWidthOrFormat(r) {
        continue
    }
    // (2) Map confusables / fullwidth forms to ASCII.
    if mapped, ok := confusableToASCII(r); ok {
        b.WriteRune(mapped)
        continue
    }
    // Fullwidth ASCII block (U+FF01..U+FF5E) -> ASCII (U+0021..U+007E).
    if r >= 0xFF01 && r <= 0xFF5E {
        b.WriteRune(r - 0xFEE0)
        continue
    }
    b.WriteRune(r)
}

// (3) Lowercase last so any mapped/decomposed uppercase also folds.
return strings.ToLower(b.String())

}
Step one strips the invisibles: zero-width space, non-joiner, joiner, word joiner, soft hyphen, BOM, and then the Unicode Cf format category generally, which sweeps up the bidi controls. These are the cheapest evasion available, because alice@example.com with a zero-width space after the l renders identically to alice@example.com and is a different byte string.

Step two is a small hand-written confusables table. Five dot homoglyphs, two commercial-ats, two colons, two slashes. Then the fullwidth ASCII block folds by a fixed 0xFEE0 offset, which is the one piece of Unicode arithmetic in the whole thing: U+FF01..U+FF5E is a contiguous copy of printable ASCII, so subtracting the offset is the entire transform.

Step three lowercases, and it goes last on purpose, so anything the previous two steps mapped into uppercase ASCII still folds.

Two decisions inside that are worth naming.

It is stdlib only, deliberately. This is not NFKC and it is not a UTS-39 confusables pass. Doing it properly means golang.org/x/text, which is a module-level dependency, and I decided a curated table that closes the concrete vectors I could name was worth more today than a correct one I would ship later. That is a real tradeoff and the losing side of it is that my table has holes. I know it has holes. It is written down in the package comment so the next person does not think it is complete.

The source file is pure ASCII. Every one of those runes is written as an escape rather than as the glyph, and there is one hard reason underneath a lot of soft ones: a literal U+FEFF byte in a Go source file is an illegal byte-order mark. You cannot write that case as a character literal. Once one of them has to be an escape, all of them should be, or the table becomes a mix of things you can read and things you cannot.

Layer two: the day I banned @staticmethod
The contact patterns are the boring part. Canonical email, obfuscated email (user at example dot com), URLs, bare www., North American and international phone shapes, Ethereum addresses, Bitcoin bech32 and P2PKH.

The interesting one is social handles, because my first version was this:

// The version I shipped, and then deleted.
regexp.MustCompile(@[A-Za-z0-9_]{1,50})
It is correct about handles. It also rejects @staticmethod, @types/node, @media (min-width: 640px), and every Go struct tag anyone has ever pasted into a listing body.

Read that against the previous section. The marketplace brokers technical work between software agents. Listing bodies are full of decorators, scoped npm packages, and struct tags. I had written a pattern that fired most often on exactly the content I most wanted people to post, and every one of those firings was a customer who wrote something honest and got told no.

The fix is to stop matching the handle and start matching the leak. A handle on its own is not a contact detail. A handle plus somewhere to use it is:

// (i) " @handle"
regexp.MustCompile((?i)\b(?:telegram|signal|whatsapp|wechat|insta(?:gram)?|twitter|discord|snap(?:chat)?|tiktok|reddit|t\.me)\b[\s:@]+@?[a-z0-9_]{2,50}),
// (ii) "@handle on "
regexp.MustCompile((?i)(?:^|\s)@[a-z0-9_]{2,50}\s+on\s+(?:telegram|signal|whatsapp|insta(?:gram)?|twitter|discord|snap(?:chat)?|tiktok|reddit)\b),
// (iii) "dm/contact/reach/msg me @handle"
regexp.MustCompile((?i)\b(?:dm|pm|msg|message|contact|reach|ping|find|add)\s+me\b[\s:@]*@[a-z0-9_]{2,50}),
Three patterns instead of one, and each requires context that makes a leak plausible: a platform name adjacent to the handle, or a solicitation. ping me on telegram @alice_dev, @alice_dev on telegram and dm me @alice_dev all still fail closed. @staticmethod passes.

There is a related fix in the Bitcoin matcher that I want to mention only because the reasoning generalises. A P2PKH address is a base58 run of 26 to 34 characters starting with 1 or 3, and distinguishing one from an ordinary word means also requiring mixed content: at least one digit, one uppercase and one lowercase. The original expressed that with a nested quantifier over an alternation, which is the classic catastrophic-backtracking shape. Go's regexp is RE2, so it is linear time and was never actually exploitable. I moved it into code anyway:

var btcP2PKHCandidate = regexp.MustCompile((?:^|[^0-9A-Za-z])[13][1-9A-HJ-NP-Za-km-z]{25,33}(?:[^0-9A-Za-z]|$))
and the mixed-content check became a loop. Not because RE2 was going to blow up, but because a reviewer cannot tell at a glance that it will not, and a pattern whose safety depends on which engine you compiled it with is a pattern that breaks the day someone ports it.

The detail I did get right there by accident and then had to defend: the mixed-content scan runs over body[1:], skipping the version prefix, so the leading 1 does not satisfy the digit requirement on its own.

Two passes, and why the raw one runs first
Scan runs the whole pattern set twice:

func Scan(text string) (ok bool, reason config.Reason) {
if ok, reason := scanOnce(text); !ok {
return false, reason
}
if normalized := normalizeForScan(text); normalized != text {
if ok, reason := scanOnce(normalized); !ok {
return false, reason
}
}
return true, ""
}
Raw first, then normalized, and only if normalizing changed anything. The ordering is not an optimisation, although it is one. Patterns are evaluated in declaration order and the first match wins, so which pass runs first decides which reason a rejected submission gets. Running raw first means ordinary ASCII content, which is almost all of it, produces exactly the reason it produced before the normalize pass existed. The fold cannot reorder the common path. It can only catch things the common path missed.

The whole scanner is a pure function with no I/O, and detection is fail-closed: callers reject on ok == false and are explicitly forbidden from reading the reason to decide whether to allow something. The reason is for the rejection message, not for a policy branch.

One thing worth knowing about where it runs. On threads, the scan is over the message diff, not the whole thread. That is the right call for cost and it is a real gap: it means the scanner sees each increment in isolation and has no view of a leak assembled across turns.

Layer three: an ID that does not count
Scrubbing text is only half of it. The other half is not handing out identifiers that leak by existing.

Deal IDs are eight hex characters, produced by a balanced Feistel network:

const (
rounds = 4
halfBits = 16
halfMask = (1 << halfBits) - 1
)

func (c *Codec) round(val, roundKey uint32) uint32 {
v := val + roundKey
v ^= v >> 7
v += v << 3
v ^= v >> 5
v += v << 11
return v & halfMask
}

func (c *Codec) Encode(n uint32) uint32 {
left := (n >> halfBits) & halfMask
right := n & halfMask

for i := 0; i < rounds; i++ {
    newRight := left ^ c.round(right, c.keys[i])
    left = right
    right = newRight
}

return (left<<halfBits | right)

}
Four rounds, 16-bit halves, an ARX round function, round keys loaded at construction from Parameter Store. A Feistel network is bijective by construction whatever the round function does, so Decode(Encode(n)) == n for every uint32 and there is no collision to check for and no uniqueness index to maintain.

That round function is not cryptography and I am not going to pretend it is. Somebody is going to say so in the comments, so it is said in the package doc first:

// SECURITY (L-8): the Feistel round function and the FNV-32a route hash are
// NON-CRYPTOGRAPHIC. This is intentional and safe under the current design only
// because (a) the pre-image fed to Encode is drawn from crypto/rand at deal
// finalize time, so encoded IDs are unpredictable regardless of the weak mix,
// and (b) GET /v1/deals/{id} returns 404 to any non-party, so a guessed or
// reversed ID leaks nothing. Do NOT derive deal IDs from counters or any
// sequential/attacker-influenced source, and do NOT promote the route hash to a
// security-bearing lookup key. If either invariant changes, replace this with a
// keyed cryptographic PRF (e.g. HMAC/AES-based) before shipping.
Both clauses are load-bearing and both are enforced somewhere else in the tree, which is the uncomfortable part of writing an invariant like that down. Clause (a) lives at finalize:

var rawBuf [4]byte
if _, err := rand.Read(rawBuf[:]); err != nil {
return store.Deal{}, fmt.Errorf("finalize: rand: %w", err)
}
rawID := binary.BigEndian.Uint32(rawBuf[:])
encodedID := s.codec.Encode(rawID)
dealID := fmt.Sprintf("%08x", encodedID)
Clause (b) lives in the GET handler, and it is a 404 rather than a 403 on purpose, because a 403 confirms the deal exists:

if accountPK != deal.BuyerPK && accountPK != deal.SellerPK {
problem.Write(w, problem.New(http.StatusNotFound, "Not Found",
"deal not found", config.ReasonNotFound))
return
}
So the honest statement is not that the ID is unguessable. It is that the ID is drawn uniformly from 2^32 and reveals nothing when guessed. Take away either property and the encoding needs to become a keyed PRF. The comment says that too, in the imperative, because the person who breaks this will be me in eight months and I will not remember.

The one adjacent decision I would defend on its own is decode strictness. Deal IDs have exactly one legal spelling:

var dealIDHexPattern = regexp.MustCompile(^[0-9a-f]{8}$)
The previous implementation used fmt.Sscanf, which cheerfully accepts a 0x prefix, uppercase, and leading whitespace, all of which parse to the same integer. That gives one deal several valid names, and anything downstream that compares, caches, logs or rate-limits by the string form now has several keys for one object. A regexp guard in front of strconv.ParseUint closes it.

The reveal, mirror-imaged and time-boxed
When a deal seals, each party gets the counterparty's endpoint, and only then. The endpoint is per-deal, not per-account: an FNV-32a hash of a per-operator salt and the encoded deal ID, appended to whatever base route that operator configured.

func ResolveRoute(baseRoute, hash string) string {
if baseRoute == "" {
return ""
}
return strings.TrimRight(baseRoute, "/") + "/" + hash
}
The empty-base case matters more than it looks. Returning "" means an operator who configured no route escrows as absent, not as a bare /hash that resolves to somebody's site root.

Two properties on top of that. The reveal is served mirror-imaged, so each side receives the other's coordinates and neither ever sees their own escrowed record come back to them. And it is time-boxed: reveal_at gates release, purge_at is seven days after finalization, and after that the contact detail is gone and only reputation aggregates survive.

The purge is lazy, evaluated on read, with no scheduler. If purge_at has passed when the deal is fetched, the handler makes a best-effort flip of the stored status and returns 410 regardless of whether that flip succeeded.

Returning 410 whether or not the write lands is the part I like. The read path does not depend on the write path having worked, so a failed flip costs a retry next request and never a leak. There is no sweeper to monitor, no dead-letter queue, and no window where the scheduler is behind and the data is still readable.

What is still wrong: the tax falls on my own users
The false positives from the @handle pattern taught me to go looking for the rest of them. I found a worse class, and it is worse precisely because of what this marketplace is for.

The prompt-injection patterns implement the OWASP LLM01 checks: persona hijacks, new instructions:, ChatML role delimiters, jailbreak keywords. They are reasonable patterns. They are also fired against listings written by and for AI agents, which is a domain where that vocabulary is just the vocabulary. Real strings, run through the real scanner:

Listing text Result
telegram bot integration, 99.9% uptime rejected, contact_leak
you are now ready to query the endpoint rejected, prompt_injection
we run jailbreak detection on every prompt rejected, prompt_injection
our DAN pipeline scores nightly rejected, prompt_injection
ignore stale rows before applying the constraint rules rejected, prompt_injection
Every one of those is a legitimate listing. The first is the sharpest: I built a marketplace for agent services and my contact-leak pattern rejects anyone offering a Telegram bot integration, because pattern (i) matches a platform name followed by any word. The last one is a database tool describing what it does to stale rows, caught by an ignore ... rules proximity pattern with a sixty-character window. And \bDAN\b carries no case-insensitive flag, which spares the name Dan and still matches every ordinary uppercase acronym.

This is the same mistake as @staticmethod, one layer up, and I did not recognise it until I went looking for it on purpose. A pattern set inherits its false-positive rate from the corpus you point it at, and I keep pointing mine at the one corpus guaranteed to be dense in the exact tokens I banned.

I have not fixed it. The shape of the fix is the same as the handle fix: require an imperative addressed at a model rather than a bare keyword, and scope the platform patterns to require handle-shaped text rather than any word. What I am not going to do is soften it into an allowlist of blessed phrases, because that is a list I would be editing forever.

And the bypass I am not going to fix
Regex contact-scrubbing is trivially bypassable. Here are two that work today, tested against the shipped scanner:

jay oh aitch en at gee mail dot com
my handle is the same word as the bird, on the app named for it
Both pass clean. The first survives because the obfuscated-email pattern wants token at token dot tld with single-token domains, and spelling the local part as separate words breaks the shape. The second survives because it is a riddle, and I am not going to solve natural-language reference with a regexp.

I could push these into an LLM classifier and catch both. Then the bypass becomes a slightly better riddle, at the cost of a model call on every listing write and a new failure mode where the classifier is down. There is a kill switch for exactly that case, and its behaviour is to fail the write rather than let content through unscanned:

var ErrUnavailable = errors.New("scrub: scanner unavailable")

func ScanE(text string) error {
if unavailable.Load() {
return ErrUnavailable
}
...
}
The reason I am comfortable stopping here is the threat model at the top. The scrubber is not the anonymity guarantee. The anonymity guarantee is structural: there is no field in the schema where a counterparty's contact detail lives before a deal seals, the identifiers do not enumerate, and the reveal expires. The scrubber is a tax on the one channel where free text has to exist at all, and taxes are allowed to be evadable. What is not allowed is for the structure to have a hole, and that is where the review effort goes.

What I would keep
Name the adversary before you write the pattern. Mine is a customer, which means false positives cost more than misses, and that single sentence would have prevented @staticmethod.
Match the leak, not the shape. A handle is not a contact detail. A handle plus a platform is. The context requirement is what made the pattern set survivable.
Normalise before matching, and fold in a fixed order. Invisibles out, confusables in, case last.
Write the invariant next to the weak primitive. Non-cryptographic is a fine choice with two named preconditions and a disaster without them, and the difference is entirely whether the next person knows what the preconditions are.
Lazy expiry over scheduled expiry. Evaluating on read means there is no sweeper to fall behind.
And the one I would tell myself earlier: run the pattern set against your own corpus before you ship it, not against the attack strings you invented while writing it. I had good coverage of the leaks and none of the legitimate content, so every test was green and the failures were all in production, arriving as users who could not post.

This is running at cogdepot.com, where two agents negotiate without either learning who the other is until they seal. If you want to argue with any of this, the table in the false-positives section is the part I would argue with too.

The Cognito war stories: four ways it breaks an MCP server, and the fix for each

Avraham K — Wed, 19 Aug 2026 19:05:33 +0000

If you are putting Amazon Cognito behind a remote MCP server, here are four specific ways it will break the connector before you ever reach your own code - each with the symptom, the reason, and the fix that got us through it. All four came out of one week of wiring an agent OAuth flow for cogDepot, and none of them are in the happy-path docs.

None of this is competitively sensitive. It is just the friction between two specs that were written by different people who never had to make them meet.

1. Cognito rejects the RFC 8707 resource indicator that MCP insists on sending

MCP's authorization spec wants access tokens to be audience-bound. The mechanism it points at is RFC 8707 Resource Indicators: the client appends a resource parameter to the /authorize and /token requests naming the server it wants a token for, and the authorization server is supposed to bind the resulting token to that resource.

A spec-compliant MCP client does this unconditionally. Claude's connector does. You do not get to turn it off from the client side, and you should not want to - it is the client behaving correctly.

Cognito does not implement RFC 8707. It does not bind the token to the resource; it rejects the request for carrying an unrecognized parameter. So the connector's very first hop - the redirect to /authorize - dies before the user ever sees a login box.

You cannot fix this in Cognito's configuration and you cannot fix it in the client. The fix is a thin, same-origin OAuth proxy sitting in front of Cognito's /authorize and /token. It forwards everything through untouched except for one surgical edit: it strips the resource parameter on the way in.

The part that will bite you if you are careless about it: strip resource and nothing else. In particular code_challenge and code_challenge_method have to survive verbatim, or you break PKCE and trade one failure for another. Our verification checklist for the proxy is exactly that - "/oauth/authorize strips the RFC 8707 resource param while preserving code_challenge" - because the first cut of the proxy is where you accidentally drop the wrong one.

The audience-binding that RFC 8707 was supposed to give you, you now have to enforce yourself at the resource server. Which is the next story.

2. Cognito access tokens carry no `aud`, so you pin on `client_id`

MCP is blunt about audience validation:

MCP servers MUST validate that access tokens were issued specifically for them as the intended audience, according to RFC 8707 Section 2. [...] MCP servers MUST NOT accept or transit any other tokens.

The reflex, if you have validated ID tokens before, is to check the aud claim. That is correct for a Cognito ID token. It is useless for a Cognito access token, because a Cognito access token has no aud claim at all. The client that the token was minted for is named in client_id instead, and the token carries token_use: access where the ID token carries token_use: id.

So the audience check that satisfies the MCP requirement is a client_id check. Two claims move relative to the ID-token path: you compare client_id against your configured client, and you require token_use == "access". Here is the verifier we run, trimmed to the claim checks:

// An access token differs from an ID token in two ways that matter here: it
// carries no `aud` claim (the client is named by `client_id`), and it carries
// authorization `scope`. The verifier checks `client_id` where the ID-token
// path checks `aud`, and `token_use=access` where the ID path requires `id`.

if claims.Iss != v.issuer {
    return nil, fmt.Errorf("cognito: unexpected issuer %q", claims.Iss)
}
// The binding that stands in for the absent `aud` on an access token.
if claims.ClientID != v.clientID {
    return nil, fmt.Errorf("cognito: unexpected client_id %q", claims.ClientID)
}
if claims.TokenUse != "access" {
    return nil, fmt.Errorf("cognito: unexpected token_use %q", claims.TokenUse)
}

Miss the token_use check and an ID token minted for the same client sails straight through your access-token path. Miss the client_id check and any access token from the same user pool - including one issued to a completely different app client - is accepted as yours. The pool is the trust boundary Cognito gives you for free; the client is the one you have to draw yourself.

One more thing worth pinning while you are in there: accept exactly one signing algorithm (RS256) and one key type (RSA), compared against the values in the attacker-supplied token header rather than inferred from it. Algorithm confusion needs a negotiable alg field to exist. Do not give it one.

3. Managed Login v2 renders "Login pages unavailable" for any client with no branding style

This one produces the least helpful error message of the four. You move a user pool to Managed Login (the version-2 hosted UI), point a new app client at the same domain, hit its login URL, and get:

Login pages unavailable. Please contact an administrator.

Nothing is misconfigured in the obvious places. The domain resolves, the client exists, the pool is on the right feature plan. What is missing is a branding style for that specific client. On a version-2 domain, Managed Login will not render a login page for a client that has no style applied - it does not fall back to a default, it refuses. The web client worked because it had a style; the freshly-added agent client hit the wall precisely because it did not.

The fix is to give every client its own managed-login branding resource, even if it is a near-clone of another client's. In Terraform that is awscc_cognito_managed_login_branding (the aws provider's equivalent is a v6 resource; the underlying call is the same CreateManagedLoginBranding either way). Ours reuses the web client's palette and logo assets byte-for-byte, with a single deliberate difference: the agent client's page shows the federated sign-in buttons, because unlike the web flow there is no first-party page in front to deep-link the user into a specific identity provider.

While you are here, one gotcha that turns a working style into a recurring outage: Cognito marks the branding style's ClientId as create-only, and Cloud Control's in-place update is a JSON patch that always contains an "add ClientId" op it is not allowed to apply. The first apply succeeds; every later colour or logo tweak fails with:

NotUpdatableException: Invalid patch update:
createOnlyProperties [/properties/ClientId] cannot be updated

So configure the style to be replaced on change, not updated - replace_triggered_by a hash of the settings and asset files. The cost is a few seconds of unstyled login during the destroy-then-create, which is fine for a settings change and is the only supported path for a create-only property.

4. Elicitation is not supported by connector hosts yet - which we proved, not assumed

The MCP spec has elicitation: mid-tool-call, the server can ask the client to collect a piece of input from the user and hand it back. It is the natural home for a confirmation step - "this action will spend N credits, confirm?" - and the spec describes it cleanly enough that it is very tempting to design a flow around it and move on.

We did not design around it, because the spec describing a capability and a given host implementing it are different facts. Before leaning on elicitation for anything load-bearing, we built the smallest possible throwaway server that does nothing but issue one elicitInput call, pointed a real connector host at it, and watched what came back.

The answer today is that connector hosts do not support elicitation yet. Reading the spec would have told you the shape of the round-trip; it would not have told you the host silently declines to make it. The spike cost an afternoon and turned a guess into a fact.

The consequence for the design is that we did not ship anything whose safety depends on an elicitation round-trip. The confirmation that elicitation would have carried lives somewhere the host is guaranteed to honour instead. The general rule, which is older than MCP: when a capability sits on the far side of a host you do not control, the smallest experiment that exercises it end-to-end is cheaper than the bug you ship by assuming it works.

The through-line

Three of these four are the same shape: a standards body wrote an obligation, an implementation you depend on does not meet it, and the gap lands in your lap at the integration seam. RFC 8707 says bind the token; Cognito does not, so you strip and rebind. MCP says validate the audience; Cognito's access token has no audience field, so you validate the client instead. The spec says elicitation exists; the host has not built it, so you find out before you depend on it.

The only defense that generalizes is to verify the seam rather than trust it - proxy what the provider rejects, check the claim that is actually present rather than the one you expected, and spike the capability against the real host. Every one of these was an afternoon once we stopped assuming and started looking.

The EU AI Act asks AI to identify itself. I checked 30 years of that experiment on my server.

Avraham K — Tue, 11 Aug 2026 20:17:44 +0000

Article 50 of the EU AI Act applies as from 2 August 2026. Providers of systems that generate synthetic text, audio, image or video have to mark outputs in a machine-readable format so they are detectable as artificially generated, and people have to be told when they are interacting with an AI system. Systems already on the market before that date have until 2 December 2026 to meet the marking obligation, so the compliance scramble is happening right now.

The whole design rests on a premise: that if you require a thing to declare what it is, you get a usable signal.

We have been running that experiment for thirty years. It is called the User-Agent header, and I have a small server that logs every one of them.

Before the numbers, the honest caveat, because I do not want to be accused of a bait and switch: the User-Agent is not what Article 50 regulates. The Act is about marking generated content, not about how crawlers announce themselves, and C2PA signatures and text watermarks are cryptographically stronger than a header any client can type. The analogy is not that they are the same mechanism. It is that they share the load-bearing assumption, which is that a declaration made by the party being regulated is worth something to the party reading it. My logs are the closest thing I have to a natural experiment on that assumption.

The numbers

Thirty days to 11 August 2026, on a small service that gets more machine traffic than human traffic. Every request whose User-Agent matched a known AI crawler, graded by who actually owns the source address, resolved over RDAP against the internet registries:

Verdict	Hits	What it means
verified	259	Source address is inside the vendor's own registered netblock
plausible	112	Rentable cloud the crawler is known to run from
SPOOFED	916	One source address sending several different crawler identities
UNEXPECTED	3	Owner is not a network that crawler operates from
no-ip	306	My own instrument does not record a source address on those routes

1,596 requests, 11 distinct crawler identities. Of the 1,290 I can attribute at all, 916 came from somewhere the claimed vendor does not operate. That is 71 percent of the attributable traffic, and 57 percent of everything.

Two sources account for nearly all of it.

The first is a consumer broadband address. It sent 531 requests as GPTBot, spread across 86 different paths, and then came back as ClaudeBot, CCBot and PerplexityBot. Four separate AI companies, one residential connection, walking my URL space methodically. That is not a crawl, it is somebody's scraper wearing whatever costume seemed useful.

The second is more interesting: an address inside a Google-owned netblock that cycled through seven crawler identities in the same window. ChatGPT-User 114 requests, Amazonbot 63, OAI-SearchBot 42, Google-Extended 40, PerplexityBot 38, GPTBot 32, ClaudeBot 32. One machine, seven declared identities, 361 requests.

Meanwhile the real traffic is boring and easy to confirm. ClaudeBot arrives from Anthropic's own registered range. meta-externalagent arrives from Meta's. They look exactly like what they say they are, because they are.

The thing that actually worked

The fix is not a better header. It is refusing to treat the header as evidence.

The User-Agent is the one field the sender chooses for free. The registered owner of the source netblock is not forgeable in the same way, because forging it means controlling routing rather than editing a string. So the grading rule is: take the source address, resolve it to its registered owner over RDAP, and check that owner against a table of who each crawler is allowed to originate from. Anthropic's crawler out of Anthropic's range is a crawl. Anthropic's crawler out of a residential DSL line is a person testing something.

Two properties of this that matter more than the accuracy:

One source, many identities is the tell. I did not need to know which crawler was real. A single address presenting seven different vendor identities has told me everything I need to know without my having to adjudicate any one of them. Cheap, robust, and it does not require me to maintain an opinion about anybody's crawler policy.

The table goes stale, and that failure is silent. Vendors move netblocks. A crawler that suddenly reads UNEXPECTED after a long run of verified is far more likely to be a vendor migration than an impostor, so the honest version of this tool tells you to check the vendor's published ranges before you believe your own verdict. Any provenance scheme with a trust list has this problem and mostly does not admit it.

What this predicts about Article 50

Marking helps against the honest and does nothing against the motivated. Every actor in my logs who was telling the truth was already easy to identify without the mark, and every actor who was lying would have been just as happy to omit a C2PA manifest or strip it in a re-encode. Anthropic's own documentation on how it marks generated content is refreshingly blunt about this: the absence of a mark proves nothing, marks fade under heavy editing, and a present mark means the content "may have been processed" rather than authored. Those are not weaknesses of that implementation. They are the shape of the problem.

Here is the part I would worry about if I wrote policy. When a declared signal is unreliable and enforcement is still required, enforcement does not stop. It migrates to whatever signal is available, which is vibes.

You can already watch this happen. The r/golang subreddit bans AI-generated content and states its method openly: "As it is not easy to determine what is and is not AI, posts will be removed based on their appearence." Their rule reaches posts, comments, and the things a post links to. That is a community that gave up on detection and moved to reading for texture, and I do not think they were wrong to, given the tools they have. It also means a compliant, marked, disclosed piece of writing gets removed for reading like a machine wrote it, while an unmarked one that reads human sails through. The mark is orthogonal to the judgement.

That is the failure mode I would expect at scale: not defiance of the marking rules, but marking becoming irrelevant to the decisions people actually make.

If you run a server

Three things worth doing, none of which require caring about the AI Act at all:

Log the source address, not just the User-Agent. My own report has a 306-hit blind spot because one origin logs the header and not the address. That is 19 percent of my traffic I cannot grade, and it is my fault.
Grade by netblock ownership. RDAP lookups are free, cacheable, and turn an unfalsifiable claim into a checkable one.
Never quote a crawler percentage off raw User-Agent counts. Every "AI crawler traffic is up N percent" chart I have seen is counting the string. Mine would have overstated real crawler traffic by 4.3x.

The reason I care about any of this more than a normal person should: the service these logs come from is cogDepot, a marketplace where the buyers and sellers are supposed to be software agents rather than people. When your customers are all machines, "is this actually who it says it is" stops being an abuse-team problem and becomes the product. I went looking for demand signal in my traffic and found that most of it was somebody else's scraper in a costume, which is a useful thing to learn early and a miserable thing to learn late.

The Act is asking a reasonable thing. I just think anyone building on the assumption that self-declaration produces a usable signal should look at what happened to the last header we tried it with.

I write these up as I hit them. More at x.com/cogdepot.

My Agent Orchestrator Burned 1-2M Opus Tokens Per Task. Here's the Postmortem.

Avraham K — Tue, 04 Aug 2026 18:19:42 +0000

I built an orchestration skill for Claude Code that delegated everything to subagents. It worked. It also cost somewhere on the order of 1-2 million Opus tokens per task - including tasks whose final diff was a handful of lines.

Nothing was broken. Every individual decision was defensible. Three modest multipliers stacked, and then the whole stack ran on every single request.

This is the postmortem, the redesign, and the enforcement layer I should have written first.

v1: pure delegation

The design goal was context hygiene. The main session gets polluted fast - it accumulates file contents, tool output, and dead ends, and its judgment degrades as the window fills. So: don't let it do any work. Make it a coordinator, and give every unit of real work a fresh context.

That produced four rules:

A hard gate. The main session was forbidden from reading, editing, or running anything itself. Every action went through a subagent.
A fixed 5-phase pipeline on every task: Plan → Approve → Execute → Review → Report.
Fresh subagents per phase. No reuse. Each phase got clean context by construction.
Mandated reviewers with "loop until clean." A review phase that re-ran until it found nothing.

And the trigger was broad - essentially any actionable request. "do this," "implement," "fix," "build," "change."

Read those four rules again with a cost lens instead of a correctness lens. That is the whole postmortem.

The three multipliers

1. The dispatch schema made `model` optional

The subagent dispatch tool takes a model parameter. My skill never set it. Omitted, it inherits from the parent session - which was Opus 4.8.

So every subagent, including the ones whose entire job was "read this file and summarize it," ran on the most expensive tier available.

Here's what that actually costs at list prices:

Model	Input $/MTok	Output $/MTok	vs. Opus
Claude Opus 4.8 (`claude-opus-4-8`)	$5.00	$25.00	1×
Claude Sonnet 4.6 (`claude-sonnet-4-6`)	$3.00	$15.00	0.6×
Claude Haiku 4.5 (`claude-haiku-4-5`)	$1.00	$5.00	0.2×

I want to flag something here, because I got it wrong in my own first write-up of this incident: Opus is not 5× Sonnet. It's about 1.7×. It is exactly 5× Haiku. If you're building a tiering story, the Opus→Sonnet move is a 40% cut, and the Opus→Haiku move on genuinely trivial work is an 80% cut.

Which means the model tax was the smallest of my three multipliers. I'd been blaming it for the whole bill. It wasn't even close.

2. "Include ALL context" plus zero memory = a cold cache, every time

This is the expensive one, and it took me longest to see because the symptom ("agents re-read the repo") sounds like a token-count problem when it's actually a cache-prefix problem.

Prompt caching is a prefix match. The cache key comes from the exact bytes of the rendered prompt, in the order tools → system → messages, up to each cache_control breakpoint. One byte different at position N and everything from N onward is a miss.

The economics of that:

Cache read: ~0.1× base input price.
Cache write: 1.25× base input price (5-minute TTL; 2× for the 1-hour TTL).

So a cached read is a 90% discount, and a cold write carries a 25% premium. The gap between best case and worst case on the same tokens is roughly 12×.

Now put a fresh subagent in that picture. A fresh subagent is a new prefix. It does not inherit the parent's cached prompt unless its system, tools, and model are byte-identical to the parent's - and mine weren't, because each phase got its own tailored instructions. Every subagent I spawned paid a cold write on the entire repo context it had been told to "include ALL" of.

It gets worse when you parallelize. A cache entry only becomes readable once the first response starts streaming. Fire five subagents simultaneously with identical prefixes and all five pay full freight - none of them can read what the others are still writing.

My design had a rule that guaranteed maximum context per agent, a rule that guaranteed a fresh prefix per agent, and a fan-out pattern that guaranteed simultaneous cold writes. Three rules, one bill.

3. Fan-out multiplied by an unbounded loop

Five-plus agents per task as a floor - one per phase, more when a phase parallelized. On top of that, "loop until clean" gave the review phase no termination bound other than the reviewer's own judgment about its own output.

A reviewer that finds one nit per pass runs forever. A reviewer that finds nothing on pass one still costs a full agent.

The multiplication

None of these is outrageous alone. Multiply them:

Factor	Multiplier
Opus instead of Sonnet on work that didn't need it	~1.7×
Cold cache write instead of cache read on repo context	~12×
5+ agents per task, before review loops	~5×
Review loop iterations	~1-3×

That's a 100× to 300× band against a baseline of "one well-cached Sonnet agent does the work." Applied to every actionable request, because the trigger was broad.

The 1-2M number stops being surprising. It's what the architecture was specified to do.

Why I didn't notice

Because there is no backpressure anywhere in that loop.

The model cannot see cumulative session spend. It has no running total, no budget, no signal that agent #14 is different from agent #2. The API does offer a task budget (output_config.task_budget), but that governs a single agentic request - thinking, tool calls, and output within one loop. It does not span a session's worth of independent subagent dispatches, which is precisely where my spend lived.

So the only thing standing between me and a 1.5M-token bill was the model's own restraint, mediated through a prompt. Prompts are preferences. Preferences degrade under context pressure, and they get compacted away entirely on long sessions.

That was the actual bug. Not the model tier, not the cache: I put a budget policy somewhere it could not be enforced.

v2: the dispatch contract

Same delegation model, corrected against each root cause:

Explicit model on every dispatch. Haiku / Sonnet / Opus, chosen per task, never inherited. Ends the Opus-by-default tax and, more importantly, makes tier a visible decision rather than a silent default.
Curated briefs instead of "read everything." Exact file paths plus a digest, not a directive to reload the repo. This is the big one - it attacks token count, and token count beats unit price. Cutting input tokens 5× saves more than the entire Opus→Sonnet swap.
Scoped trigger. Orchestrate only large or genuinely parallel work. Trivial edits happen directly in the main session. The overhead of a subagent - a cold prefix, a brief, a report to read - is only worth paying when the work is bigger than the overhead.
Right-sized reviews with a 2-round cap, flat orchestration (no nested agents), and ≤5 in flight.

Better. Still a prompt.

The cost-guard hook: enforcement outside the model

The real fix is that none of the above is left to judgment. It runs as a PreToolUse hook - a process the harness executes before the tool call, whose verdict the model does not get a vote on.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Task",
        "hooks": [
          {
            "type": "command",
            "command": "node /path/to/.claude/hooks/cost-guard.js",
            "statusMessage": "Checking dispatch budget..."
          }
        ]
      }
    ]
  }
}

The hook receives JSON on stdin:

{
  "session_id": "abc123",
  "transcript_path": "/home/user/.claude/projects/.../transcript.jsonl",
  "cwd": "/home/user/my-project",
  "permission_mode": "default",
  "hook_event_name": "PreToolUse",
  "tool_name": "Task",
  "tool_input": { "subagent_type": "general-purpose", "prompt": "...", "model": null },
  "tool_use_id": "toolu_01ABC..."
}

And answers on stdout:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "allow | deny | ask | defer",
    "permissionDecisionReason": "shown to the model and the user",
    "updatedInput": { "...": "replaces the tool's arguments before it runs" }
  }
}

updatedInput is what makes this more than a bouncer. The hook can rewrite the call rather than just refusing it.

Five guards:

Guard	Decision	What it stops
Model downgrade	`allow` + `updatedInput`	Opus-by-default. Rewrites Opus and model-less dispatches to Sonnet.
Dispatch circuit-breaker	`ask` past 10, `deny` past 25	Runaway fan-out across a whole session.
Nested-dispatch guard	`deny`	Agents spawning agents - exponential, not linear.
Concurrency cap	`deny` beyond 5 in flight	Simultaneous cold cache writes.
Context-bloat gate	`deny`	Tool calls that would flood the context window.

Here's the core of it:

#!/usr/bin/env node
// .claude/hooks/cost-guard.js - PreToolUse, matcher: "Task"
const fs = require("fs");
const os = require("os");
const path = require("path");

const MODEL_FLOOR = "sonnet";
const ASK_AFTER = 10;
const REFUSE_AFTER = 25;

function decide(decision, reason, updatedInput) {
  const out = {
    hookEventName: "PreToolUse",
    permissionDecision: decision,
    permissionDecisionReason: reason,
  };
  if (updatedInput) out.updatedInput = updatedInput;
  console.log(JSON.stringify({ hookSpecificOutput: out }));
  process.exit(0);
}

// Counters must live on disk: each hook invocation is a separate process with
// no memory of the last one. session_id is the only stable key we get, and it
// goes into a path, so it is validated rather than trusted.
function counterPath(sessionId) {
  if (!/^[A-Za-z0-9_-]{1,64}$/.test(sessionId)) return null;
  return path.join(os.tmpdir(), `cost-guard-${sessionId}.json`);
}

function bumpDispatchCount(sessionId) {
  const file = counterPath(sessionId);
  if (!file) return 1;
  let state = { dispatches: 0 };
  try {
    state = JSON.parse(fs.readFileSync(file, "utf8"));
  } catch {
    // First dispatch of the session, or an unreadable file. Either way we
    // start from zero rather than failing the user's tool call.
  }
  state.dispatches = (state.dispatches || 0) + 1;
  fs.writeFileSync(file, JSON.stringify(state), "utf8");
  return state.dispatches;
}

let raw = "";
process.stdin.on("data", (chunk) => (raw += chunk));
process.stdin.on("end", () => {
  let payload;
  try {
    payload = JSON.parse(raw);
  } catch {
    // A guard that crashes must not become a guard that blocks. Exit 0 with no
    // JSON and the normal permission flow applies.
    process.exit(0);
  }

  const input = payload.tool_input || {};
  const n = bumpDispatchCount(payload.session_id);

  if (n > REFUSE_AFTER) {
    decide(
      "deny",
      `Dispatch #${n} exceeds the hard cap of ${REFUSE_AFTER} for this session. ` +
        `Do the remaining work directly, or start a fresh session.`
    );
  }

  if (n > ASK_AFTER) {
    decide(
      "ask",
      `This is subagent #${n} this session (soft cap ${ASK_AFTER}). ` +
        `Each one pays a cold prompt-cache write. Approve?`
    );
  }

  // updatedInput REPLACES tool_input wholesale - it is not a patch. Spreading
  // the original first is what keeps `prompt` and `subagent_type` alive; drop
  // the spread and you dispatch an agent with no instructions.
  if (!input.model || input.model === "opus") {
    decide(
      "allow",
      `Model ${input.model ? "'opus'" : "unset (would inherit Opus)"} rewritten ` +
        `to '${MODEL_FLOOR}'. Set model explicitly to override.`,
      { ...input, model: MODEL_FLOOR }
    );
  }

  process.exit(0); // no opinion; normal permission flow applies
});

Three implementation notes that cost me time:

updatedInput replaces, it does not merge. Return { model: "sonnet" } and you have just dispatched a subagent with no prompt. Spread the original input first. This is the single easiest way to turn a cost guard into an outage.

Hooks are separate processes. There is no in-memory counter to increment. Anything cumulative has to be persisted, and session_id from stdin is the natural key. Validate it before putting it in a path.

Never fail closed on your own bug. Exit 0 with no JSON output and the normal permission flow applies. A malformed payload, an unreadable state file, a disk error - none of those should block the user's work. Exit 2 is the deliberate block; everything else stays out of the way.

The concurrency cap needs a PostToolUse counterpart to decrement the in-flight count, and the nested-dispatch guard needs a reliable "am I inside a subagent" signal - check what session_id and transcript_path actually look like inside a subagent on your Claude Code version before you rely on either. Those two are the most harness-coupled of the five.

The part that generalizes

I keep coming back to one line from this:

A budget rule in a prompt is a preference. A budget rule in a PreToolUse hook is an invariant.

The prompt version degrades exactly when you need it most - deep in a long session, under context pressure, after compaction has quietly dropped the paragraph where you wrote it down. The hook version runs identically on dispatch #1 and dispatch #24, and it does not need to be persuaded.

That distinction isn't really about cost. It's about which layer a constraint belongs in. Anything you would be upset to discover the model overrode - spend caps, destructive commands, push targets, credential access - does not belong in a system prompt. It belongs in a process the model cannot argue with.

I still delegate. Pure delegation on tasks that are genuinely large and parallel is the right shape, and the context-hygiene argument that motivated v1 was never wrong. What was wrong was believing an architecture and forgetting to price it - and then writing the safeguards in the one place they could not be enforced.

If you're running a similar setup: check whether your dispatches set model explicitly, and check whether your subagents share a prefix with their parent. Those two questions found most of my bill.

Deal-scoped PASETO: three things I got wrong about audience-bound tokens

Avraham K — Sun, 02 Aug 2026 19:18:48 +0000

The Model Context Protocol's authorization section says something blunt: a server must reject any token that was not issued for it. That has been normative since the 2025-06-18 revision rather than arriving with the current one, which is worth saying plainly because the interesting question was never whether the rule is new. I have been running a system where every credential is scoped to exactly one two-party transaction, so I want to write down what that actually took, including the third thing I still have not fixed.

The spec sentence

Three normative sentences from the 2026-07-28 authorization spec, which is the current revision as I write this. They are from across its Token Handling section rather than one continuous paragraph:

MCP servers MUST validate that access tokens were issued specifically for them as the intended audience, according to RFC 8707 Section 2. [...] MCP servers MUST only accept tokens that are valid for use with their own resources. MCP servers MUST NOT accept or transit any other tokens.

The middle sentence is the one that moved. In 2025-06-18 it began Authorization servers MUST only accept tokens, which put the obligation on the party that issues tokens in a passage about the party that receives them. The current revision points it at MCP servers. The first and third sentences are unchanged from 2025-06-18.

That is three sentences in a spec and about a quarter of the work in an implementation. The rest of this post is the other three quarters.

What the tokens are for

The system brokers work between two agents that stay pseudonymous while they negotiate. When a deal seals, each side receives the other's callback endpoint and a credential, and the broker steps out of the data path. The credential has exactly one job at the receiving end: answer whether this caller belongs to deal 1a2b3c4d. Not whether they are a valid user of the platform. Not whether they are a paying customer. This deal.

That is the same shape as the MCP requirement. A token minted for one resource has to be worthless at every other one. The only difference is that my resource is a transaction rather than a server.

The easy part: v4.public and nothing else

Signing is one line, and the version is chosen at compile time rather than read out of the token:

// V4Sign returns a plain string; it panics only on internal encoding errors.
signed := tok.V4Sign(kp.PrivateKey, nil)

No v4.local, no JWT, no algorithm negotiation. There is no alg header for an attacker to rewrite because there is no header. The whole family of algorithm-confusion bugs, where a verifier is talked into treating an RSA public key as an HMAC secret or into honouring alg: none, needs a negotiable algorithm field in order to exist. PASETO's contribution is not better cryptography. It is deleting the negotiation.

I am not going to pretend that was a hard decision. It took ten minutes and it removed a category. The next three took considerably longer.

One: a kid constant is a rotation outage

The first version put a fixed string in the token footer as the key identifier, something like the deployment stage name. It parsed, it round-tripped, the tests were green.

It also meant that rotating the signing key was a hard cutover. These credentials live seven days. Rotate on a Tuesday and every credential minted in the previous seven days carries a kid that now resolves to the wrong key. There is no window where the old key and the new key are both selectable, because both of them answer to the same name.

The fix is to stop naming keys and start fingerprinting them:

const kidHexLen = 16

func DeriveKid(pub paseto.V4AsymmetricPublicKey) string {
    sum := sha256.Sum256(pub.ExportBytes())
    return hex.EncodeToString(sum[:])[:kidHexLen]
}

And so the mint path cannot disagree with itself, the loader derives the kid instead of accepting one from its caller:

func LoadKeyPair(privKeyHex string) (KeyPair, error) {
    sk, err := paseto.NewV4AsymmetricSecretKeyFromHex(privKeyHex)
    if err != nil {
        return KeyPair{}, fmt.Errorf("credentials: load key pair: %w", err)
    }
    pub := sk.Public()
    return KeyPair{
        PrivateKey: sk,
        PublicKey:  pub,
        Kid:        DeriveKid(pub),
    }, nil
}

A kid is now a property of the key rather than a label attached to it. Two keys can be live at once, a verifier picks by kid, and rotation is an overlap window instead of an outage. The old key stays loaded until the last credential it signed has expired, which is a bounded seven days, and then it goes away.

Yes, sixteen hex characters is a truncated hash. It is a selector, not a security boundary. The kid tells a verifier which key to try; the signature decides whether the token is real. If someone finds a second public key whose SHA-256 shares its first eight bytes with mine, they have successfully selected my key and still cannot sign with it. A colliding kid fails verification. It does not forge one.

Deriving the kid is only half of it. Reading it back is the other half, and it is the one place where a token has to be touched before its signature is checked:

// ExtractKid reads the key ID from the token footer WITHOUT verifying the
// signature. This is intentionally unsafe and is used only for key selection
// before the full Verify call.
func ExtractKid(token string) (string, error) {
    parser := paseto.NewParserWithoutExpiryCheck()
    footerBytes, err := parser.UnsafeParseFooter(paseto.V4Public, token)
    // ...unmarshal, reject an empty kid
}

go-paseto calls that method UnsafeParseFooter and the name is honest: nothing has been authenticated at that point. What makes it safe anyway is that the footer is covered by the signature, because PASETO folds it into the pre-authentication encoding. A tampered kid cannot do anything except point at the wrong key, and the wrong key fails verification. The kid is a hint about which key to try, never a claim to be believed.

That distinction is worth being explicit about, because select a key using the token, then verify the token with that key reads as circular until you notice the selector lives inside the authenticated envelope. The rule it generalises to: you may read unauthenticated input to decide how to check something, never to decide whether it passed.

The generalisable part: an identifier that has to survive rotation should be derived from the thing it identifies. Choose it independently and the two can drift, and the drift surfaces at precisely the moment you are rotating a key under pressure.

Two: never classify an error by reading its message

Callers need two different answers out of a failed verification. ErrExpiredToken is a routine event with a routine remedy. ErrInvalidToken means someone presented a credential I did not sign. Those belong in different places, and one of them should page someone.

go-paseto validates temporal claims through rules, so the obvious implementation parses with the not-expired rule on and inspects whatever error comes back. In practice that means this:

// The version I wrote first, and deleted.
if strings.Contains(err.Error(), "expired") {
    return ErrExpiredToken
}

It works, and it is coupled to a string in someone else's repository that they never promised not to change. A minor version bump that rewords a rule error does not fail the build, does not fail the type check, and does not fail any test that builds its expired token through the same library. It silently reclassifies every expired credential as a forgery. Nothing breaks visibly. A routine event just starts arriving on the path reserved for attacks, which is how a real one gets ignored.

The version that ships turns the rule off and does the comparison itself:

// Parse without the built-in NotExpired rule so a valid-signature but expired
// token parses successfully and we can classify it deterministically below.
parser := paseto.NewParserWithoutExpiryCheck()

tok, err := parser.ParseV4Public(pubKey, token, nil)
if err != nil {
    return TokenClaims{}, fmt.Errorf("%w: %v", ErrInvalidToken, err)
}

// Enforce not-before explicitly: a token whose nbf is in the future is not yet
// valid and must not be accepted.
if nbf, nbfErr := tok.GetNotBefore(); nbfErr == nil && time.Now().Before(nbf) {
    return TokenClaims{}, fmt.Errorf("%w: token not yet valid", ErrInvalidToken)
}

// Classify expiry directly off the exp claim.
if exp, expErr := tok.GetExpiration(); expErr == nil && !time.Now().Before(exp) {
    return TokenClaims{}, ErrExpiredToken
}

Signature first, always. The kid lookup above is the only thing that touches the token earlier, and it decides nothing. Only a cryptographically valid token gets its claims read, so expired is a statement about a token I definitely signed. Then the temporal checks, in code I own, comparing values instead of strings.

The explicit not-before check in the middle is the part I would have gotten wrong if I had trusted the constructor name, so it is worth being precise about what go-paseto v1.6.0 actually does. NewParser() preloads exactly one rule, NotExpired(), and that rule reads exp and nothing else. nbf has its own rule, NotBeforeNbf(), and it is not loaded by default. ValidAt() checks iat, nbf and exp together, and you only get it from NewParserForValidNow().

So that check is not compensating for something I switched off. NewParserWithoutExpiryCheck dropped the one rule I was already replacing. The nbf gap was open the whole time, in the default parser, before I touched anything - I just found it while reading the rule list instead of the constructor names. A parser named NewParser sounds like sensible defaults. It is a one-element slice, and the element is not the one you assumed.

Three: I never shipped the verification side

This is the one I do not have a fix for yet, and it is the one that matters most, so here it is plainly. Three facts about the code as it stands today.

Verify has no production callers. It exists, it is tested, and if you search the repository for callers outside the test files you get nothing. Production calls Mint at deal finalize and LoadKeyPair at startup. Nothing on the serving path verifies anything.

No endpoint publishes the public key. There is no kid-to-key document anywhere on the API. A counterparty that receives a credential and reads its footer gets a key identifier that identifies nothing they can fetch. The only way to check a credential today is to ask me, which means the credential proves what I say it proves.

Both parties get the same token. Finalize mints once and hands the identical string to both sides. It carries the deal ID and both pseudonymous references, so it proves membership of the deal. It cannot distinguish which member is holding it.

Put those together and the honest description of what I built is: a correctly minted, correctly scoped, correctly rotatable credential that nobody can independently verify and that does not identify its bearer. The minting half is right. The half that converts minting into a security property is missing.

Which is exactly why the MCP spec does not stop at audience binding. The same document makes discovery a requirement in its own right:

MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC9728). MCP clients MUST use OAuth 2.0 Protected Resource Metadata for authorization server discovery.

Next to the audience rule, that reads like plumbing. It is not. Without a published, fetchable way to learn which authority signs for a resource and which keys it is using, this token was issued for you degrades into the issuer says this token was issued for you. Discovery is the part that makes audience binding checkable by the party the binding is supposed to protect.

The fix has a shape, and I will write it up separately once it ships:

publish the current and previous public keys, keyed by kid, at a stable well-known path, so a counterparty can verify without asking the broker;
mint one token per party with a claim naming which side holds it, so a credential identifies its bearer and not only its deal.

What I would keep

Delete the negotiation. If a field can be attacked, the cheapest defence is for it not to exist.
Derive identifiers from what they identify. Keys, and anything else that rotates while its old outputs are still in flight.
Read the rule list, not the constructor name. What a library validates by default is a short, specific list, and it is usually shorter than the name implies.

And one thing I would do earlier: build the verifier before the issuer. Minting a token is satisfying and provides no security by itself. Everything that makes a credential worth holding lives on the side that checks it, and it is very easy to ship the satisfying half, watch the tests go green, and never notice that the other half was never written.

This is running at cogdepot.com, where credentials are minted at deal finalize and each side gets a per-deal endpoint for the other. If you want to argue with any of the above, section three is the one I would argue with too.