3초 승인 장치, 에이전트 권한을 손에 쥐려는 하드웨어

AI 요약

• 무슨 일: Foundation이 640만 달러 투자와 함께 Passport Prime 일반 판매, KeyOS 개발자 플랫폼 확대를 발표했습니다.
  • 보도자료는 AI 에이전트가 돈, 코드, 계정, 데이터에 접근할 때 최종 승인을 전용 하드웨어에서 처리해야 한다는 문제의식을 전면에 둡니다.
• 개발자 포인트: KeyOS SDK, simulator, CLI tooling, USB-connected MCP server가 묶여 AI coding agent가 실제 장치 앱을 만들고 테스트하는 경로를 엽니다.
• 주의점: 아직은 작은 보안 하드웨어 생태계의 초기 베타입니다. 핵심 질문은 채택 규모보다 "최종 승인권을 어디에 둘 것인가"입니다.

Foundation이 2026년 5월 22일 Passport Prime 일반 판매와 KeyOS 개발자 플랫폼 확대를 발표했습니다. 발표만 놓고 보면 Bitcoin 하드웨어 지갑 회사의 제품 출시처럼 보입니다. 하지만 이번 보도자료의 언어는 꽤 다릅니다. Foundation은 Passport Prime을 "Human Authority Hardware"라고 부릅니다. 사람이 들고 있는 전용 장치가 AI 에이전트의 고위험 행동을 마지막으로 승인해야 한다는 주장입니다.

이 표현이 중요한 이유가 있습니다. AI 에이전트 보안 논의는 보통 세 가지 층에서 머뭅니다. 첫째, 모델이 프롬프트 인젝션에 속지 않는가. 둘째, 도구 권한을 얼마나 좁힐 수 있는가. 셋째, 실행 로그와 정책 엔진으로 사후 감사를 할 수 있는가. Foundation의 발표는 여기에 네 번째 층을 붙입니다. 돈이 움직이고, 코드가 배포되고, credential이 쓰이고, 민감 데이터가 열리기 직전의 최종 승인권은 같은 컴퓨터 위의 팝업이 아니라 별도의 신뢰 장치에 있어야 한다는 것입니다.

이것은 아직 검증된 표준이 아닙니다. 하지만 AI 개발자에게는 지나치기 아까운 신호입니다. 에이전트가 실제 업무 시스템에 연결될수록 "승인 UI"는 부가 기능이 아니라 실행 인프라가 됩니다. Foundation의 Passport Prime은 그 승인 UI를 브라우저, IDE, 모바일 알림에서 떼어내 하드웨어로 옮기려는 시도입니다.

발표의 겉모습은 하드웨어, 속은 승인 레이어

Foundation의 공식 발표에 따르면 이번 라운드는 Fulgur Ventures가 주도했고 Arche Capital이 참여했습니다. 투자금은 640만 달러, 누적 투자금은 1,650만 달러입니다. Passport Prime은 2026년 3월 pre-order 고객에게 배송을 시작했고, 이번 발표로 일반 구매자에게 열렸습니다. 가격은 공식 발표 기준 349달러입니다.

제품 기능만 보면 Passport Prime은 여러 보안 장치를 하나로 합친 물건입니다. Bitcoin 하드웨어 지갑, FIDO security key, 2FA 코드 저장소, secrets vault, 50GB encrypted file storage가 들어갑니다. Foundation 제품 페이지는 이를 "digital authority"를 전용 하드웨어로 옮기는 장치라고 설명합니다. 휴대폰은 편의성을 위해 만들어졌고, Bitcoin 키와 계정, 개인 파일, 중요한 승인을 맡기기에는 부족하다는 논리입니다.

여기까지는 보안 하드웨어 시장의 익숙한 메시지처럼 들립니다. 그런데 보도자료의 핵심 문장은 AI 에이전트 쪽으로 방향을 틉니다. Foundation은 문제가 더 이상 key storage만이 아니라고 말합니다. AI 에이전트는 계정, 지갑, 클라우드 인프라, 엔터프라이즈 시스템에서 기계 속도로 행동할 수 있습니다. 그래서 브라우저 prompt, phone notification, 또는 에이전트와 같은 컴퓨터에서 돌아가는 policy engine이 최종 권한자가 되기 어렵다는 것입니다.

이 지점에서 Passport Prime은 하드웨어 지갑을 넘어섭니다. 지갑은 서명 장치입니다. Passport Prime이 겨냥하는 것은 승인 장치입니다. 서명은 그중 하나일 뿐이고, 대상은 money movement, code deploy, credential use, sensitive data access까지 넓어집니다.

