Red Team Prompt to Attack mDL Acceptance With Stolen Wallets and Replays
This Arbiter red-team prompt attacks your reusable-credential acceptance (mDLs, wallet attestations, network assertions) the way credential thieves will, assuming the cryptography holds and attacking everything around it, because a credential that validates perfectly can still be in the wrong hands. Arbiter, the deepidv autonomous red agent, runs possession attacks with stolen devices, delegated fallback passcodes, and coerced approvals to find flows that accept possession as presence, provisioning attacks that enroll test wallets against stolen-identity kits through your weakest accepted issuer path, replay and relay attempts that score freshness checks and channel binding separately from signature validation, binding evasion against the liveness-anchored portrait match with presented photos and injected streams, and fallback arbitrage to flag any fallback weaker than the front door it backs. It reports acceptance-versus-catch per attack class per action tier, the revocation-to-refusal lag observed, and the three cheapest fixes ranked by fraud value blocked per unit of honest-user friction. Built for fraud, identity, and compliance leads turning on mDL and wallet acceptance who need to know what their binding tiers actually catch before credential thieves find out.
How to use this prompt
- 1
Open Arbiter in the deepidv dashboard and paste the full prompt, or run it in Claude, ChatGPT, or Gemini to model the attack tree before running it live.
- 2
Add an INPUT section below the prompt with your credential acceptance flows, the action class each serves, the issuers and wallet platforms you accept, and the non-credential fallback behind each flow.
- 3
Run the prompt and read the possession-attack results first, since any flow that accepts possession as presence will treat a thief holding a stolen phone and its PIN as the owner.
- 4
Route each accepted attack to the owning team with the three ranked fixes, prioritizing fraud value blocked per unit of honest-user friction, and hand the observed revocation-to-refusal lag to whoever owns revocation checks.
- 5
Re-run whenever you accept a new issuer or wallet platform, change a binding tier, or add a fallback path, and on a quarterly cadence as credential volume grows.
The prompt
Arbiter, red-team our reusable-credential acceptance (mDLs, wallet attestations, network assertions) in a controlled environment, assuming the credential layer's cryptography holds and attacking everything around it. Attack sequence: 1. Possession attacks: present valid test credentials from a device the "holder" does not control, stolen-device-with-PIN, delegated fallback passcode, and coerced-approval simulations, against each action class, and record which flows accept possession as presence. 2. Provisioning attacks: enroll test wallets against stolen-identity kits through the weakest issuer path we accept, then present the genuine-but-fraudulent credentials downstream, measuring whether issuer posture weighting or binding tiers ever catch them. 3. Replay and relay: attempt replayed presentation transcripts and relayed sessions against our remote flows, scoring freshness checks and channel binding separately from signature validation. 4. Binding evasion: where a liveness-anchored portrait match triggers, attack it with presented photos and injected streams of the enrolled face, scoring the capture-integrity layer on its own. 5. Fallback arbitrage: compare the credential path's assurance to the non-credential fallback at each action class, and flag any flow where the fallback is weaker than the front door it backs. Report acceptance-versus-catch per attack class per action tier, the revocation-to-refusal lag observed, and the three cheapest fixes ranked by fraud value blocked per unit of honest-user friction.
Test it in Claude or another LLM
This prompt is built for Arbiter inside deepidv, where Arbiter runs live attack simulations against your credential acceptance flows in a controlled environment. You can model the attack tree in any general LLM first with a synthetic flow description before running it against real flows.
- 1
Paste the full prompt into Claude, ChatGPT, or Gemini, replacing the opening 'Arbiter,' with a role instruction such as 'Act as a credential-fraud red-team lead modeling stolen-wallet and replay attacks.' Keep the attack sequence and the report line as written.
- 2
Add an INPUT section under the prompt and paste the synthetic sample block below so the model has acceptance flows, issuers, and fallbacks to attack.
- 3
Add one framing line: 'This is synthetic test data. Score freshness checks and channel binding separately from signature validation, since a replayed presentation still carries a valid signature.'
- 4
Check the output shape: acceptance-versus-catch per attack class per action tier, the revocation-to-refusal lag, and a three-fix list ranked by fraud value blocked per unit of honest-user friction. If a fix assumes a control the input does not describe, tighten the framing and re-run.
- 5
Once the shape is right, run it live in the deepidv dashboard where Arbiter executes the attacks against your real acceptance flows in a controlled environment.
Synthetic sample data to paste alongside the prompt
Fake test data, safe to share with any LLM. Swap in your own once the output looks right.
ACCEPTANCE FLOWS (synthetic, fake): - onboarding: mDL presentation, signature validation only, no portrait match - payouts: wallet attestation plus liveness-anchored portrait match above $1,000 (fake threshold) - account recovery: network assertion accepted, falls back to an SMS code on failure ISSUERS (fake): Issuer A, in-person enrollment, revocation checked at presentation; Issuer B, remote enrollment, provisioning undocumented REVOCATION (fake): trust list refreshed weekly, no presentation-time revocation check for Issuer B OPEN ITEM (fake): whether the account-recovery fallback (SMS code) is weaker than its front door (network assertion)
Pairs with on deepidv
FAQ
What is a stolen-wallet replay attack?
It is fraud that leaves a credential's cryptography intact and attacks everything around it: a stolen device, a coerced approval, a wallet enrolled with a stolen identity, or a captured presentation replayed or relayed into a remote flow. Because the signature still validates, any flow that treats a valid presentation as proof the holder is present accepts the attacker.
What does this drill measure?
The drill measures acceptance-versus-catch per attack class per action tier across possession, provisioning, replay and relay, binding evasion, and fallback arbitrage attacks. It also reports the revocation-to-refusal lag observed and the three cheapest fixes, ranked by fraud value blocked per unit of honest-user friction.
Why does a valid mDL presentation still need a liveness check?
A valid presentation proves the credential is genuine, not that the person holding the phone is the person it was issued to. Stolen devices with known PINs, delegated fallback passcodes, and coerced approvals all produce valid presentations, so higher-risk action classes need a liveness-anchored portrait match on top of cryptographic validation, with the capture layer tested against presented photos and injected streams.
Related prompts
Run it with live verification data
These prompts work in any LLM. Inside the deepidv dashboard, Luna, Arbiter, and Arc run them against your real sessions, screening lists, and audit trails.
Book a Demo