Handing an autonomous agent a master private key is not delegation — it’s abdication. A wallet built for agent use has to replace that all-or-nothing access with something scoped, bounded, and revocable, without losing the self-custody properties the wallet exists to provide.
A human using a wallet makes a series of deliberate, individually authorized decisions: sign this transaction, approve this connection, confirm this transfer. That model assumes a person is present and attentive for each action. It breaks down immediately when the entity initiating transactions is an autonomous agent completing a multi-step task without a human reviewing each individual step — which is exactly the pattern agent-driven activity requires.
The naive solution, and why it fails
The simplest way to let an agent act is to give it the wallet’s private key directly. The agent can then sign anything it needs to sign, whenever it needs to. This works in the narrow sense that it lets the agent function, and it is also a serious security failure waiting to happen: a master private key handed to software is not a bounded grant of authority, it’s unconditional access to everything that key controls. If the agent is compromised, misconfigured, or simply does something its owner didn’t anticipate, there is no layer between that failure and the full contents of the wallet.
Scoped, revocable authorization
The alternative is treating agent access as something that can be defined narrowly rather than granted wholesale. Thanos Wallet’s approach is built around session credentials: structured authorizations that specify what an agent or application is permitted to do, not a blanket grant of wallet access. A credential can carry a maximum spend limit, a defined set of approved assets, a list of approved contracts, approved networks, an expiration date, and a revocation path. An agent operating under that credential can act within those bounds. It cannot act outside them, because the authorization simply doesn’t extend that far — not because the agent chooses to respect a limit, but because the wallet enforces the scope at the credential level.
This changes what granting agent access actually means for a user. Instead of an irreversible decision to hand over full control, it becomes a bounded decision: this agent, this spend limit, these contracts, this expiration, revocable at any point. The user remains in control not by reviewing every individual transaction, but by defining the boundaries within which autonomous activity is allowed to happen in the first place.
The same logic validators already apply to their own keys
This principle isn’t unique to agent wallets — it’s the same reasoning behind how Lithosphere’s validator architecture handles its own credentials. A validator operating on the network doesn’t rely on one key for everything either. Operational consensus keys, identity keys, network communication keys, governance credentials, and recovery credentials are kept separate, so that compromising one doesn’t cascade into control over the others. Scoped, separated authorization at the wallet level and scoped, separated authorization at the validator level are the same security principle applied at two different points in the stack: don’t let one credential carry more authority than the specific task in front of it actually requires.
This matters practically for Genesis validators as well. An operator running infrastructure under the Genesis Validator Program — self-staking LITHO in the 10,000 to 25,000 range, managing Foundation-delegated stake on top of that — is itself an entity that benefits from the same scoped-access model Thanos Wallet applies to agents. A validator’s operational team needs to manage staking and delegation activity without every team member or every piece of automation requiring unrestricted access to the full stake. The underlying problem, bounding what a given credential is allowed to touch, shows up for human-run validator operations in a parallel form to how it shows up for autonomous agents.
Self-custody doesn’t change for agent use
What doesn’t change, regardless of whether the wallet is being used by a person, an agent, or a validator’s operational team, is where the keys live. Thanos Wallet’s underlying self-custody model — locally generated and stored key material, AES-encrypted local storage, no third party holding a copy of anything — applies the same way whether the signing request originates from a human tapping a confirmation button or an agent operating under a scoped session credential. Agent-friendly authorization is a layer built on top of self-custody, not a departure from it.
Multi-chain access matters here too, for a reason specific to agents rather than human convenience: an agent completing a task across multiple networks needs a single wallet capable of operating across all of them, under one consistent credential and permission model, rather than juggling separate wallets with separate authorization schemes for each chain it touches.
Why this is a practical requirement, not a feature request
None of this is about making wallets more interesting for software to use. It’s about the fact that agent-driven activity is already happening, and the wallets handling it are mostly built around an interaction model — one human, one deliberate action per signature — that doesn’t fit how agents actually operate. A wallet that can only offer all-or-nothing key access is not a safe option for agent use, regardless of how convenient that access might be to implement. Scoped, time-limited, revocable authorization is not a nice-to-have on top of agent wallet support. It’s the same discipline the network already applies to its own validator credentials, and it’s the minimum requirement for agent wallet support to be something a user can responsibly grant at all.