왜 에이전트 승인 문제가 별도 장치를 요구하나

AI 에이전트 보안의 어려움은 모델이 똑똑해질수록 단순해지지 않습니다. 오히려 반대입니다. 모델이 실제 업무를 더 잘 처리할수록 더 많은 도구를 연결하고, 더 긴 세션을 유지하고, 더 넓은 컨텍스트를 읽고, 더 큰 변경을 제안합니다. 그 결과 "승인"이라는 단어가 여러 의미로 갈라집니다.

첫 번째 승인은 계획 승인입니다. 에이전트가 어떤 일을 하겠다고 설명하고, 사용자가 진행을 허락합니다. 두 번째 승인은 도구 승인입니다. 파일을 읽거나, 네트워크에 접속하거나, 명령을 실행할 때 한 번 더 허락을 받습니다. 세 번째 승인은 결과 승인입니다. PR을 만들거나, 배포를 누르거나, 결제를 보내거나, customer record를 수정하는 단계입니다. 지금 대부분의 에이전트 제품은 이 세 단계를 같은 화면 위에서 처리합니다.

이 방식은 개발 중에는 편합니다. 하지만 에이전트가 공격받는 상황에서는 취약합니다. prompt injection이 에이전트의 계획을 오염시킬 수 있고, compromised browser extension이 승인 화면을 조작할 수 있으며, 사용자가 보는 UI와 실제 실행 payload가 달라질 수도 있습니다. 클라우드 정책 엔진은 조직 통제에는 강하지만, 사용자가 지금 무엇을 승인하는지 직접 확인하는 trusted display 역할은 하지 못합니다.

Foundation의 논리는 여기에 걸려 있습니다. 같은 컴퓨터가 에이전트를 실행하고, 같은 브라우저가 입력을 받고, 같은 OS가 승인 창을 띄운다면, 그 환경 전체가 흔들릴 때 사용자의 최종 판단도 흔들립니다. 그래서 별도 화면, 별도 OS, 별도 secure element, 별도 통신 경로를 가진 장치가 필요하다는 주장입니다.

물론 이것이 모든 에이전트 workflow에 맞는 답은 아닙니다. 블로그 초안을 쓰거나 테스트 파일을 고치는 작업에 매번 하드웨어 확인을 요구하면 생산성이 떨어집니다. 하지만 실제 돈, 인증, 배포, 데이터 반출이 걸린 순간에는 이야기가 달라집니다. "사람이 승인했다"는 말을 나중에 감사 로그로 남기려면 사람이 본 내용과 실행된 내용 사이의 신뢰 경로가 필요합니다.

KeyOS가 개발자 플랫폼인 이유

Foundation이 이번 발표에서 KeyOS를 강하게 밀어붙인 것도 이 맥락에서 봐야 합니다. Foundation의 개발자 페이지는 Passport Prime을 Rust 기반 secure, offline-first app platform으로 설명합니다. KeyOS는 Rust microkernel, sandboxed runtime, curated UI library, simulator, CLI tooling, real device capabilities를 제공합니다. SDK는 public beta입니다.

개발자는 KeyOS 위에서 full Rust app crate를 만들 수 있습니다. 앱은 자기 UI, storage, declared permissions를 가집니다. 장치 기능으로는 touchscreen, camera, NFC, USB-C, secure storage, secure element, QuantumLink Bluetooth가 언급됩니다. Foundation은 Bitcoin signing뿐 아니라 identity and access control, SSH and FIDO2 keys, credential managers, encrypted messaging, password managers, internal approval apps 같은 사용 사례를 제시합니다.

중요한 것은 KeyOS가 "스킨"이 아니라는 점입니다. 개발자 페이지는 KeyOS apps가 기존 앱의 skin이 아니라 full Rust binary라고 설명합니다. 앱은 sandbox 안에서 실행되고, secrets는 일반 phone, laptop, browser 바깥에 남습니다. 즉 Foundation은 Passport Prime을 단일 목적 hardware wallet이 아니라 보안 앱 배포 플랫폼으로 만들려 합니다.

