Turnkey, AI 에이전트의 자격 증명 접근을 위한 Managed Secrets 출시

Turnkey가 Managed Secrets를 출시해 엔클레이브 기반 지갑 인프라를 애플리케이션과 AI 에이전트가 작동하는 데 필요한 API 키, 비밀번호, 결제 정보, 복구 자료까지 확장했다. 10월 29일 발표로 회사는 개인 키 관리에서 한발 더 나아가, 재사용 가능한 자격 증명을 인프라 곳곳에 흩뜨리지 않고도 소프트웨어가 권한을 받아 작업을 수행하게 하는 더 폭넓은 문제를 다루게 됐다.

이 제품을 이용하면 팀은 어떤 서비스가 자격 증명을 가져올 수 있는지, 그리고 요청에 사람의 승인이나 다자간 승인이 필요한지 결정할 수 있다. 금융 애플리케이션의 경우, 거래를 실행하도록 승인된 백엔드에 거래소 API 키를 제공하면서도 AI 어시스턴트의 대화와 실행 환경에서는 해당 키를 분리해 둘 수 있다.

엔클레이브 경계 안으로 옮기는 자격 증명 접근

환경 변수나 설정 파일에 저장된 자격 증명은 소프트웨어가 편리하게 사용할 수 있지만, 이를 읽는 프로세스가 침해되면 내용이 노출될 수 있다. 비밀 정보 저장소를 이용하면 저장과 접근 제어를 한곳으로 모을 수 있지만, 자격 증명을 읽을 수 있는 상태가 되는 지점과 그 순간 신뢰해야 하는 시스템이 무엇인지는 여전히 고려해야 한다.

Managed Secrets는 Turnkey의 보안 엔클레이브 안에서 권한 확인을 수행한다. 클라이언트는 비밀 정보를 가져오기 전에 암호화하고, 엔클레이브는 이를 다시 암호화해 저장한다. 요청이 들어오면 엔클레이브는 관련 정책과 승인 여부를 확인한 뒤, 결과를 지정된 수신자의 키로 암호화한다. 요청자와 수신자는 서로 다른 서비스일 수 있다.

이러한 분리는 중요하다. 애플리케이션은 작업을 시작하고 승인을 수집하면서도, 작업을 완료하는 데 쓰이는 자격 증명을 복호화할 권한은 얻지 않을 수 있다. 승인자의 서명은 정보 공개를 허가할 뿐, 공개된 비밀 정보에 대한 접근 권한까지 자동으로 부여하지는 않는다.

가져오기와 내보내기에 적용되는 암호화 기술

Turnkey의 보안 채널 문서는 하이브리드 공개 키 암호화(HPKE)를 기반으로 하는 프로토콜을 설명한다. 이 방식은 공개 키 기반 키 합의와 인증 암호화를 결합해 민감한 정보가 중간 시스템을 거칠 때 암호문 상태로 전달되도록 한다. 가져오는 과정에서는 클라이언트가 엔클레이브 서명 키 자료를 확인하고, 내보낼 때는 서명된 요청에 포함된 공개 키로 암호화한다.

수신자 키는 한 번만 사용하도록 설계됐다. Turnkey는 이 규칙을 클라이언트가 직접 지켜야 한다고 설명한다. 프로토콜 자체로는 결함이 있는 클라이언트가 대상 키를 재사용하는 일을 막을 수 없다. 따라서 엔클레이브뿐 아니라 클라이언트 구현도 보안 모델의 일부다.

Managed Secrets 제품 페이지에는 저장된 각 비밀 정보를 AES-256-GCM으로 암호화한다고 명시돼 있다. API는 개별 자격 증명 요청과 여러 비밀 정보를 한꺼번에 요청하는 방식을 모두 지원한다. 요청한 비밀 정보 중 하나라도 접근 권한이 없으면 묶음 내보내기 전체가 실패하므로, 일부만 승인된 묶음이 공개되는 일을 막을 수 있다.

수신자가 여전히 중요한 이유

