Zach Herbert got into Bitcoin in 2013, dropped out of Harvard Business School four years later, and eventually landed on a single obsession: building hardware that makes sensitive approvals depend on explicit human authorization. That was the logic of a Bitcoin wallet. You see the transaction, approve it on trusted hardware, and only then does it get signed. When AI agents started running actions at machine speed, he recognized the shape of the problem immediately: the same authorization gap, only wider.
Herbert co-founded Foundation in 2020. For a while, it was a Bitcoin company. Then it became something harder to categorize. Passport Prime, the flagship device, runs KeyOS, a Rust-based operating system Foundation spent three years building. It is kept deliberately small, with apps walled off from each other and every action filtered through the kernel. Nobody drew it up as an AI containment system. That framing came later, when Herbert started asking various AI models to describe what a secure OS would look like if they were designing it themselves. The answers were uncomfortably familiar.
In this interview, he explains why that matters, what it will take to fix an authorization problem he argues mainstream tech has not yet taken seriously enough, and whether human control over AI is still actually achievable.
The Control Problem
1. Foundation describes its work as applying Bitcoin-grade cryptographic discipline to AI agent authorization. Before anything else, what does that mean in plain terms when an AI agent tries to act on someone’s behalf?
Bitcoin taught a very simple lesson: software can prepare an action, but the final approval should happen somewhere the compromised machine cannot rewrite. In Bitcoin, that action is an irreversible transaction. With AI agents, it might be a bank transfer, a GitHub deploy, a cloud change, a file deletion, or access to a sensitive account.
So when we say Bitcoin-grade cryptographic discipline for AI authorization, we mean the agent should not just say, “trust me, the user approved this.” The action should be specific, human-readable, verified on independent hardware, and cryptographically authorized by the person holding the device. Software proposes; hardware authorizes.
2. Most AI tools today show a permission prompt before taking an action. The argument, however, is that once a user hands over credentials, those prompts are largely cosmetic. Why is software-level enforcement not enough, and what does trusted hardware actually change?
A software prompt is only as strong as the environment around it. If the agent has the browser session, OAuth token, API key, shell, MCP tool, or network path, then the prompt is often just a convention. It may be useful UX, but it is not a real security boundary if the same software environment already has the capability to act.
Trusted hardware changes the trust boundary. The credential or signing authority can live outside the agent runtime, and the action can be displayed on a trusted screen before approval. That gives you two things software alone cannot give you: a place to verify the real action, and cryptographic proof that a human with the physical device approved that specific action.
3. Not every AI action carries the same risk. Sending a million-dollar wire transfer is different from paying a recurring vendor invoice. Where should the line be, and how does hardware enforcement help draw it?
The line should be based on consequence, not just category. Low-risk actions can run automatically under policy. Medium-risk actions can be constrained, logged, rate-limited, or routed through a policy check. High-risk actions should require explicit hardware approval: money movement, credential access, production changes, deletion, legal commitments, identity changes, or anything irreversible.
Hardware helps because the line is not just a UI setting inside the agent. The policy can be enforced in the capability path itself. If an action requires human approval, the agent does not get the credential, signature, or release until the hardware approves it. That is the difference between “the agent agreed to ask” and “the agent physically cannot proceed.”
4. Can Foundation walk through a specific scenario where Passport Prime steps in as the authorization layer for an AI agent handling something sensitive?
A near-term example is an AI agent that needs to use credentials or tools for a sensitive workflow. This is not a mainstream shipping workflow today, so I would not describe it as something customers can use in production yet. But internally we already have apps where Passport Prime can store MCP credentials, act as an MCP server/router/toolbox, and route Claude or GPT API calls through Passport so actions can be evaluated against policy.
The point is that Passport Prime is not just a passive approval screen. The hardware and KeyOS can hold credentials, mediate tool access, evaluate requests, and require the human to release authority for specific actions. That demonstrates the model: the agent can prepare the work, but Passport controls whether the relevant capability is actually released.
Why the Existing Stack Cannot Be Fixed
5. The operating systems most people use today, Mac, Windows, Linux, were built long before AI agents existed. What does it mean, practically, that those systems cannot tell the difference between a human user and an AI agent taking over the keyboard?
Practically, it means the OS sees one user session. If a human clicks a button, if an agent uses browser automation, if a script calls an API, or if malware reuses a token, a normal OS often sees the same logged-in user with the same permissions. It was built to authenticate the session, not to prove human authority over each action.
That distinction now matters more than ever. Agents are no longer just answering questions. They are using computers: browsers, shells, filesystems, cloud APIs, GitHub, Slack, email, finance tools. If the OS cannot distinguish who or what is acting inside the session, then the final authority cannot live inside that same session.
6. Given that, where does the trust boundary actually belong in an AI workflow? Inside the app, inside the operating system, or somewhere else entirely?
For low-risk tasks, the app and OS can handle a lot. But for high-stakes authority, the trust boundary should sit outside the agent runtime, outside the browser session, and outside the general-purpose OS. Otherwise the agent, the compromised app, or the compromised machine is effectively policing itself.
Our view is that authority belongs in dedicated hardware and a purpose-built OS. The agent gets intent. The workflow gets capabilities. Passport holds the human authority. That separation is the important part.
7. Enterprise custody operations, firms holding large amounts of Bitcoin on behalf of others, are reportedly still relying on infrastructure that is decades old. How does the rise of AI-powered exploit tools change the risk picture for those organizations?
I would be careful not to overgeneralize because some custodians have serious security teams and strong controls. But there is a myth that enterprise custody always relies on magical technology far beyond what a prosumer, startup, or smaller institution could access. In many cases, it is still operating systems, HSMs, smart-card architectures, approval workflows, mobile apps, and human process. Those systems can be better managed, but they are not immune.
AI changes the tempo. It does not create magic attacks, but it makes reconnaissance, phishing, exploit chaining, code analysis, and operational abuse faster and cheaper. If your authority model depends on humans noticing every anomaly inside a noisy software environment, that model gets weaker as attackers automate.
Foundation’s Answer: Hardware-Level Control
8. Foundation started building KeyOS in late 2022, well before AI agent security became a topic most people were discussing. Looking back, which parts of that architecture ended up being directly relevant to containing AI, even though that was never the original goal?
The parts that matter most are the same ones we needed for Bitcoin and personal security: a microkernel architecture, app sandboxing, process isolation, protected master keys, a trusted screen, and dedicated hardware outside the phone or laptop. We were not designing around AI agents in late 2022. We were trying to build a secure, open platform for keys, approvals, and sensitive apps.
But that architecture maps almost directly onto the AI problem. If agents are going to touch money, identity, files, accounts, and infrastructure, you need a place to store authority that the agent cannot simply reach into. KeyOS gives us that foundation.
9. At some point, Foundation put a question to several AI models: describe the ideal secure operating system, one that lets you work but keeps you contained. What did they say, and how did it compare to what KeyOS already was?
I asked Claude, GPT, and Gemini a version of this question: if you were designing the ideal system for securing Bitcoin, 2FA, and AI authorization, what architecture would you want? The interesting part was that they all converged on the same basic answer: a microkernel, strong isolation, narrow privileges, and a design where apps cannot freely reach across the system.
Gemini went further and said the ideal system should be airgapped and should not trust Bluetooth. So I asked the follow-up: what would have to be true for Bluetooth to be acceptable? The answer was basically what we had already built with QuantumLink: treat Bluetooth as an untrusted transport, isolate the radio, and run encrypted, authenticated communication above it. I do not frame that as “AI endorsed us.” It was just independent architectural convergence.
10. KeyOS uses app sandboxing, isolated memory, and derived keys to separate what each app can access. How does that model stop an AI agent from reaching something it was never authorized to touch?
The basic idea is that an app should not get global access just because it runs on the device. Each app gets its own sandbox, its own permissions, and its own derived keys. It cannot casually read another app’s data, pull the master secret, or use capabilities it was never granted.
The next important piece is the policy engine. We are improving KeyOS so actions can be evaluated against a policy table at the kernel level, not just inside an app’s own logic. That matters for agents because one permission should not become every permission. If an agent is authorized to prepare an invoice, that should not imply access to Bitcoin keys, 2FA secrets, encrypted files, or production credentials.
11. Foundation draws a comparison between approving a Bitcoin transaction on hardware and how AI authorization should work. How close is that analogy in practice, and where does it break down?
It is very close at the principle level. In Bitcoin, the untrusted computer prepares a transaction, the hardware device shows you the real details, and the key signs only after human approval. AI authorization should work the same way for high-risk actions: the agent prepares the action, trusted hardware displays what will happen, and approval releases a specific capability.
Where it breaks down is that AI actions are broader and messier than Bitcoin transactions. A Bitcoin transaction has a relatively clear output, amount, and fee. An AI action might be a sequence: read files, call an API, send a message, modify code, move money. So the challenge is making the approval context specific enough to be meaningful without forcing the user to approve every tiny step.
12. Passport Prime’s developer mode includes support for MCP servers, which allows an AI agent to interact directly with the device during testing. What does that actually enable, and what does the hardware prevent the agent from doing?
This is specifically a KeyOS developer mode for people building native KeyOS apps. When explicitly enabled in developer settings on the device, an agent can get deep access for development and testing, including the ability to see the screen and interact with the device over MCP. That can make app development much faster because the agent can actually exercise the app on real hardware instead of relying on a disconnected mockup.
It is not meant for mainstream use. The whole point is that this level of access has to be intentionally enabled on-device by a developer. In normal user flows, MCP should not mean an agent gets raw keys, global secrets, or silent authority. The hardware can expose controlled interfaces while keeping the trust boundary intact.
13. Foundation is building a way to store credentials and API keys for AI tools directly on Passport Prime, so agents have to authenticate through the physical device. What category of attack does that address that a purely software solution leaves open?
It addresses the ambient credential problem. Today, once an API key, OAuth token, cookie, or session credential is available to the agent environment, a compromised agent or tool can often use it directly. A prompt injection does not need to “convince” the user if it can simply call the credentialed tool.
Putting the credential behind hardware changes that. The agent can request access, but the device can enforce policy, require approval, rate-limit use, and bind the release to a specific action. The credential is no longer just sitting in a software environment waiting to be copied, exfiltrated, or abused.
Beyond Bitcoin: The Bigger Picture
14. Once an AI tool has a user’s credentials, it often has access to email, files, communications, financial accounts, and more. Is Foundation’s longer-term goal to become a hardware authorization layer across all of those integrations, or is the current focus more narrow?
The long-term goal is broader, but the way we get there is not by Foundation building every integration ourselves. Bitcoin is where we started because it is the clearest version of final authority: irreversible money, adversarial environment, no undo button. But the same principle applies to accounts, identity, files, communications, code, cloud infrastructure, and AI actions.
The main point is the SDK and open app store. We want developers to build native KeyOS apps and authority workflows for the tools people already use. Foundation provides the secure hardware, OS, app model, and approval architecture; the ecosystem can build the long tail of integrations.
15. What would an enterprise deployment of Foundation’s model actually look like? One device per employee, shared approval hardware, a policy layer sitting above existing tools? What is the realistic path here?
The realistic path is policy plus hardware, not one rigid deployment model. Some users need a personal device because the authority is personal: signing, identity, privileged access, executive approvals. Some workflows may use shared or role-based approval devices. Enterprises will also need a policy layer above existing tools so approvals, audit logs, revocation, recovery, and device assignment fit into how they already operate.
Foundation will also offer fleet management tools for remote device management. I would start with the highest-risk actions: treasury, custody, production infrastructure, admin credentials, and sensitive data access. Do not ask the enterprise to rewrite everything. Put hardware-rooted approval in the path of the actions that can hurt the company, then expand from there.
16. Everything Foundation ships is open source, hardware and software both. In an AI security context, why does the ability to inspect what is actually running on a device matter more than it used to?
When a device becomes the authority layer for AI, “trust us” is not good enough. The device may be approving money movement, credential use, code deploys, account access, or agent policy. Users and enterprises need to be able to inspect the hardware design, the OS, and the app model so they can verify what the device is actually doing.
Open source also matters because AI security is going to move quickly. Developers need to build new authority apps, researchers need to audit the model, and users need a path if a vendor disappears or changes direction. A closed black box is a weak foundation for human authority.
Using AI to Build Against AI
17. Foundation uses AI heavily in its own product development. Where has it made the most difference to how the team works, and where is it still not reliable enough to trust?
AI has made the biggest difference in how we explore and implement. I think of our role as executives and leaders, especially Ken (our CTO) and me, as architects. We spend an enormous amount of time iterating on architecture, often with the help of AI, and then use the tools to help implement, test, review, and move faster.
Where I do not trust it is final authority. It cannot be the thing that decides whether a security model is correct, whether a cryptographic boundary is sound, or whether a high-risk action should happen. AI is very useful as a tool for a small team. It is not a root of trust.
18. Passport Prime ships with post-quantum encrypted Bluetooth, called QuantumLink. Is there a direct connection between that capability and the AI authorization work Foundation is doing, or are those separate tracks for now?
There is a direct architectural connection, even if the first user-facing use cases are broader than AI. QuantumLink exists because we do not want to trust Bluetooth. The Bluetooth chip is treated as an untrusted transport; the sensitive communication is encrypted and authenticated above it, and the radio does not become part of the trust boundary.
We are also launching a server-based model where any app or service can initiate a new, unique QuantumLink connection with Passport Prime, then send messages over a relay path: our server to the mobile app to Passport hardware. That makes it much easier to send data to and from Passport for review and approval, without turning the relay network or Bluetooth link into the authority itself.
What Human Control Actually Requires
19. Foundation’s stated mission is keeping humans in control of their digital lives. As AI agents become more capable and more embedded in daily decisions, what does genuine human control actually require? Not in theory. In practice.
In practice, human control requires separation. The tool doing the work should not also hold final authority over the work. If an agent can access the credential, approve the action, and execute the action inside the same environment, then the human is mostly supervising after the fact.
Real control means the human can see the action, understand the consequence, approve or deny it on independent hardware, and revoke authority when something goes wrong. It also means the system should not ask for approval on everything. It needs policy: automate the safe things, constrain the medium-risk things, and escalate the actions that actually matter.
20. For developers building AI agents today, what is the one thing they are most likely getting wrong about authorization, identity, or keeping humans in the loop?
They are treating human-in-the-loop as a UX pattern instead of a security boundary. A chat prompt that says “approve?” is not the same thing as authorization if the agent already has the token, browser session, or API capability needed to act.
The question developers should ask is: could the agent still do this if the human said no? If the answer is yes, then the human was not actually in control. You need to remove ambient authority, bind permissions to specific actions, and put the final approval somewhere the agent cannot rewrite.
