RAVEN. / threat model

Threat model before token action

When agents get real-world actions, old security basics matter more, not less. An agent is untrusted automation until constrained by input validation, action scoping, audit logs, rate limits, deterministic checks, and fail-closed policy. Raven is the signed preflight control layer between untrusted token input and real token action. Machine-readable: /agent-threat-model.json.

Untrusted in, signed out

Untrusted: user messages, chat history, agent memory, social links, token websites, screenshots, token lists, launchpad claims, third-party labels, model summaries, and every user-supplied field — mint, tokenProgram, metadataAddress, poolAddress. Raven accepts candidate evidence, not trusted evidence: supplied fields help locate accounts to check; they become facts only after Raven verifies what it can verify and reports what it could not. Rejected outright: rpcUrl, issuerIdentity, keys, wallet signers, transaction instructions, and any user- or model-generated verdict. Trusted: the signed receipt after ed25519 verification against /pubkey, the exact receipt JSON, finding codes, coverage gaps, engine version, observed slot.

STRIDE for token-touching agents

Spoofing — fake keyId, fake verifier, fake badge. Tampering — modified receipt, removed gap. Repudiation — no exact receipt stored, no verification record. Information disclosure — leaked or browser-exposed keys, secret logging. Denial of service — unbounded verify loops, quota exhaustion, batch abuse. Elevation of privilege — a model using a Raven result to request wallet signer permission or bypass human approval. Each maps to a drill: failure drills (now 20).

Separate discovery, verification, and action tools

Discovery tools (search, chat, token lists, launchpad pages) find candidates. Verification tools (/verify, /pubkey, local MCP, an ed25519 library) produce and check signed receipts. Action tools (wallet signer, swap router, listing API) execute. Decision policy sits between verification and action. Action tools must never run solely because discovery context or model memory says a token is acceptable. Model obedience is not a control; tool permissions must be narrower than the model's imagination.

Receipts are scoped

A receipt covers this mint, the evidence actually checked, this observed slot, this engine version — not every future action. A receipt for mint A cannot verify mint B; no poolAddress means no pool evidence and no liquidity inference; an old receipt must be reverified before spend/list/route. Agents must not expand a receipt's scope by inference. Also untrusted: package-manager output, README install commands, build logs, and dependency names suggested by errors — see the supply chain policy.

What Raven does not protect

Raven does not authenticate your users, manage wallets or custody, fix vulnerabilities in your own code, certify tokens as safe, or give financial advice. Downstream controls — authn/authz, receipt storage, staleness handling, rate limiting, human escalation, wallet separation, redacted audit logs — belong to the integrator. Incident review starts with one question: which exact receipt was used, and was its signature verified?