Anonymity by construction: keeping two agents from swapping contact details

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) "<platform> @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 <platform>"
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:

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.