Heima (@heimaNetwork): Introducing AgentKeys (Part 2) — Why we treat the agent as the adversary

Introducing AgentKeys (Part 2) — Why we treat the agent as the adversary Two weeks ago we introduced AgentKeys: closed alpha, the second product on the Heima stack, the first one where users never touch crypto. Part 1 walked through what the product is and who it is for. This is Part 2, and it is for the community: the people who have been with Heima long enough to want to know not just what we shipped, but how we think. For two years, one idea has shaped every security decision we have made. It’s the idea that defines AgentKeys, and it’s older than the product itself. The agent is not your friend. Not your employee either. The agent is a process running on the operator’s machine, with the operator’s permissions, taking input from outside the operator’s trust boundary. That is the fundamental structure of the system, regardless of whether the agent is helpful, malicious, or exploited. Every load-bearing security choice in AgentKeys starts here. The rule, plainly AgentKeys is designed around one rule: Treat the agent as a potential adversary to the human operator. Not “build security in.” Not “harden the agent.” Treat the agent as adversarial from the first line of code, then let every design decision follow from that premise. The result is a system where compromise stays contained. Any single component can fail without handing an attacker total control. There is no single point whose compromise collapses the entire security model. That is the only kind of safety guarantee worth having when the threat model assumes the agent is exploitable. Why the agent is the threat model, not a footnote A modern coding agent reads documentation, scrapes web pages, parses model output, talks to other agents, then issues commands with the operator’s credentials. Stated plainly: it is a process that takes input from the internet and acts on the operator’s behalf, with the operator’s authority, on the operator’s machine. We have seen this shape before. The browser had it 25 years ago. We eventually learned how to deal with it, but not by trusting the browser. We learned by assuming the browser would eventually be exploited and bounding what it could do when that happened. The agent is the browser of 2026. Prompt injection is a real, ongoing class of vulnerability. Tool misuse, scope creep, model jailbreaks, and indirect attacks through tainted context — these all collapse to the same underlying problem. A process running with the operator’s credentials, taking adversarial input, producing actions the operator did not authorize. The agent is not malicious. The agent is exploitable. An exploited agent and a malicious one produce the same security problem. The security community has been warning about this class of risk in LLM agents for the last 18 months. What we did differently was take it seriously before writing any code. What changes when you design for the adversarial agent The adversarial-agent frame leads to four core design properties. They sound abstract, but each one maps directly to how the system is built and operated. 1. The agent never holds the master keys. The long-lived secrets, the ones that would be catastrophic to leak, live inside hardware the agent process cannot reach. The agent can request signatures, but the key itself never crosses the boundary. A compromised agent can leak the short-lived permission it was explicitly granted. It cannot leak what it never had. 2. The agent gets permission slips, not full access. When the agent needs to call an external service, it does not get an API key with broad permissions. Instead, it gets a narrowly scoped permission slip tied to a specific operation and expiring within minutes. Once it expires, the agent must request a new one, and the system rechecks whether the operator still permits that scope. If permissions were revoked, the next request fails. Revocation propagates in seconds, not minutes. The agent still makes its own calls, but with permission so narrow and so short-lived that compromise cannot accumulate. 3. Agents are sealed off from each other. If the operator runs ten agents and one gets compromised, the compromise stays contained to that one agent, the other nine continue unaffected. The compromised agent cannot impersonate its siblings, request permissions it was never granted, or reach the operator’s master credentials. The isolation is enforced outside the agent’s control. 4. The agent cannot rewrite history. Every credential mint, read, revocation, and scope change is recorded independently of the agent. The agent has no write access to the audit log. The operator can verify what actually happened without relying on the agent’s account of events. A compromised agent cannot deny its actions because the record exists outside the agent’s control. Across all four properties, the same principle holds: compromise stays bounded. Not by good intentions, careful operators, or fast detection, but because the agent simply cannot perform actions it was never explicitly authorized to perform. And the same posture applies across the rest of the system. The agent is the most visible component — the one closest to user-facing input — so we name it first. But the same skepticism applies everywhere: every component is treated as potentially compromised, and every component operates within a bounded blast radius. Two weeks of progress: the position keeps sharpening Part 1 introduced the first version of how AgentKeys stores encrypted credentials. Strong as it already was, adversarial-agent framing has a habit of producing harder questions every time you answer one. The question we kept coming back to after Part 1 shipped was simple: What happens if the encryption key leaks ten years from now, not today? A blockchain is public, immutable, and permanent. Once encrypted data is published on-chain, every copy of the chain retains it indefinitely. Even if the data remains encrypted, it still exists in every archive, every block explorer, and every backup. If the encryption key ever escapes the secure hardware protecting it — years later, through any future vulnerability — that encrypted data becomes readable retroactively. That is not an attack the system faces today. It is an attack that becomes possible the moment a single key leaks, no matter when or how it happens. The team’s answer was simple: change where the data lives. The new design has three parts: The credentials themselves move off-chain, into storage we control directly and protect behind the same per-user permission boundaries enforced across the rest of the system. The blockchain still stores the structural facts — who owns what, who granted what, who revoked what, and a tamper-evident trail for every encrypted file. If a stored file is altered later, the on-chain trail detects the mismatch on read. The encryption keys rotate on a fixed schedule, old keys are destroyed during rotation, and encrypted files associated with those keys are deleted alongside them. This means even total compromise of the encryption infrastructure can therefore only expose at most a single rotation window of data. The future window stays bounded. The historical window no longer exists. This is what adversarial-agent design produces in practice: not a fixed security position, but a process of continuously re-evaluating the threat model and tightening the system around it. The team kept asking harder questions, and the answers kept improving the design. For the community, nothing changes about how AgentKeys feels to use. Credentials still store with one command, agents still read them from their own configs, revocation still propagates in seconds. What changes is the long-term guarantee underneath. Part 1 already promised that your credentials are safe today, the new design extends that guarantee across the multi-decade horizon where the threats that matter most may be the ones we cannot yet predict. Shipping this quickly is part of the point. The infrastructure evolves alongside the threat model, not behind it. We intend to keep moving the same way through every milestone ahead. Why this matters in 2026 The agent ecosystem is no longer theoretical. Developers already run ten coding agents simultaneously on the same machine, production fleets manage thousands. Each agent holds credentials for GitHub, OpenAI, OpenRouter, Anthropic, Slack, AWS, and the operator’s own internal services. The shape of the threat model has changed, even if the credential model underneath it has not. Most agent tooling still relies on environment-variable secrets. Same pattern as 2015, the agent receives the raw key, the key carries broad permissions, no per-agent scoping, no instant revocation, no audit trail. At ten agents, this is inconvenient. At a hundred, it becomes a real security problem. At the scale the industry is moving toward, it becomes a recurring incident class. Adversarial-agent design is not the conservative position, it is the position that takes the agent boom seriously. The truly conservative position is the one most systems still take today: trust the agent, hand it the key, and hope nothing goes wrong. Five years from now, that security posture will look outdated. AgentKeys is built for the world after that shift. Where we are The current build is live. Closed alpha continues at agentkeys.heima.network. The next milestones will continue hardening the security model and later this quarter, introduce a chain-native version of AgentKeys for the Heima community that wants direct access to the underlying chain primitives. Public alpha will open as those land. Heima remains what it has always been: a team building the trustless identity, credential, and audit stack that other products, including ours, ship on top of. AgentKeys is what those ideas look like when applied to a real user workflow. What this means For the community that has watched Heima build since the rebrand, this is the design philosophy behind AgentKeys — and the same posture underlying everything we have shipped. Bounded blast radius at every layer. The chain stores only what genuinely requires consensus. The hardware holds the keys. The team keeps asking harder questions and answering them with code. For everyone discovering Heima through AgentKeys, this is what coherence in infrastructure design looks like. The product is the visible layer, the design philosophy underneath is what allows it to hold up at scale. The agent is not malicious. The agent is exploitable. Every line of AgentKeys comes from designing for that reality. — The Heima team