Threat Model

Methodology

Three independent adversarial analyses were conducted:

1. Ad-tech fraud history: Every major fraud category from 20+ years of programmatic advertising, mapped to RAMP equivalents
2. Content licensing abuse brainstorm: 56 attack vectors from each party’s perspective (dishonest exchange, agent, provider, broker, attacker)
3. STRIDE security threat model: Formal threat modeling of the protocol’s technical surface

Key Lesson from Ad-Tech History

Every self-reported field gets gamed. Any claim that is not cryptographically attested by a trusted party will be falsified if there’s economic incentive.

This single pattern accounts for most ad-tech fraud: domain spoofing (self-reported domain), geo spoofing (self-reported location), viewability fraud (self-reported measurement), and attribution fraud (self-reported conversion). RAMP must learn from this.

1. Supply-Side Threats (Dishonest Exchange Operator)

T1: Hidden fee inflation

Attack: Exchange charges agent $0.75 but tells provider the rate was $0.50, pocketing the spread. Ad-tech parallel: The “unknown delta” from ISBA study — 15% of spend unaccounted for. Countermeasure (protocol): Offers are cryptographically signed by the Exchange (Ed25519). Provider can verify prices weren’t inflated beyond RSL terms. Countermeasure (reconciliation): Provider compares CDN access logs against Exchange-reported transaction volumes and revenue.

T2: Dynamic price discrimination

Attack: Exchange serves different prices to different buyers for identical content. Countermeasure (protocol): Not directly preventable — price discrimination is a business decision. If prices are derived from RSL (provider-set), the Exchange can’t inflate beyond RSL terms without detection. Countermeasure (reconciliation): Brokers querying from different identities can detect discrepancies.

T3: Bait-and-switch content

Attack: Offer describes “2026 Q4 Financial Report, 15,000 words” but signed URL delivers different content. Ad-tech parallel: Inventory misrepresentation (declaring premium placement, serving remnant). Countermeasure (protocol): Content hash in the Offer. ResourceIdentity.content_hash commits to content at offer time. Agent verifies after fetch. Mismatch = dispute.

T4: Phantom transactions / ghost billing

Attack: Exchange fabricates billing_ids that never corresponded to real agent requests. Ad-tech parallel: Impression inflation by exchanges. Countermeasure (protocol): Mutual transaction receipts. Agent’s idempotency key in TransactionRequest is agent’s proof; Exchange’s billing_id is Exchange’s proof. Neither can forge the other’s Ed25519 signature.

T5: Provider revenue skimming

Attack: Exchange tells provider 1,000 transactions occurred; actually processed 1,500. Countermeasure (reconciliation): Three-sided reconciliation. Provider’s CDN logs, Exchange’s transaction log, and usage reports must all agree. Countermeasure (protocol): Signed URLs include transaction_id in URL parameters for CDN-to-Exchange reconciliation.

T6: Overly long signed URL expiry

Attack: Exchange issues 24-hour URLs instead of 5-minute, enabling reuse. Countermeasure (protocol): Protocol mandates maximum URL TTL (5 minutes). Provider’s edge function enforces independently.

T7: Signing key leakage

Attack: Exchange shares signing keys with a preferred buyer, enabling URL forgery. Countermeasure (protocol): Asymmetric signing. Provider holds the private key; Exchange requests signed URLs from provider’s signing service.

2. Demand-Side Threats (Dishonest Agent / Buyer)

T8: Signed URL sharing

Attack: Agent A pays, shares signed URL with Agents B, C, D before expiry. Countermeasure (protocol): Agent-bound signed URLs. Embed the agent’s RFC 7638 JWK Thumbprint (agent_identity_hash) in the HMAC-signed URL; a capable edge function requires the fetcher to present its public key + an RFC 9421 signature (proof-of-possession) and checks thumbprint(presented key) == agent_identity_hash. Implemented via agent_identity_hash on TransactionResponse.

T9: Systematic caching / content mirroring

Attack: Agent fetches every article once, caches locally forever, never pays again. Countermeasure (protocol): Single-use signed URLs. Edge function marks URL as consumed after first fetch. Countermeasure (legal): License terms prohibiting caching beyond session scope.

T10: Usage underreporting (token count)

Attack: Agent reports using 500 tokens of a 10,000-token document but ingested the entire thing. Countermeasure (protocol): Exchange sets minimum billable quantity equal to document’s actual size. UsageReport.consumed_quantity cannot be less than content’s known size.