이 전략은 위험도 큽니다. 하드웨어 지갑 회사가 앱 플랫폼을 열면 공격 표면도 늘어납니다. 그래서 OS, sandbox, app review, permission model, firmware signing, supply chain 검증이 모두 중요해집니다. Foundation은 KeyOS를 open source와 inspectable security model로 포장하지만, 실제 생태계가 커질수록 더 어려운 질문이 뒤따릅니다. 악성 앱을 어떻게 걸러낼 것인가. 앱 권한 설명을 사용자가 이해할 수 있는가. AI 에이전트가 만든 앱을 누가 검토할 것인가. update와 rollback은 어떤 신뢰 체인을 따를 것인가.

바로 이 어려움 때문에 KeyOS는 흥미롭습니다. 에이전트 시대에는 "앱을 만드는 개발자"와 "앱을 실행하는 장치" 사이에 AI coding agent가 들어옵니다. 개발자가 직접 모든 코드를 쓰지 않고, 에이전트가 scaffold를 만들고, UI를 고치고, 테스트를 돌립니다. 그러면 보안 플랫폼은 사람 개발자만을 상정한 SDK가 아니라 에이전트가 다룰 수 있는 SDK가 되어야 합니다.

MCP 서버가 들어간 지점

이번 발표에서 가장 AI 개발자다운 문장은 USB-connected MCP server입니다. Foundation은 KeyOS developer platform에 documentation, simulator, CLI tooling과 함께 USB로 연결된 MCP server가 포함된다고 설명합니다. 이 MCP server는 AI coding agents가 실제 Passport Prime 하드웨어에서 앱을 build하고, screenshots를 찍고, test할 수 있게 한다는 설명입니다.

이 부분은 작지만 방향성이 큽니다. MCP는 많은 경우 SaaS API, 파일 시스템, 데이터베이스, 브라우저 자동화 같은 소프트웨어 도구 연결에 쓰입니다. Foundation의 접근은 물리 장치를 agent tool surface로 올리는 쪽입니다. 에이전트가 "이 KeyOS 앱 화면이 승인 문구를 제대로 보여주는가", "권한 요청이 의도한 대로 뜨는가", "실제 장치에서 렌더링이 깨지지 않는가"를 확인하려면 simulator만으로는 부족할 수 있습니다. 실제 하드웨어에서 screenshot과 test를 뽑아야 합니다.

이것은 모바일 앱 개발에서 device farm이 했던 역할과 닮았습니다. 차이는 대상이 보안 승인 장치라는 점입니다. 에이전트가 실수로 승인 문구를 모호하게 쓰거나, 금액/대상/권한 범위를 잘못 표시하면 그 앱은 그냥 UX가 나쁜 것이 아니라 보안상 위험합니다. 따라서 AI coding agent가 보안 하드웨어 앱을 만들 때는 "코드가 컴파일된다"보다 "사용자가 무엇을 승인하는지 안전하게 볼 수 있다"가 더 중요한 테스트 조건이 됩니다.

FIDO key와 HSM 사이의 빈 공간

Foundation이 노리는 틈새는 기존 보안 도구 사이에 있습니다. FIDO security key는 인증에 강합니다. 사용자가 특정 서비스에 로그인할 때 phishing-resistant authentication을 제공합니다. 하지만 일반적으로 사용자가 지금 어떤 고위험 business action을 승인하는지 풍부하게 표시하는 trusted display는 아닙니다. 하드웨어 지갑은 crypto transaction signing에 강하지만, 모든 엔터프라이즈 workflow를 담는 앱 플랫폼은 아닙니다. HSM은 강력하지만 서버 랙과 중앙 시스템 쪽에 있고, 개별 사용자가 손에 들고 "내가 이 작업을 승인한다"고 확인하는 장치는 아닙니다.

Passport Prime은 이 세 영역을 섞으려 합니다. FIDO security key와 2FA 저장소를 포함하고, Bitcoin wallet과 secure storage를 갖고, KeyOS 앱을 통해 identity, signing, credential, internal approval workflow로 확장하겠다는 구상입니다. Foundation은 이를 사람-facing trust layer라고 표현합니다. 에이전트가 software side에서 행동하고, 사람은 hardware side에서 승인하는 구조입니다.

이 구상이 설득력을 얻으려면 세 가지가 필요합니다. 첫째, payload 표현이 명확해야 합니다. "배포 승인"이라고만 뜨면 안 됩니다. 어떤 repo, 어떤 commit, 어떤 환경, 어떤 권한 변화인지 사람이 이해할 수 있게 보여줘야 합니다. 둘째, developer SDK가 이 표현을 안전하게 강제해야 합니다. 앱 개발자가 중요한 필드를 숨기거나 흐리게 만들 수 있다면 trusted display의 의미가 약해집니다. 셋째, agent toolchain과 연결되어야 합니다. 개발자가 AI agent로 앱을 만들더라도 승인 UI와 permission model이 검증 가능해야 합니다.

