AI 에이전트(AI agents)는 코드를 배포하고, 인프라를 수정하며, 민감한 시스템을 조회하고, 금융 작업을 시작하는 능력을 점점 더 많이 갖추게 되고 있습니다. 대화형의 **"정말인가요?"**라는 프롬프트는 유용하지만, 이는 독립적인 권한 부여(authorization)가 아닙니다. 액션을 제안한 것과 동일한 에이전트가 확인 흐름(confirmation flow) 또한 제어할 수 있기 때문입니다.

저는 다음과 같은 네 가지 속성을 가진 승인 메커니즘을 원했습니다:

1. 사람이 하나의 특정 액션을 승인한다.
2. 승인은 빠르게 만료된다.
3. 다른 도구 호출(tool call)을 위해 재사용(replay)될 수 없다.
4. 승인 서비스가 에이전트의 프롬프트나 소스 코드를 필요로 하지 않는다.

그 결과물은 GoodRoom.verify입니다. 이는 운영자가 패스키(passkey)로 검증하는 동안 설정된 고위험 액션을 일시 중지하는 MCP 사이드카(sidecar)입니다.

승인 흐름 (The approval flow)

에이전트는 사람이 읽을 수 있는 요약(summary), 정형화된 액션의 SHA-256 해시(hash), 위험 수준(risk level), 그리고 보호된 도구를 식별하는 대상(audience)과 함께 MCP 도구를 호출합니다.

{
  "action_summary": "Deploy migration to production",
  "action_hash": "sha256:...",
...

게이트웨이는 해당 필드들을 승인 API(approval API)로 전송하고, 별도의 승인 및 폴링(polling) 기능을 수신합니다. 승인 페이지에는 요약 내용이 표시되며 WebAuthn 사용자 검증을 요청합니다.

검증이 성공하면, API는 원자적(atomically)으로 챌린지(challenge)를 소비하고 수명이 짧은 Ed25519 증명(proof)을 발행합니다. MCP 게이트웨이는 공개 JWKS를 다운로드하여 서명(signature), 발행자(issuer), 대상(audience), 액션 해시(action hash), 키 ID(key ID), 만료 시간(expiry)을 로컬에서 검증합니다.

보호된 작업은 반드시 해당 증명을 독립적으로 요구해야 합니다. 이러한 강제 지점(enforcement point)이 없다면, 승인 UI는 단지 권고 사항(advisory)에 불과합니다.

왜 패스키인가? (Why passkeys?)

WebAuthn은 신뢰할 수 있는 당사자(relying party)와 연결된, 피싱 저항성(phishing-resistant)이 있는 사용자 검증을 제공합니다. 개인 자격 증명(private credential)은 플랫폼 인증기(platform authenticator) 또는 하드웨어 키에 남아 있습니다. 또한 이는 물리적인 운영자의 존재를 에이전트 런타임(agent runtime)에 의해 제어되는 또 다른 버튼보다 더 명확한 보안 경계로 만들어 줍니다.

경계를 넘나드는 것을 최소화하기 (Minimize what crosses the boundary)

승인 서비스는 프롬프트(prompt), 대화(conversation), 소스 코드(source code) 또는 가공되지 않은 도구 인자(raw tool arguments)를 가질 필요가 없습니다. GoodRoom.verify는 제한된 디스플레이 요약(display summary)과 액션 해시(action hash)를 전달받습니다.

지속적인 감사 기록(audit records)은 요약본을 유지하지 않고도 해시, 결과, 증명 식별자(proof identifier) 및 타임스탬프를 보관할 수 있습니다.

증명이 결합(bind)해야 하는 요소

유용한 실행 증명(execution proof)은 단순히 "승인됨(approved)"이라는 불리언(boolean) 값 이상의 것이 필요합니다. GoodRoom.verify 설계는 증명을 다음 요소들과 결합합니다:

• 계정 및 챌린지(challenge);
• 정규화된 액션 해시(canonical action hash);
• 보호된 도구 대상(protected tool audience);
• 위험 수준(risk level);
• 고유한 증명 식별자(unique proof identifier);
• 짧은 유효 기간(short validity window).

보호된 도구는 일치하지 않는 대상(audience) 또는 액션 해시, 만료된 서명, 알 수 없는 서명 키, 그리고 재사용된 증명 식별자를 거부해야 합니다.

이것이 해결하지 못하는 것

이 설계는 특정 액션이 안전한지 여부를 결정하거나, 도구를 샌드박스(sandbox)화하거나, 런타임(runtime)이 승인 도구를 우회하는 것을 방지하지는 않습니다. 에이전트 런타임(agent runtime) 또는 도구 래퍼(tool wrapper)가 증명 검증을 강제해야 하며, 실행될 것과 동일한 정규화된 액션(canonical action)을 해싱해야 합니다.

마지막 점이 매우 중요합니다. 검토된 페이로드(payload)와 실행된 페이로드가 서로 다를 수 있다면, 그 승인은 의미가 없습니다.

강제(enforcement)는 어디에 위치해야 하는가?

세 가지 가능한 위치가 있습니다:

1. 런타임 정책(Runtime policy): 일관되게 적용하기 쉽지만, 런타임 경계(runtime boundary)의 강도만큼만 강력합니다.
2. MCP 서버 미들웨어(MCP server middleware): 도구 디스패치(tool dispatch)와 가깝고 여러 도구에서 재사용할 수 있지만, 다른 경로로 도구에 접근할 경우 우회될 수 있습니다.
3. 최종 도구 또는 API(The final tool or API): 실행과 가장 강력하게 결합되지만, 가장 깊은 수준의 통합이 필요합니다.

저의 현재 선호 방식은 심층 방어(defense in depth)입니다. 사용성을 위해 런타임 또는 MCP 정책을 사용하되, 가능한 경우 항상 민감한 도구 경계에서 최종 검증을 수행하는 것입니다.

GoodRoom.verify는 현재 프라이빗 베타 MVP(private-beta MVP) 단계이며, 완성된 보안 제품이 아닙니다. 저는 민감한 도구를 사용하여 에이전트를 구축하는 개발자들로부터, 특히 증명 강제(proof enforcement) 및 액션 정규화(action canonicalization)에 대한 피드백을 기다리고 있습니다.

아키텍처 확인 및 베타 액세스 요청하기.

오늘날 당신의 에이전트가 호출할 수 있는 가장 위험한 도구는 무엇이며, 어디에서 인간의 승인(human approval)을 강제하고 있습니까?