T11: Function misreporting (RAG vs training)

Attack: Agent declares function: ai-input (cheaper) but uses content for function: ai-train (prohibited or more expensive). Countermeasure: Not solvable at protocol level. Agent’s internal processing is a black box. Legal/contractual enforcement only.

T12: Offer metadata harvesting

Attack: Agent calls DiscoverResources repeatedly, extracting metadata — never transacting. Ad-tech parallel: Bid stream data harvesting. Countermeasure (protocol): Rate limiting on DiscoverResources. Exchange tracks query-to-transaction ratio per agent.

T13: Credential sharing / proxy laundering

Attack: One billing reference shared across organizations. Countermeasure (protocol): Anti-abuse is anchored on the verified requester identity (domain/key), not on the self-supplied billing_ref (an opaque billing handle that proves no entitlement). Exchange monitors usage patterns (IP diversity, volume spikes). Ed25519 agent signatures bind requests to specific key pairs; billing_ref only attributes cost.

3. Provider-Side Threats (Dishonest Provider)

T14: Paywall-gated garbage

Attack: Compelling headline, but behind the paywall: padding, filler, or unrelated content. Countermeasure (protocol): Content integrity hash catches changed content. Exchange curation/reputation systems address quality.

T15: Word count / token count inflation

Attack: Provider pads content to inflate word count, affecting unit_cost calculations. Countermeasure (protocol): Exchange independently verifies content length during RSL ingestion. Agent independently tokenizes after fetch.

T16: Content versioning fraud

Attack: Provider changes content at URL after Exchange has priced it. Countermeasure (protocol): Content integrity hash in the Offer. SHA-256 of content at offer creation time. Agent verifies after fetch.

T17: Double-selling with exclusivity claims

Attack: Provider grants “exclusive” licensing to multiple Exchanges. Countermeasure: ResourceIdentity enables detection (same content_hash from different exchanges). Prevention requires legal contracts.

T18: Selective enforcement / preferential access

Attack: Edge function blocks some agents but quietly allows others to scrape freely. Countermeasure: Not solvable at protocol level. Market dynamics address it.

4. Broker Threats

T19: Hidden orchestration fee

Attack: Broker adds markup to every offer relayed to the agent. Countermeasure (protocol): Exchange signs offers (Ed25519). Broker passes through signed offers. Agent verifies the price was not tampered with.

T20: Kickback-driven offer selection

Attack: Broker always routes to a specific Exchange regardless of pricing. Countermeasure (protocol): Agent can bypass Broker and query Exchanges directly. Each forwarding party adds its own RFC 9421 HTTP Message Signature to the request — covering the request plus the prior hop’s signature — so the ordered stack of signatures in the HTTP headers is a tamper-evident forwarding chain that provides non-repudiation. Reordering, dropping, or inserting a hop breaks a downstream signature, and the Exchange verifies the whole stack.

T21: Query intelligence harvesting

Attack: Broker logs every DiscoverResources query, sells the data. Countermeasure: Not solvable at protocol level. Data handling agreements required.

5. Third-Party Attacks

T22: Exchange impersonation

Attack: Attacker sets up fake Exchange, poisons ramp.json via DNS hijack. Countermeasure (protocol): ramp.json served over HTTPS from provider’s domain (TLS proves endorsement). Every Offer carries exchange_signature (Ed25519). Agent verifies against Exchange’s public key.

T23: Signed URL interception (MITM)

Attack: Attacker intercepts TransactionResponse, steals signed URL. Countermeasure: HTTPS everywhere. Agent identity binding prevents reuse.

T24: Transaction replay

Attack: Attacker captures valid TransactionRequest and replays it. Countermeasure (protocol): Idempotency keys. TransactionRequest.id is unique. Exchange rejects duplicates.

T25: Billing_id forgery in usage reports

Attack: Attacker fabricates billing_ids in usage reports. Countermeasure (protocol): Exchange validates billing_id exists in transaction log before accepting usage reports.

T26: DiscoverResources flooding (DoS)

Attack: Flood DiscoverResources to exhaust Exchange resources. Countermeasure (protocol): Per-partner rate limiting keyed on the verified requester identity (RFC 9421 request signature — domain/key), not on the self-supplied billing_ref. Anonymous queries rejected.

6. Systemic / Arbitrage Threats

T27: Content arbitrage (buy low, resell high)