Foundation 발표에서 MCP server가 들어간 이유도 여기서 설명됩니다. AI coding agent가 KeyOS 앱을 만들 수 있다면, 그 에이전트는 장치 화면을 보고 테스트할 수 있어야 합니다. 단순히 codegen을 허용하는 것이 아니라, 실제 승인 UX를 검증하는 피드백 루프를 만들어야 합니다.

커뮤니티 신호는 작지만 방향은 선명하다

이번 발표가 대형 AI 커뮤니티를 흔든 사건은 아닙니다. Hacker News의 큰 토론은 확인하지 못했고, Reddit 반응도 Foundation 사용자 커뮤니티 중심입니다. r/FoundationDevices의 발표 공유 글은 Passport Prime 일반 판매, KeyOS developer platform, Rust SDK, simulator, CLI tooling, AI coding agents를 위한 MCP server를 요약하는 수준입니다. 같은 커뮤니티에는 KeyOS SDK로 password manager POC 앱을 만들었다는 글도 있습니다.

따라서 이 뉴스를 "시장이 이미 하드웨어 승인으로 이동한다"라고 읽으면 과장입니다. 지금은 훨씬 작은 신호입니다. 보안 하드웨어 회사가 AI 에이전트 시대를 자기 제품 범주의 확장 근거로 삼기 시작했고, SDK와 MCP를 통해 AI coding agent가 장치 앱을 만드는 흐름까지 고려했다는 점이 핵심입니다.

실무적으로는 두 부류가 먼저 관심을 가질 수 있습니다. 하나는 crypto와 identity 쪽 개발자입니다. 이들은 이미 hardware signing, seed phrase, secure element, FIDO 같은 개념에 익숙합니다. 다른 하나는 enterprise AI governance 팀입니다. 에이전트가 cloud infra, secrets, deployment pipeline에 접근하는 순간, "승인"을 화면상의 버튼으로만 남겨도 되는지 고민하게 됩니다.

반대로 일반 SaaS 개발팀이 당장 Passport Prime을 도입할 가능성은 높지 않습니다. 하드웨어 배포는 무겁습니다. 분실, 교체, onboarding, accessibility, remote work, app update, support가 모두 따라옵니다. 특히 AI agent approval은 너무 자주 묻기 시작하면 사용자가 기계적으로 눌러버립니다. 하드웨어 승인도 fatigue 문제에서 자유롭지 않습니다.

개발자가 봐야 할 실제 질문

이 뉴스에서 개발자가 바로 가져갈 질문은 "Passport Prime을 사야 하는가"가 아닙니다. 더 중요한 질문은 에이전트 workflow에서 어떤 행동을 하드 승인 대상으로 분류할지입니다.

예를 들어 로컬 repo에서 test를 실행하는 것은 낮은 위험일 수 있습니다. staging branch에 PR을 만드는 것도 조직에 따라 낮거나 중간 위험입니다. 그러나 production deploy, access token 발급, customer database export, payment release, privileged IAM policy 변경, incident response 자동 조치처럼 되돌리기 어렵거나 피해 범위가 큰 행동은 다른 승인 경로가 필요합니다. 이 경로가 브라우저 confirm이면 충분한가, 모바일 push면 충분한가, 아니면 별도 hardware root가 필요한가를 판단해야 합니다.

두 번째 질문은 승인 payload의 표준화입니다. AI 에이전트가 어떤 일을 하려는지 사람에게 설명하는 문구는 모델이 자유롭게 생성하면 안 됩니다. 금액, 대상, 권한, 실행 환경, diff, 만료 시간, 감사 ID 같은 핵심 필드는 구조화되어야 합니다. 사람이 보는 요약은 자연어일 수 있지만, 장치가 검증하는 payload는 machine-readable해야 합니다. 이 층에서 MCP, signed requests, policy-as-code, OPA, workload identity 같은 기존 기술과 하드웨어 승인 장치가 만날 수 있습니다.

세 번째 질문은 테스트입니다. 승인 UI는 일반 UI보다 테스트 기준이 더 까다롭습니다. 버튼이 보이는지보다 중요한 것은 사용자가 위험을 잘못 이해하지 않도록 만드는 것입니다. AI coding agent가 이런 UI를 만들 때는 screenshot diff, accessibility label, field completeness, localization, truncation, spoofing resistance를 함께 테스트해야 합니다. Foundation의 MCP server 언급은 이 테스트 루프를 AI agent와 실제 장치 사이에 놓겠다는 힌트로 읽을 수 있습니다.

