A wallet_secret is what an agent presents on every paid call - a bearer credential with no name attached, built so a machine can authenticate without a login flow. That's the right shape for an agent making API calls. It's a worse shape for a human who wants to check a balance, adjust a spend limit, or update a saved card without pasting a secret into a browser session every time. Linking a wallet to an account solves that second problem without touching the first.
An account, tied to an email address, gives a human a login-based way to view and manage a wallet. The wallet_secret keeps doing exactly what it already does - authenticating the agent's calls. Neither one replaces the other. Your agent's integration doesn't change at all when you link a wallet to an account; what changes is that you, separately, now have a way into the wallet's settings that doesn't involve handling the same string your agent uses in production.
A secret embedded in an agent's environment has a blast radius: if that environment leaks it, whoever gets it can spend the wallet, nothing more and nothing less. If the same secret were also the only way to log in and manage billing, that blast radius would extend to billing settings, saved cards, and account-level controls too. Keeping the two separate means a leaked agent credential costs you the wallet's balance (bounded further by whatever daily spend limit you've set - see Setting Daily Spend Limits on an Autonomous Agent's Wallet) and nothing structurally beyond that.
It's worth contrasting this with how DimeBox treats inbox ownership, because the defaults are deliberately different. An inbox is never tied to the wallet that paid to create it - DimeBox doesn't store that link at all, by design; see Why DimeBox Never Stores Which Wallet Paid for an Inbox and Who Owns an Agent's Inbox?. A wallet, by contrast, can opt into exactly that kind of persistent link to a human-identified account, because unlike a disposable inbox, a card-funded wallet needs billing continuity - someone has to be reachable about a declined card or an expiring subscription. The asymmetry isn't an inconsistency; it reflects what each object actually needs to function.
Linking an account doesn't recover a lost wallet_secret - see How Wallet Secrets Work for why there's no reset flow for that credential specifically. An account lets you manage a wallet's settings and funding; it's not a backdoor into reissuing the one credential your agent needs to keep calling the API. If an agent's secret is lost or compromised, an account gives you visibility into what's happening with the wallet, not a way to hand your agent a new secret without creating a new wallet.
A fully autonomous wallet - created, funded, and spent entirely by code with no human checking a dashboard - doesn't need an account link to function; the wallet_secret alone is sufficient for every API call it will ever make. Linking an account is for the human side of the operation, not a requirement DimeBox imposes on the agent. Does an AI Agent Need an Identity? is worth reading alongside this one if you're thinking through how much of "who is responsible for this wallet" needs to be legible to a human versus how much can stay entirely inside the agent's own credentials.
Linking happens at /wallet when you create or manage a wallet, tied to the email address you use for the account. It costs nothing extra and changes nothing about how paid calls authenticate - it's purely an added way in for a human, on top of the bearer-secret path an agent already uses.
Picture a small team running a support agent that drafts and sends replies through a wallet. One person creates the wallet, funds it via Stripe Checkout, and links it to an account under a team email address - that's the login a billing-minded teammate can use later to check balance, raise a spend limit, or update the card, without ever touching the agent's code. The deployed agent itself only ever sees the wallet_secret, injected as an environment variable wherever it runs. If the team later hands the agent off to someone else to maintain, the new maintainer needs the secret to keep the agent calling the API, but doesn't need account access to do that - and whoever manages billing doesn't need to hand over the secret to keep managing it. Two credentials, two audiences, no overlap required.
A solo operator running a single agent against a single wallet with nobody else involved has little reason to link an account at all - the wallet_secret alone covers everything that wallet will ever need to do. Account linking exists for the cases where a human and an agent need different, independently manageable access to the same wallet, not as a mandatory step every wallet has to go through before it can be used.