Attack Lab #3: Our Attribution Was Theater — Anyone Could Spend With Your Agent

Attack Lab · Episode 3. Last episode we said we'd go after attribution. Turns out: the foundation was empty.

Episode 1: six attacks, all blocked. Episode 2: we found we hadn't implemented daily cumulative limits, and added a sixth gate. This episode we went after Pillar 1 of the whole framework: Identity & Attribution (KYA).

It didn't hold. It collapsed harder than we expected.

The attack: I spend your money with your agent

Our KYA gate did one thing: check whether an agentId had been attributed to a KYC'd entity. Attributed → pass.

It never checked: are you that agent?

Real run, live gateway:

1) Victim attributes their own agent
   → attributed: Victim Corp (KYC'd)

2) Attacker (a completely different party) pays using the victim's agentId, zero credentials
   → 200 allow
   → the KYA gate's own words: "attributed: Victim Corp"

3) Attacker overwrites the victim's attributed entity
   → that agent now attributes to: "I am the attacker"

Step 2 is fatal: I need to know nothing but your agentId to spend against your mandate — while the KYA gate cheerfully assures you the payment is "attributed to Victim Corp."

Step 3 is worse: the attacker can point attribution at anyone. The audit chain is poisoned at the root — when you go looking for who to hold responsible, the log points at an innocent entity.

The root cause: authentication ≠ authorization

We conflated two questions:

• "Does this identity exist?" (we did this)
• "Are you this identity?" (we did not)

Doing only the first is checking at the door whether an ID card is genuine — without looking at whether the person holding it is the person on it.

Attribution without proof is theater. And Pillar 1 is the foundation of the entire RAP framework — if the foundation is theater, the five gates above it are decoration. That's an unpleasant sentence to write, and it's the most important conclusion here.

The patch: a seventh gate, KYA/Proof

Registration now issues a one-time credential (agentSecret), and every later call must present it:

• Paying without it / with a mismatch → blocked at KYA/Proof
• Updating an already-attributed agentId → requires the original credential, else refused (no attribution tampering)

After the patch, the same three attacks:

| Attack | Before | After | |---|---|---| | Pay with someone else's agentId (no credential) | 🔴 200 allow | ✅ 403 at KYA/Proof | | Overwrite another's attributed entity | 🔴 succeeded | ✅ refused | | Legitimate holder pays with credential | 200 | ✅ 200 (no false positive) |

That last row matters just as much: after a fix, legitimate traffic must still pass. A gate that kills good payments eventually gets switched off.

Three lessons

1. The most basic layer is the one nobody checks. We spent real effort polishing limits, allowlists, intent matching — the things that look like security. Meanwhile "who are you" at the foundation was simply assumed. Attackers don't attack the part you polished.

2. "Attributed" can be a lie that comforts you. The dangerous thing isn't having no KYA — it's having a KYA that lies, because it makes you believe the check happened. People without a defense are careful. People who think they have one aren't.

3. We've now broken our own gateway three episodes running. Episode 1 read like good news. Episode 2 found a missing limit. Episode 3 found the foundation empty. This is exactly why the Attack Lab exists — if we don't attack ourselves, someone else will, and they won't tell us.

We publish every break, including the ugly ones. A standard's credibility doesn't come from claiming completeness — it comes from whether its authors publish the results when they break it themselves.

Next episode

We're going after the audit chain: can the log of a blocked attack be forged or erased?

Attack it yourself: oceanalt.com/firewall · Test with your own agent: integration guide

(OceanAlt Attack Lab · research note)