Keys Have Lives
Research Competition
The Missing Maintenance Layer in Agent Security
A private key is what proves you authorised something. As software agents begin to hold value and act on their own, the industry has concentrated on securing the instant of authorisation: the agent proposes a transaction, a human or a preset policy approves it, and a hardware secure element performs the signature so the key itself never reaches the agent. This paper accepts that this design is correct and argues that it is incomplete.
A key is not an event. It is created, delegated, used, rotated, exposed, revoked and eventually abandoned. Mapping those seven stages against published specifications and roadmaps, this paper finds that three are addressed and four are not. No published mechanism defines how an agent’s key is rotated once other systems depend on it, how authority delegated to a sub-agent is withdrawn, or what happens to a key belonging to an agent that no longer runs. The relevant standards each solve a neighbouring problem: ERC-8004 registers agent identity as a transferable token separable from any signing key, NIST CSWP 39 addresses algorithm agility rather than key lifecycle, and the object-capability literature has formalised delegation, attenuation and revocation since the 1970s without any of it being assembled into tooling an agent developer can use.
Drawing on my own development practice as a case study, the paper argues that agents inherit a developer’s key habits rather than a careful consumer’s, and multiply them. It identifies the point at which a key most commonly escapes in practice, which is before any signature occurs, and sets out the questions a maintenance layer would have to answer. It closes with the only mechanism I observed to change my own behaviour: not security guidance, but a bill.
1. Introduction: Security at Human Speed
When I first started leaving private keys in files I could see, the risk I imagined was a person. Someone would glance at my screen, or open a repository, and try to remember what they saw. That threat model felt reasonable, and it shaped how carefully I behaved.
The threat that actually arrived was automated. Exposed testnet keys were found and drained by scanning bots, in my experience within about a week of the commit that exposed them. No human ever read the key. Nobody needed to remember anything. My security instincts had been calibrated against a human adversary, in an environment where the adversary is a program that never gets bored.
That mismatch is the subject of this paper, one layer up. Software agents now generate keys, hold keys, and act on them at a rate no person reviews. The industry’s response has been to secure the moment those keys are used. Ledger’s position states it clearly: agents propose, humans sign, hardware enforces [4, 5].
This paper accepts that position and asks a question it does not answer. What happens to those keys after the signature?
2. Methodology
This is a document-analysis position paper. It makes no experimental claims and reports no new cryptanalysis.
Sources are primary and fall into three classes: vendor engineering publications and roadmaps, standards documents and their reference implementations, and academic literature. They were selected where they either define a primitive relevant to key handling or state a design position on agent authority. Commentary and secondary reporting were excluded. Where a claim concerns what an architecture does or does not address, it rests on published specification or roadmap text, cited directly.
Two limitations govern everything that follows. First, this analysis works from published material rather than internal access. Where a primitive is absent from public specifications and roadmaps, that absence is evidence of a public gap. It does not establish that no such work exists internally at any organisation named here.
Second, Section 4 draws on my own development practice as a primary source. This is one practitioner’s account, offered as an existence proof of a pattern rather than as a survey. Its evidential weight lies in being specific and verifiable in kind, not in being representative.
3. The Snapshot Architecture, and What It Gets Right
The case for the current architecture starts from a distinction that is easy to miss. Identity is not security. Knowing which agent is acting tells you nothing about whether the action was wanted. An agent can be owned by one party and controlled by another, through a compromised dependency, a poisoned input, or an instruction its operator never issued. Any design treating verified identity as sufficient authorisation has already lost.
The response is to stop trying to secure the agent and to secure the act instead. Payment cards are the working analogy. The industry did not solve card fraud by making numbers harder to obtain. It accepted that numbers leak and moved verification to the moment of the transaction. Ledger’s stack applies the same move to agents [4, 5]. A model may be probabilistic, may be manipulated, and may reason its way somewhere nobody intended, but the decision to move value passes through a deterministic layer that the model cannot argue with.
This also disposes of a tempting alternative. One might try to audit the agent’s own account of its reasoning, but recent work on chain-of-thought faithfulness finds that a model’s stated reasoning does not reliably reflect the computation that produced its output [8]. A self-report carries no evidential weight. What the act did is the evidence.
The roadmap’s primitives follow from this. Agent Identity, Intents, Policies and Proof of Human [4] each answer a question asked at the moment of the act: who is acting, what specifically was authorised, within what bounds, and whether a human principal stands behind it.
The same reasoning already governs Ledger’s existing products, which is worth noting because it shows the principle is load-bearing rather than aspirational. A secure screen driven directly by the secure element renders the transaction independently of the machine that composed it, so malware that alters what a computer displays cannot alter what the device shows [13]. Clear signing extends this by requiring a readable statement of intent and human-readable transaction fields, standardised as ERC-7730 and parsed generically since 2025 [12, 13]. Where no such description exists, the device falls back to displaying a raw hash and warns the user, and this blind-signing mode is disabled by default [13]. The architecture is careful and internally consistent.
One concession matters more than the rest, and this paper grants it fully. The design does not force a trade between autonomy and safety. The agent keeps all of its speed. Only the decision to act moves into the deterministic layer, and the key never enters the agent’s reach. On its own terms the architecture is correct. What follows does not dispute it. It asks what it does not cover.
4. Keys Have Lives
4.1 What key management actually looks like
Look at my machine and practically every project directory holds a .env file with a raw private key in plaintext. When I started out I did not know these were meant to be hidden, which is a consequence of how I learnt to program: by building things that worked, from documentation that showed the key going into the file and stopped there. Later, when I began using coding agents, it did not occur to me that I would need to instruct the agent to hide them either. So it didn’t.
I have sent keys over email and over direct messages. I have never rotated a key on a schedule unless something critical forced it, and I did not rotate one even after exposing it publicly. The honest thought in my head was na just me see am na — Nigerian Pidgin for it is only me who saw it. And even if somebody did see it, I reasoned, no one memorises sixty-four hexadecimal characters in the few seconds it is on screen.
The only keys I retire are my Anthropic API keys, and only because Anthropic gives me a button that disables them. Everything else goes stale. When I need a key for a new project I do not go back and clean up the old one. I generate a new one.
That is beginning to change, though not for any reason a security guide would recognise. It is changing because I started paying for these services, and stale keys cost money.
This is not a story about carelessness. It is what key management looks like for a working developer when nothing in the toolchain asks for anything else.
4.2 Two key realities
What Section 4.1 describes is not an aberration. It is one of two distinct patterns of key ownership, and almost all published security guidance addresses the other one.
In the consumer pattern, a person holds a single seed phrase. It is generated once, backed up on paper or metal, kept inside a hardware enclave, and never rotated across its entire life. Sharing it is the cardinal sin. Retirement happens only when the wallet itself is migrated. The pattern has one key, one owner, one device, and a human physically present to approve each signature. Every part of the hardware security model is built for this person, and for this person it works extremely well.
In the developer pattern, the same individual holds dozens of keys. At least one per project, often more, spread across local testnets, staging environments and deployment pipelines. They live in plaintext configuration files because that is what the tooling reads. They travel over email and direct messages because that is how a teammate gets one. They are rotated in reaction to an incident, if at all, and they are almost never retired, because generating a fresh key costs nothing while auditing an old one costs attention.
I live in the second column. So does every developer I know, and the number of us is growing quickly for a reason worth naming. This wave of developers is shipping without fundamentals. Agents let a person build something that works before they have learned why it is dangerous, and the small forgiving mistakes that used to teach key hygiene never happen.
The consequence for this paper is straightforward. An autonomous agent does not inherit the consumer pattern. It inherits mine, along with the plaintext files, the reactive rotation and the keys nobody retires, and it does so at a rate and volume no person supervises.
4.3 The lifecycle of a key
4.4 Coverage
Mapping the roadmap’s primitives [4] against the stages in 4.3 leaves four of seven stages without a published mechanism. Rotation, compromise, revocation and retirement have no primitive at any point on the 2026 roadmap, including its unshipped quarters. Delegation is partially addressed: policies bound what a single agent may do, but nothing specifies how authority passes from one agent to another.
4.5 The counterargument: the primitives already exist
The obvious objection is that none of this is missing, only scattered.
Object-capability systems addressed delegation, attenuation and revocation decades ago. Redell’s Caretaker Pattern dates to 1974, KeyKOS to 1985 and EROS to 1999, with the model formalised in Miller’s 2006 thesis, which covers selective revocation, attenuating authority and membranes [2].
NIST CSWP 39 [3] addresses crypto-agility, meaning the decoupling of application logic from underlying algorithms. It is not a key lifecycle management framework, and this paper does not claim it is.
ERC-8004 [1] defines Identity, Reputation and Validation registries for agents. An agent’s identity is a transferable ERC-721 token whose tokenURI points to an agent card. The specification remains in Draft status. It contains no rotation, revocation or expiry primitive, and the identity token is separable from any signing key the agent uses.
The objection is right on the facts and wrong on the conclusion. The gap is not one of invention but of assembly. Fifty years of capability research, a crypto-agility framework and an on-chain identity standard have not been packaged into anything an agent developer can import today.
5. Why Agents Make the Gap Structural
5.1 The key enters the context window
The stated principle is that the agent never touches the key. The workflow I actually run breaks that principle before the agent does anything at all. I generate a keypair in the terminal, and then I paste the private key straight into the coding assistant, whether that is Claude or Cursor, because the assistant is writing the deployment script and needs to see the configuration it is writing.
Consider precisely where that key now exists. It is in the assistant’s context window, which means it was transmitted to a remote inference endpoint. It is in that session’s stored history, retrievable by anyone who opens the conversation later. It is in my terminal scrollback and my shell history file. It is in the configuration file the assistant just wrote, which is one careless commit from a public repository. And it is in the memory of any process that loads it.
Not one of these locations is reached by a signing-time control, because no signature has been requested. Agent Identity does not apply, since no agent has acted; Policies do not apply, since no transaction exists to bound; Proof of Human does not apply, since nobody is being asked to approve anything. The architecture begins at the moment of the act, and the key has already been copied into five places before that moment arrives.
This describes my own routine practice rather than a hypothetical failure. The principle that the agent never touches the key is sound. The workflow surrounding the principle hands the key over anyway.
5.2 Keys created outside any provisioning event
In some builds, agents have generated wallets and key material themselves through platform SDKs and agent skills. Where that happens, no human initiated the creation, nothing recorded it, and no inventory contains it.
5.3 Delegation with no defined grant or withdrawal
One agent engages another, and the second needs authority to act. Published material specifies what an agent may do. It does not specify how a portion of that authority passes onward, or how it is taken back.
5.4 Volume
Agent-to-agent interaction and per-call micro-transaction economics [9] push action counts past any rate a person can meaningfully review. Every action moved under a standing policy to preserve throughput is an action no human saw.
5.5 The compromise question I could not answer
Several agents I have deployed can still sign transactions today. Asked what I would do if one of them were compromised right now, my honest answer was that I would ask another agent how to proceed.
That answer is worth examining rather than excusing. I know how to generate a key, how to fund an account and how to deploy an agent that uses both. I do not know how to withdraw a key from circulation, and I have never been shown. There is no documented procedure, no tooling that performs it, and no checklist in any of the material this paper cites. The gap in my knowledge maps exactly onto the gap in the published architecture, which suggests the problem is not that developers fail to learn the procedure. It is that the procedure has not been written.
Correct for the Instant, Silent About the Years
Grant the position first, and mean it. Hardware-anchored trust, a human in the loop, and deterministic enforcement at the moment of the act [6] are right, and right for reasons this paper has already accepted. What follows is offered from inside that value system.
6.1 The hard questions are longitudinal
Self-custody’s guarantees are instantaneous. This key, this signature, this moment, this device. The questions that determine whether a fleet of agents is safe are questions about time: which keys exist, what inherited authority from what, and what still signs on behalf of something that no longer runs. An architecture that answers only instantaneous questions is not wrong. It is incomplete in a direction that worsens as agent count grows.
6.2 The model assumes device ownership
A hardware signer costs more than I would pay. My own threshold is somewhere around ten to twenty dollars, and only for something I clearly need. I am a student developer in Lagos running agents that touch real value, which makes me the kind of user a serious threat model should cover and the kind of user who will not own the device. Where the security boundary is a purchase, everyone below the price line inherits the software-only threat model by default. This is an observation about who the architecture reaches, not a complaint about pricing.
6.3 The recommended mitigation multiplies keys
Ledger’s published guidance on blind signing offers a set of practical precautions, and the most substantial of them is asset segregation: never interact with smart contracts using the wallet holding your long-term assets, but dedicate a separate burner wallet for dApp interactions and move only the funds a given transaction requires [13].
As advice this is sound, and I follow it myself. As a lifecycle instruction it is worth reading carefully, because what it recommends is the creation of additional keys. It says nothing about what becomes of a burner afterwards. There is no stated expiry, no sweep, no retirement step and no suggested interval at which a user should review how many burners they have accumulated. A cautious user following this guidance for two years holds a collection of funded, live, forgotten keys, each created deliberately and none ever closed.
This is the same accumulation Section 4.1 describes in my own development practice, arriving through a different door. Developers accumulate keys because tooling never asks them to clean up. Users accumulate them because the safety guidance asks them to create more and stops there. Neither is a failure of care. Both are what happens when an architecture defines creation and use precisely and leaves retirement undefined.
6.4 The population is moving in the wrong direction
The current wave of developers is shipping without fundamentals, building quickly with agents and never acquiring the security instincts an earlier generation picked up slowly through smaller, more forgiving mistakes. Guidance written for readers who already know to rotate their keys reaches a shrinking share of the people holding them.
6. What a Maintenance Layer Would Have to Answer
This paper proposes no protocol. It sets out the questions any serious attempt would need to resolve.
- Who revokes a compromised sub-agent key, and how does that revocation propagate through a delegation chain?
- What expires by default, and on what clock?
- How does rotation survive an on-chain identity binding when identity is a transferable token?
- What records a key’s provenance when no human initiated its creation?
- What attaches a cost to a key’s continued existence? This is the only mechanism I have observed to actually produce maintenance behaviour.
7. Limits and Conclusion
The strongest objection to everything above is that it changes nothing. A maintenance layer only matters if somebody adopts it, and developers already ignore practices they know to be correct. I am the evidence for that: I understood why keys should be rotated for years before I rotated one. Naming a gap does not close it.
The objection is correct, and the answer to it is the most useful thing in this paper. Nothing about security ever produced maintenance behaviour in my own practice. A bill did. The moment stale API keys began costing money every month, I started retiring them, and I did it without discipline, without a reminder and without thinking of it as security work at all. Consequence achieved in weeks what a decade of good advice had not.
That points at a design constraint rather than a design. Whatever a key maintenance layer turns out to be, it will not work by asking developers to be more careful, because careful is not a state anyone sustains across dozens of keys and hundreds of agent actions. It will work by attaching a consequence to a key’s continued existence, so that the default outcome of neglect is expiry rather than accumulation. Every question in Section 6 is ultimately a question about where that consequence lives.
Three limits are worth stating plainly. A critique built on published roadmaps may describe a documentation gap rather than an engineering one; internal work may exist that this paper cannot see. One practitioner’s account is an existence proof rather than a survey, and the pattern may be less widespread than I believe. And the object-capability literature may already resolve more of this than a reading at the level of assembly suggests.
Within those limits the finding stands. The industry has built careful, well-reasoned machinery for the instant a key is used, and almost nothing for the years on either side of that instant. Agents do not create this gap. They make it impossible to keep ignoring, because they generate keys faster than people can remember having made them.
- ERC-8004: Trustless Agents (Draft). eips.ethereum.org/EIPS/eip-8004
- Miller, M. S. (2006). Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. Johns Hopkins University. erights.org/talks/thesis/markm-thesis.pdf
- NIST CSWP 39: Considerations for Achieving Crypto Agility. National Institute of Standards and Technology. csrc.nist.gov/pubs/cswp/39/…crypto-agility/final
- Ledger. 2026 AI Security Roadmap. ledger.com/blog-2026-ai-security-roadmap
- Rogers, I. Don’t Give the Agent the Keys. Ledger Agent Stack. x.com/iancr/status/2074525268778049991
- Gauthier, P. Revenge of the Atoms. Ledger. ledger.com/blog-revenge-atoms
- Ledger Donjon. Security research publications. donjon.ledger.com
- Arcuschin, I., Janiak, J., Krzyzanowski, R., Rajamanoharan, S., Nanda, N. and Conmy, A. Chain-of-Thought Reasoning In The Wild Is Not Always Faithful. arxiv.org/abs/2503.08679
- Rothschild, D. M., Mobius, M., Hofman, J. M., Dillon, E. W., Goldstein, D. G., Immorlica, N., Jaffe, S., Lucier, B., Slivkins, A. and Vogel, M. The Agentic Economy. arXiv:2505.15799, May 2025. arxiv.org/abs/2505.15799
- Ledger Agent Intents. agentintents.io and github.com/brackets-fistful-ayen/ledger-agent-intents
- Ledger Device Interaction documentation. developers.ledger.com/docs/device-interaction/getting-started
- ERC-7730: Clear Signing Metadata registry. github.com/LedgerHQ/clear-signing-erc7730-registry
- Ledger. “What Is Clear Signing?” The Ledger Newsletter, 16 February 2026. linkedin.com/pulse/what-clear-signing-ledgerhq-5mjic
- Rogers, I. Security in the AI Agent Era. Ledger. ledger.com/blog-security-in-the-ai-agent-era
The research and argument in this paper are my own. Sources are cited throughout. AI tools were used in the course of the work; the analysis, the claims and the conclusions are mine, and I am able to defend them.
Demilade Ayeku · September 2026
