Bringing Verified Device Identity to Agents with Smallstep
Today, we’re excited to announce a strategic partnership with Smallstep to bring hardware-attested device and workload identity to Keycard.
Last week, we introduced Keycard for Coding Agents to control what agents do at execution time. But there’s a missing piece: knowing where those agents are actually running. Keycard’s keycard run entrypoint delivers ACME-based, device-attested identity directly into policy decisions, ensuring access is only granted when agents are running in environments your organization trusts, evaluated on every tool call.
When an agent requests access, it could be running on a trusted laptop, a CI job, a production system, or an attacker’s machine using credentials the agent itself exposed. Most identity systems authenticate at the moment credentials are issued, but they don’t account for where those credentials are actually used.
Why this problem exists
Anyone can leak secrets and credentials, and that’s not new. GitGuardian reported over 29 million leaked secrets on GitHub in 2025 alone. What’s changed is the proliferation of agents and how they operate. They use tools, read from file systems, and explore every path to complete a task, pulling in whatever data they can find without bias or concern, including credentials.
A typical event is straightforward: An agent is given a credential, or discovers one on disk, brings it into its context, and later sends it out through a tool call. From there, it can be captured and replayed from an untrusted environment. From the system’s perspective, nothing looks wrong. The credential is valid.
What’s missing is context. Where is this request coming from? Who is actually using the credential? Most identity systems don’t know. They authenticate the user or issue a credential, but they don’t evaluate the runtime using it. Once a credential exists, it can be replayed from anywhere.
Devices and runtimes aren’t trustworthy by default. If a credential leaks and is used from an unknown machine, your system has no way to tell whether it’s an attacker, a mistake, or legitimate use.
That’s the tension with agents. Give them more autonomy and they become more useful, but the risk grows with it. Lock things down and you reduce that risk, but you also limit what they can do. Without better controls, you’re stuck trading off utility for security.
Runtime Verification, Enforced Per Tool Call
The missing piece is the runtime. The problem isn’t just that credentials leak, it’s that once they do, you have no idea where they’re being used from as everything still looks valid, even if it’s coming from the wrong place.
ACME-based device and workload attestation fixes that by turning the runtime into something you can actually verify instead of assume. A developer laptop, a CI runner, or a production service gets a hardware-backed identity that proves what it is at the moment it starts.
That identity comes from a key that’s generated and stored in hardware, like a Secure Enclave or TPM, and never leaves the device. When the device or workload starts, it uses that key to obtain a short-lived certificate via ACME. That certificate is tied to the device and its state, and it can’t be copied or reused somewhere else because the private key never leaves the hardware.
For services built with Keycard or that support proof of possession strategies, every request contains both attested device identity and the access tokens required to perform tool calls upstream.
Keycard is building on these trust primitives. When an agent is executed with keycard run, the runtime becomes part of the identity. It’s no longer just the user and the agent, it’s the user, the agent, the task, and the environment it’s running in, and that context carries through every decision. Instead of issuing a credential and hoping it’s used correctly, Keycard issues short-lived, task-scoped access only after the runtime is verified, and does it per action, not once up front.
From there, every request is tied back to that same environment. The agent doesn’t just present a token, it proves it’s still running on the same device by signing each request with that hardware-backed key.
That’s what stops replay. If a credential leaks, it can’t be used somewhere else because the attacker doesn’t have the device or the key needed to prove it. At the same time, Keycard is enforcing what the agent is allowed to do, scoped to the task and checked on every tool call, so access only happens when both are true: the environment is trusted, and the action is allowed.
Early Access
The Keycard and Smallstep integration is being developed and integrated alongside select partners.
If you’re building agents that need to operate across real infrastructure — CI runners, developer machines, production services — and you want runtime identity to be part of the trust model, not an afterthought, we’d love to work with you.