“에이전트가 자격 증명을 보지 않고 사용할 수 있다”는 말은 통합 방식에 대한 설명이지, 자격 증명을 받는 모든 프로세스가 평문을 읽을 수 없다는 보장은 아니다. Turnkey의 개발자 문서는 평문이 엔클레이브 내부와 비밀 정보를 가져오거나 내보내는 클라이언트에 존재할 수 있다고 명시한다.

별도의 실행 서비스가 수신자 키를 보유하면, 모델에는 자격 증명을 노출하지 않은 채 이를 복호화해 사용할 수 있다. 에이전트 자체의 런타임이 해당 키를 보유한다면 런타임에서 자격 증명을 복호화할 수 있다. 따라서 수신자와 그 메모리, 로그를 보호하는 일은 여전히 필요하다.

또 다른 경계도 있다. 정책은 요청에 포함된 맥락, 예를 들어 사용자가 주장하는 결제 페이지의 도메인을 확인할 수 있지만, Turnkey가 그 주장의 진위를 독립적으로 검증하지는 않는다. 서명된 주장은 누가 그런 주장을 했는지를 확인해 준다. 애플리케이션은 그 주장을 실제 작업과 연결하는 신뢰할 수 있는 검증 절차를 여전히 마련해야 한다.

워크플로에 따라 조정할 수 있는 승인 방식

팀은 직접 가져오기를 허용하거나, 요청을 사람이 승인하도록 하거나, 여러 에이전트 역할 간 합의를 요구할 수 있다. 기반이 되는 비밀 정보를 다시 가져오지 않고도 정책을 변경할 수 있으므로, 처음에는 면밀한 감독 아래 워크플로를 시작한 뒤 일부 요청을 자동화할 수 있다.

Turnkey의 프로그래밍 방식 접근 가이드는 브라우저 에이전트와 결제 에이전트가 요청에 함께 서명하는 예를 보여 준다. 복호화할 수 있는 카드 정보를 받는 것은 결제 에이전트뿐이다. 승인하기 전에 브라우저 구성 요소는 제안된 도메인이 자신이 사용하는 페이지의 도메인과 일치하는지 확인한다. 이 예는 단순히 승인 수를 둘로 늘리는 것보다 독립적인 역할과 검증이 중요한 이유를 보여 준다.

에이전트 역할에는 범위가 제한되고 만료 시간이 있는 세션 자격 증명을 사용할 수 있어, 운영자가 실행 중인 특정 인스턴스 하나의 권한을 취소할 수 있다. 그러나 향후 접근 권한을 취소해도 수신자가 이미 복호화한 비밀 정보까지 지울 수는 없다. 따라서 이후에 자격 증명을 교체하는 일은 별도의 운영 통제로 남는다.

지갑 인프라에서 금융 자동화로

Turnkey의 기존 보안 아키텍처는 AWS Nitro Enclaves를 사용하며, 하드웨어 격리와 재현 가능한 빌드 및 원격 증명을 결합합니다. 재현 가능한 빌드를 통해 소프트웨어 빌드를 서로 비교할 수 있고, 원격 증명은 현재 실행 중인 엔클레이브 코드에 관한 근거를 제공합니다. Managed Secrets는 이러한 기반을 블록체인 서명 키 이외의 자격 증명으로 확장합니다.

회사는 트레이딩 업체, 핀테크 백엔드, AI 에이전트 개발자, MPC 수탁기관을 주요 이용자로 꼽습니다. 거래소 자격 증명과 OAuth 토큰은 지속적인 서비스 접근에 사용되며, 키셰어 백업과 복구 키는 복원력을 높이는 데 쓰입니다. 저장 인프라를 공유하더라도 이들은 승인 절차와 수신자 요건이 서로 다른 별개의 용도입니다.

금융 기술팀에 중요한 점은 작업 요청, 접근 권한 승인, 실제로 사용할 수 있는 자격 증명 수령을 더욱 명확히 구분할 수 있다는 것입니다. Managed Secrets는 이러한 구분을 뒷받침하는 인프라를 제공합니다. 이를 통해 얻는 보호 수준은 범위가 제한된 정책, 신뢰할 수 있는 승인자, 그리고 궁극적으로 비밀 정보를 사용하는 서비스의 보안 수준에 달려 있습니다.