Every paid DimeBox call authenticated by a wallet needs exactly one credential: the wallet_secret, presented as Authorization: Bearer <wallet_secret>. It's shown once, at creation, and never again - not in a dashboard, not via a reset link, not on request. That's a deliberate design choice, and it's worth understanding why, especially if you're used to services that let you regenerate or recover a lost API key.
A wallet_secret is a bearer credential: whoever presents it can spend the wallet's balance, full stop. There's no username paired with it, no additional factor, no scoping to a subset of routes - the same secret that drafts an email can also send one, claim a custom inbox name, or pay for priority receive. That's what makes it powerful and what makes losing control of it expensive.
A secret that's always retrievable from a dashboard has to be stored somewhere in a form that can be shown back to you - which means it's stored in a form that could also leak in a breach. DimeBox hashes credentials like this instead of storing them reversibly; see Hashing Secrets Instead of Storing Them for the mechanism. The practical consequence is that there's nothing on DimeBox's side to show you later, even if you ask - not because of an arbitrary policy, but because what's stored isn't the secret itself.
This isn't unique to wallets. An inbox's read_token follows the identical rule: shown once at creation, no recovery flow if it's lost. Read Tokens Explained and Losing Your Inbox Read Token cover that side of it in detail. DimeBox applies one model - a single bearer secret, shown once, hashed at rest - to both the credential that reads an inbox and the credential that spends a wallet, rather than inventing a different trust model for each.
A "reset password" flow implies something to reset to - a known identity you can re-verify and issue a new credential against. A bearer secret with no attached identity doesn't have that anchor by default: there's no email/password pair behind it to confirm before handing out a replacement. That's the same tradeoff x402 vs API Keys covers from the other direction - a model built around no accounts and no persistent identity buys you no-signup convenience, and costs you the recovery flows that identity enables.
If losing a secret with no recovery path is a dealbreaker for how you want to manage billing, linking the wallet to an account gives a human a separate, login-based way to view and manage it, without that login replacing or exposing the agent's secret. Linking a Wallet to an Account Without Giving Up Agent Access covers that distinction - it doesn't solve "the agent's secret leaked," but it does mean you're not solely dependent on a single string for anything other than making paid calls.
Treat a wallet_secret the way you'd treat a private key or a production API key: never commit it, never log it, never put it in a URL or a client-side script. If you're running more than one agent against DimeBox, give each one its own wallet rather than sharing a single secret across agents you'd otherwise want to budget and limit independently - see Setting Daily Spend Limits on an Autonomous Agent's Wallet for why that separation also makes spend limits meaningful per agent instead of blended across all of them.
Because there's no reset flow, the moment to think about a wallet_secret's handling is before it's issued, not after it's lost. Store it the same way you'd store a database credential or a signing key - in a secrets manager or environment variable injected at runtime, never in a repository, a config file checked into version control, or a log line. If your deployment process involves copying the secret between systems by hand, that's a moment worth automating away, since a hand-copied secret is a secret that's been displayed on a screen or pasted into a chat tool at least once more than necessary.
There's no self-service rotation today - the only way to stop a specific wallet_secret from working is for whatever balance and daily limit it has access to to stop being worth anything to misuse, or for DimeBox to intervene on suspected abuse the way it would for any other wallet; see What a Wallet Freeze Means. The practical mitigation is prevention: keep the balance and daily spend limit sized to what you'd be comfortable losing if the secret did leak, rather than assuming a large buffer you could always revoke later.
If a single pipeline needs both a human-facing dashboard view and a running agent, resist reusing one wallet_secret for both by copying it into two places. Create a wallet per distinct purpose instead - one for a production agent, a separate one for local testing - so that a leak or a mistake in one context doesn't require rotating a secret that's also depended on somewhere else entirely unrelated.