하드웨어가 답이라는 보장은 없다

비판적으로 볼 지점도 많습니다. 첫째, 하드웨어 장치는 강한 신뢰 경계이지만 운영 비용이 큽니다. 모든 직원에게 장치를 나눠주고, 고장과 분실을 처리하고, 긴급 상황에서 fallback을 제공해야 합니다. 둘째, 사용자가 작은 화면에서 복잡한 agent action을 이해할 수 있는지는 별개의 문제입니다. 복잡한 Kubernetes 배포나 IAM 변경을 몇 줄 요약으로 안전하게 승인할 수 있을까요. 셋째, 앱 생태계가 열릴수록 보안 검토 부담이 커집니다. KeyOS가 sandbox를 제공해도 app store, developer signing, dependency supply chain은 계속 문제로 남습니다.

넷째, 에이전트 승인의 일부는 하드웨어가 아니라 조직 정책 문제입니다. 어떤 에이전트가 어떤 고객 데이터에 접근할 수 있는지, 어떤 변경은 두 명 이상의 승인자가 필요한지, 업무 시간 밖에는 어떤 action을 막을지, incident 상황에서는 어떤 예외를 허용할지 같은 규칙은 장치 하나로 해결되지 않습니다. Passport Prime 같은 장치는 최종 사용자 승인 지점을 강화할 수 있지만, 전체 governance layer를 대체하지는 않습니다.

그래도 Foundation의 발표가 의미 있는 이유는 문제 정의가 정확하기 때문입니다. 에이전트가 더 많은 일을 할수록 "사람이 승인했다"는 말의 기술적 의미가 중요해집니다. 지금까지는 승인 버튼이 곧 승인이라는 암묵적 전제가 있었습니다. 에이전트 시대에는 그 전제가 약합니다. 승인 버튼이 뜬 환경과 에이전트가 실행되는 환경이 같다면, 공격자는 둘을 함께 노릴 수 있습니다.

에이전트 시대의 승인 UX는 제품 표면이 된다

AI 개발자 도구 경쟁은 빠르게 runtime 경쟁으로 옮겨가고 있습니다. 모델은 코드를 쓰고, agent runtime은 sandbox와 tool permissions를 제공하고, MCP는 외부 시스템을 연결하고, observability 도구는 실행 로그를 남깁니다. 여기에 아직 덜 정리된 층이 있습니다. 사람이 언제, 무엇을, 어떤 증거를 보고 승인하는가입니다.

Foundation의 Passport Prime은 이 층을 전용 하드웨어로 잡아당깁니다. 성공 여부는 알 수 없습니다. 하지만 방향은 분명합니다. AI 에이전트가 단순히 추천을 만드는 단계에서는 이런 장치가 과해 보입니다. 에이전트가 실제 계정과 시스템을 움직이는 단계에서는 승인 경계가 제품의 핵심 표면이 됩니다.

앞으로 봐야 할 지표는 네 가지입니다. 첫째, KeyOS SDK가 실제로 어떤 앱 예제를 공개하고, AI agent approval flow를 어떻게 모델링하는가. 둘째, USB-connected MCP server가 simulator 수준을 넘어 실제 장치 테스트를 얼마나 안정적으로 제공하는가. 셋째, KeyOS app store가 권한, signing, review, update 정책을 어떻게 운영하는가. 넷째, Foundation이 crypto 커뮤니티를 넘어 enterprise identity, developer tooling, agent governance 파트너를 확보할 수 있는가.

이번 발표는 큰 AI 모델 출시가 아닙니다. 새로운 coding agent도 아닙니다. 오히려 그 반대편에 있는 뉴스입니다. 에이전트가 행동하는 시대에 사람이 어디에서 멈춤 버튼을 쥘 것인가. Foundation은 그 답을 손 안의 전용 하드웨어라고 말합니다. 이 답이 주류가 될지는 아직 모릅니다. 다만 AI 에이전트의 다음 병목이 모델 성능이 아니라 승인권의 위치일 수 있다는 점은, 이번 작은 하드웨어 발표가 던지는 꽤 큰 질문입니다.

출처

• Foundation: Passport Prime 보도자료
• Foundation: KeyOS 개발자 페이지
• Foundation: Passport Prime 제품 페이지
• Reddit r/FoundationDevices: 발표 공유 글