Attack: Entity buys from Exchange A at $0.04, resells via own Exchange at $0.05. Countermeasure (protocol): ResourceIdentity enables detection. ramp.json declares authorized sellers.

T28: Free content laundering

Attack: Scrape freely available content, package behind paywall as “premium.” Countermeasure: Content fingerprinting against known free content databases.

T29: Synthetic content farming

Attack: Generate AI content at near-zero cost, sell as human-authored. Countermeasure: CoMP’s Text.sourcetype field. Future: C2PA content credentials.

T30: License tier arbitrage

Attack: Buy at grounding rate, use for training. Collapses pricing model at scale. Countermeasure: Black box problem. Legal/contractual enforcement only.

Prevention Taxonomy

Level	Threat IDs	What It Means
Preventable at protocol level	T3, T4, T5, T6, T7, T8, T9, T12, T16, T19, T22, T23, T24, T25, T26, T-ATT-1, T-ATT-2, T-ATT-3, T-ATT-5, T-DEL-1, T-DEL-2, T-DEL-3, T-DEL-4, T-DEL-5, T-DEL-6	Protocol changes make the attack structurally impossible
Detectable via reconciliation	T1, T2, T4, T5, T13, T14, T15, T17, T27, T-ATT-4	Three-sided reconciliation catches it
Legal/contractual only	T10, T11, T13, T17, T18, T20, T21, T28, T29, T30	Can’t enforce technically

The Three Lines of Defense

Line 1: Protocol-level prevention
  Signed offers, content hashes, agent-bound URLs, idempotency keys,
  holder-bound JWT delegation chain (cnf), RFC 9421 forwarding-chain verification
  (stack of per-hop HTTP Message Signatures), subscription-level quota tracking
  Makes attacks structurally impossible

Line 2: Three-sided reconciliation
  CDN logs + Exchange transactions + Usage reports
  Detects discrepancies that slip past Line 1

Line 3: Legal/contractual enforcement
  Audit rights, licensing terms, dispute resolution
  Handles the black-box problem (what agent did internally)

7. Attestation-Specific Threats

T-ATT-1: Forged attestation injection

Attack: Attacker crafts a fake ResourceAttestation with a fabricated verifier domain and pushes it via CatalogService.PushContent. Countermeasure (protocol): Exchange verifies caller_id is listed in the provider’s catalog_contributors (from ramp.json). Exchange verifies the attestation signature against the verifier’s public key in public_keys from its /.well-known/ramp.json. RAMP has no dedicated verifier role; a verifier publishes under its operator’s role (ROLE_PUBLISHER for a self-attesting publisher, ROLE_EXCHANGE for a standalone vendor). Both checks must pass.

T-ATT-2: Stale attestation exploitation

Attack: Provider updates content (e.g., replaces article with filler) but the catalog retains the old attestation claiming 5000 tokens. Agent pays based on stale claims. Countermeasure (protocol): attested_at timestamp enables agent freshness checks. Agents reject attestations older than their threshold for the content type (e.g., 4 hours for breaking news). Content hash mismatch (Level 1) triggers auto-credit via the dispute system. Countermeasure (reconciliation): CDN response size corroborates discrepancies. 800 bytes for a 5000-token claim is auto-creditable regardless of hash match.

T-ATT-3: Verification vendor compromise

Attack: Attacker compromises a third-party verifier’s Ed25519 private key and signs fraudulent attestations for arbitrary content. Countermeasure (protocol): Key rotation via JWKS pattern — keys have not_before / not_after windows. Exchange caches the verifier’s ramp.json with TTL-based refresh (1 hour default). Compromised key can be revoked by removing it from the verifier’s ramp.json public_keys. Countermeasure (operational): Exchange monitors attestation patterns per verifier. Sudden changes in claim distributions trigger investigation.

T-ATT-4: Claims inflation attack

Attack: Provider self-attests inflated estimated_quantity: 10000 for a 500-word article, computes a valid content hash for the actual (short) content, and prices based on the inflated count. Countermeasure (protocol): CDN response size is the corroboration signal. CDN log showing a 2KB response for a 10000-token claim is auto-creditable. Agent files dispute with INCOMPLETE_CONTENT reason; Tier 1 auto-resolution via CDN corroboration. Countermeasure (pattern): Provider flagged for investigation when token discrepancy rate exceeds 2%. Graduated consequences apply.

