Latch Now Supports Hardware-Bound Identity

Latch Now Supports Hardware-Bound Identity

Software identity can be stolen and replayed. Hardware identity stays on the device.

Latch is Subzero Labs’ policy enablement platform for AI agents that lets you set scoped limits, permissions, and audit trails for every agent you delegate work to, and enforces them before any action is taken. This means you can hand agents real work without handing over blind trust. As money movement is increasingly running through agents, the rails meant to govern that shift, including ours until today, were only solving half the problem. Scoped policies, spend ceilings, and audit logs handle what an agent is allowed to do, but an agent still has to prove who it is before any of that policy applies. Most solutions today allow that proof to live in software: a key or token sitting in a file somewhere on a server- and anyone who got hold of it, could read, copy, and replay from somewhere else.

Software-Based Security Today

450,000 malicious open-source packages were identified in 2025, and this year a single automated campaign slipped secret-stealing continuous integration (CI) workflows into more than 5,500 repositories in under six hours. KPMG put the non-human-to-human identity ratio at 80+ to 1, with machine identities per enterprise up from ~50k in 2021 to 250k in 2025. A software key can be lifted by an attacker 10,000 miles away who never touches your machine. AI is making these attacks faster, easier, cheaper for malicious actors; they don’t need to be in the room or country to steal a file. A policy enforcement stack is only as strong as the identity standing in front of it. No allowlist can stop a credential that’s already been lifted and replayed.

Hardware-bound identity breaks this model, because proving identity requires the physical, enrolled device which a remote attacker can copy or exploit. Hardware binding kills remote credential theft and replay, and the policy pipeline behind it catches misuse from a compromised-but-enrolled machine.

Welcome to Hardware Bound Identity

Hardware-bound identity is the newest primitive in Latch's policy enablement platform for AI agents. Every device you enroll with Latch now seals a device key inside its own hardware, the Secure Enclave on a Mac or a TPM on a Linux host. Latch never holds a key that could forge an agent's identity, and a stolen token can't be replayed against it. An agent's identity becomes bound to the physical machine it actually runs on, not to a credential that can be copied off it. Every agent signs its requests with that hardware-rooted identity so Latch can check the signature before the call reaches anything downstream.

“Latch never holds a key that could forge an agent's identity”

Google shipped Device Bound Session Credentials in Chrome 146, binding session cookies to TPM/Secure Enclave so stolen cookies fail off-device. While Yubico shipped YubiKey 5.8 with hardware-backed authorization for AI agent workflows. The industry just decided stolen credentials shouldn't work off-device for humans. Agents, which hold broader access and never log out, are left behind. Latch closes that gap.

Latch's core primitives: the scoped token, the policy pipeline (the ordered set of checks every request passes through), the revocable secret, set the foundation for device identity, because binding an agent to a piece of hardware only matters if there's a policy engine underneath checking that identity against something. Most other agent tools stop policing once a credential exists. Now Latch agents never hold one to begin with. They prove themselves with an identity rooted in the machine's own silicon that can't be copied off of it.

Device Enrollment

Enrollment in Hardware-Bound Identity is optional for users of Latch and live today. For Mac and Linux; on Linux hosts identities extend automatically to the VMs and containers running on top of them.

Here’s how it works:

• Mac app: Enroll an Apple Silicon Mac running macOS 13+ using the LatchSetup app. Each connected AI app receives a persistent identity, and you choose which identities may use each Latch.
• Linux CLI: A single static binary with no dependencies derives a device key straight from the host's TPM 2.0, runs on any distro, and enrolls with the same one-time, browser-approved flow as the Mac app.
• VMs and containers: Workloads inherit an identity from the enrolled host automatically, no per-container enrollment.

Built to Scale From a Laptop to a Fleet

• Individual developers can enroll a single Mac, wire up their agent of choice (such as Claude Desktop or Claude Code), and watch the full loop of deny, authorize, and succeed play out in about five minutes.
• Teams running Linux infrastructure can enroll a host once and hand out hardware-bound identities automatically to every VM and container it spins up, tracked in a registry that survives restarts.
• Organizations running fleets of agents get one place to see every hardware-bound identity across every enrolled device, and a one-click way to cut one off the moment something looks wrong, which matters most where agents are already touching underwriting, fraud detection, or reconciliation.

However you enroll, the identity model stays the same end to end. A request from a Mac, a bare-metal Linux box, a container, or a Firecracker VM carries the same signed proof, and it works unchanged everywhere Latch already runs, including the Identity filter, the Devices page, and the Connect snippets.

Revocation works the same way too: pull an identity from the Devices page and every request carrying its agent_id is rejected immediately. The identity remains visible for audit but can no longer be added to an allowlist; re-enrollment provisions a new identity.

An agent can find its way around a broken authentication check, but it cannot drive to the Apple Store and buy a new laptop. That's why hardware-bound identity works: it roots an agent's proof of self in the one thing it can't fake, copy, or go acquire on its own. Delegate the work to your agents, keep the control for yourself, and enroll your first device to get started.

FAQs

1. Does this prove what software is running on the device?
   1. No. Hardware-Bound identity proves the request came from an enrolled physical device; it doesn't attest to the code running on it, which is what the policy pipeline is for.
2. Do I need to have hardware-bound identity enabled on my device in order to use Latch?
   1. No. Existing scoped tokens, spend limits, and audit logs work the same with or without a hardware-bound device enrolled.
3. Do I have to enroll every device individually?
   1. Not on Linux, enroll the host once and every VM or container on it inherits an identity automatically. Mac devices are enrolled individually.
4. Do I need to install anything?
   1. The Latch app for Mac (Apple Silicon) or the Linux CLI, both one-time and browser-approved. No agents or workflows need to change.