T-ATT-5: Catalog contributor spoofing

Attack: Unauthorized party registers a domain similar to a legitimate verifier (e.g., doub1everify.com) and pushes attestations claiming to be a trusted vendor. Countermeasure (protocol): catalog_contributors in ramp.json uses exact domain matching. The provider must explicitly list the contributor’s domain. The Exchange fetches ramp.json from the exact verifier domain in the attestation and verifies the signature against that domain’s public_keys.

8. Delegation and Authorization Threats

T-DEL-1: Delegation token theft

Attack: Attacker steals a delegation token (e.g., via log exfiltration, memory dump, or network interception) and attempts to use it to access resources within the token’s scope. Countermeasure (protocol): Holder binding neutralizes theft. A delegation token is bound to the holder’s key (via cnf.jkt for the default JWT; sealed/attenuated to the key for the optional biscuit-v3 profile), and verification requires the key that signs the HTTP request (RFC 9421) to equal the bound key (see Verification step 3). A thief who steals the token bytes but not the private signing key cannot produce a valid request — the token is not bearer-usable, so theft alone grants nothing. Spend caps (max_spend_cents), access caps (max_accesses), short TTLs, and optional revocation_uri checking are defense-in-depth that bound the blast radius in the residual case where the holder’s signing key is also compromised. This is why T-DEL-1 is listed as structurally preventable rather than merely mitigated.

T-DEL-2: Delegation scope escalation

Attack: Attacker attempts to widen permissions by manipulating the delegation chain (e.g., editing a child JWT to escalate from ai-search to ai-train, or splicing in a forged link). Countermeasure (protocol): The delegation chain narrows only, and is cryptographically linked. Each delegation JWT is Ed25519-signed, and a child’s scope MUST be covered by its parent’s (verified) — it can narrow, never widen. The chain-linkage invariant requires each JWT to be signed by the key the parent named in cnf; editing or splicing a link breaks signature verification against the upstream cnf. The Exchange verifies the full chain (and the request-signing key against the final cnf.jkt) before granting access.

T-DEL-3: Revocation bypass

Attack: Principal revokes a delegation but cached or stored tokens continue to work until their expires_at timestamp. Countermeasure (protocol): Short expires_at (2-4 hours for standard access) limits the window of continued access. For high-value transactions, Exchange checks revocation_uri in real time before fulfillment. Trade-off: revocation checking adds latency (~50ms) so is only used for transactions above a configurable value threshold.

T-DEL-4: Forwarding chain forgery

Attack: Attacker inserts a fake hop into the forwarding chain, claiming to be a trusted Broker to gain access or inject misleading provenance — or reorders or drops an existing hop. Countermeasure (protocol): The forwarding chain is a stack of RFC 9421 HTTP Message Signatures (Ed25519). Each forwarding party adds one labeled signature covering the request plus the prior hop’s signature, so the chain is tamper-evident. Exchange verifies every signature on the request against the signer’s published public key at {domain}/.well-known/ramp.json (role=ROLE_AGENT, selected by keyid) and verifies the whole stack. A forged, reordered, dropped, or inserted hop breaks a downstream signature, causing the entire request to be rejected.

T-DEL-5: Scope pollution

Attack: Agent declares scopes it doesn’t actually have (no delegation token to prove entitlement), hoping the Exchange trusts the declared scopes and returns premium content. Countermeasure (protocol): Exchange treats Requester.scopes as an upper bound for catalog filtering only. Actual entitlements are verified via the delegation JWT at transaction time. Without a valid delegation token, the Exchange applies its default access policy (typically public resources only). Declared scopes without a matching delegation grant no additional access.

T-DEL-6: Quota gaming via multiple tokens

Attack: Agent obtains multiple delegation tokens for the same subscription (e.g., by requesting new delegations from different intermediaries) to exceed per-subscription quotas. Countermeasure (protocol): Exchange tracks quotas by subscription_id, not by delegation token. All tokens referencing the same subscription share one counter. Multiple tokens for the same subscription do not multiply the quota. Rate limiting is applied at the subscription level regardless of how many delegation tokens reference it.

9. Licensing-Layer Threats

T-LIC-1: SSRF / phishing via License.uri

Attack: A malicious publisher pushes a term whose License.uri points at an internal address — http://169.254.169.254/latest/meta-data/… (cloud metadata), http://localhost:6379/, or file:///etc/passwd. An agent platform that auto-fetches the document to “read the license before use” (REFERENCE_ONLY requires this) issues a server-side request into its own infrastructure — leaking cloud credentials, reaching internal services, or reading local files. A variant points uri at attacker-controlled HTTPS to harvest the fetcher’s identity/IP or serve misleading terms. Countermeasure (protocol): License.uri is deliberately never rejected at ingest (data-labels TDL identifiers use non-URL schemes) — but “do not reject” is not “blindly fetch.” A consumer that resolves uri MUST: (a) allowlist schemes (https + known TDL schemes); (b) block loopback, link-local, private, and cloud-metadata IP ranges, resolving-then-checking to defeat DNS rebinding; (c) fetch client-side through an egress proxy, never from the Exchange’s privileged network; (d) treat the fetched bytes as untrusted content. The Exchange applies the same rules when it fetches to pin uri_digest (T-LIC-4).

T-LIC-2: Silent restriction downgrade

Attack: A publisher forbids training (Restriction{kind: FUNCTION, prohibited: ["ai-train"]}) but the consumer does not recognize a token, or the publisher forgot to mark the restriction binding. The consumer treats it as advisory and proceeds — silent infringement with plausible deniability. Countermeasure (protocol): Restriction.advisory is fail-closed by default (it inverts the COSE-crit opt-in). A restriction is binding unless advisory = true; a consumer that cannot evaluate every token in a binding restriction MUST decline the term. A forgotten flag therefore fails safe — publishers opt into leniency explicitly and never lose protection by omission.

T-LIC-3: Scope-gating escalation

Attack: Term visibility is gated by delegation scope coverage (LicenseTerm.scopes, AND-semantics, empty = public). Two failure modes: (a) a publisher forgets scopes on a premium term → it defaults to public and leaks for free; (b) two implementations match scopes differently — naive prefix matching lets sub: cover subscription:premium, or dist:* is read as covering dist:US:internal on one Exchange but not another → an agent’s grant is read as covering a term it should not. Countermeasure (protocol): Scope matching follows the single normative rule defined in Scope Matching (M9), and the same rule applies to both Requester/delegation scopes and LicenseTerm.scopes — there is exactly one matching algorithm: matching is segment-wise (:-delimited), never substring/prefix; a granted * segment matches one level and a terminal * matches all remaining segments; there is no implicit prefix match and a grant narrower than the requirement does not cover it. This is the authoritative string-segment definition. An Exchange MAY implement coverage with Biscuit authorization (Datalog) instead of literal string comparison, but the Datalog rules MUST produce results identical to the segment-wise definition — Datalog is a conformant implementation, not a second, divergent rule. So the example failures (sub: covering subscription:premium, or one Exchange reading dist:* as covering dist:US:internal and another not) are excluded by construction. empty = public stays the explicit, documented default; backfilling a sentinel scope (e.g. r:all) is not required — it only relocates the “forgot to set it” failure and forces every publisher to issue an extra scope grant, without adding enforcement. (cf. OAuth 2.0 and AWS IAM: exact-match with explicitly-defined wildcard expansion, no implicit hierarchy.)

T-LIC-4: Referenced-document swap

Attack: A term carries a License.uri; the agent fetches and trusts the document. The publisher (or a MitM on the fetch) later changes the bytes at uri — which is just a URL — so the agent’s understanding of the terms silently diverges from what was offered. immutable: true makes this worse (the agent caches and stops re-checking), but a mutable uri is swappable too. Countermeasure (protocol): License.uri_digest pins the document as method:hexdigest and is required whenever uri is present — any semantics, mutable or not. The Exchange pins it at ingestion (computing it over the safely-fetched document per T-LIC-1, or accepting a publisher-supplied value for non-HTTP schemes). Because the entire Offer is signed, the digest is tamper-evident; the agent verifies the bytes it fetches against it and refuses on mismatch.

Comparison to Ad-Tech Fixes

Ad-Tech Fix	Year	RAMP Equivalent	Status
ads.txt	2017	ramp.json (authorized sellers)	In proto
sellers.json	2019	Exchange identity in ResourceResponse	In proto
SupplyChain Object	2019	exchange_signature on Offer	In proto
ads.cert	2020	exchange_signature + content_integrity_hash	In proto
MRC Viewability Standard	2014	Minimum billable token count	Design principle
Open Measurement SDK	2018	Three-sided reconciliation	In protocol flow