AI 에이전트 보안의 누락된 계층: 감사 가능성(Auditability)은 관찰 가능성(Observability)이 아니다

며칠 전 누군가가 AI 에이전트 설정에 대한 분류 체계(Taxonomy)를 제안했습니다. 모델 자체부터 플릿 오케스트레이션(Fleet orchestration)에 이르기까지 5개의 계층으로 구성되어 있었죠. 이는 에이전트가 어떻게 구조화되어 있는지 보여주는 제가 본 것 중 가장 깔끔한 프레임워크였습니다. 하지만 모든 계층에서 무언가 빠져 있었습니다.

아직 아무도 그것의 이름을 명명하지 않았습니다.

관찰 가능성(Observability)은 무엇이 일어났는지 알려줍니다. 감사 가능성(Auditability)은 그것이 사실임을 알려줍니다.

오늘날 대부분의 에이전트 프레임워크(Agent frameworks)는 관찰 가능성(Observability)을 갖추고 있습니다. 에이전트가 무엇을 했는지, 어떤 도구(Tools)를 호출했는지, 어떤 출력(Outputs)을 생성했는지 확인할 수 있습니다. 로그(Logs), 트레이스(Traces), 대시보드(Dashboards) 등이 그것입니다.

하지만 그들에게 없는 것은 감사 가능성(Auditability)입니다. 즉, 기록이 정품이며 사후에 변경되지 않았음을 보장하는 암호학적 보증(Cryptographic guarantee)입니다.

이 둘은 같은 것이 아닙니다. 그리고 그 차이는 대부분의 팀이 깨닫는 것보다 훨씬 더 중요합니다.

이를 구체화하는 시나리오

금융 운영을 처리하는 에이전트를 상상해 보십시오. 이 에이전트는 계좌 데이터를 읽고, 조건을 평가하며, 이체를 자동으로 승인하거나 거절합니다.

여러분의 관찰 가능성 스택(Observability stack)은 에이전트가 오전 3시 42분에 47,000달러의 이체를 승인했다고 알려줍니다. 로그는 바로 거기에 있습니다.

하지만 그것을 증명할 수 있습니까?

그 로그가 사후에 작성되지 않았음을 증명할 수 있습니까? 승인한 에이전트가 여러분이 배포한 에이전트이며, 변경된 지침(Instructions)으로 실행되는 침해된 버전이 아니라는 것을 증명할 수 있습니까? 해당 동작이 가드레일(Guardrails)을 뚫고 들어온 악의적인 프롬프트(Malicious prompt)에 의해 주입되지 않았음을 증명할 수 있습니까?

관찰 가능성(Observability)은 "이 일이 일어났다"라고 말합니다. 감사 가능성(Auditability)은 "이 일이 일어났으며, 여기 암호학적 증거가 있고, 이는 논박될 수 없다"라고 말합니다.

금융 시스템, 의료, 법률 워크플로, 또는 에이전트의 출력이 실제적인 결과를 초래하는 모든 곳에서, 이 두 문장의 차이는 로그(Log)와 증거(Evidence)의 차이입니다.

이러한 격차가 존재하는 이유

에이전트 프레임워크(Agent frameworks)는 역량(Capability)과 신뢰성(Reliability)을 중심으로 구축됩니다. 에이전트가 작업을 수행할 수 있는가? 일관되게 수행하는가? 이것들이 현재 설계 영역을 지배하고 있는 질문들입니다.

보안은 단순히 그 위에 추가하는 계층으로 취급됩니다. 그리고 무엇이 일어났는지 증명할 수 있는 능력인 감사 가능성 (Auditability)은 아직 논의조차 되지 않고 있습니다.

에이전트 메모리 권한 부여 (Memory Authorization)를 연구하는 연구자들은 다른 각도에서 동일한 근본적인 문제에 부딪히고 있습니다. 그들의 질문은 에이전트가 검색한 메모리가 수행한 동작을 제어할 권한이 있었는가 하는 것입니다. 저의 질문은 에이전트가 수행한 동작이 사후에 정당함을 증명할 수 있는가 하는 것입니다. 두 공백 모두 동일한 결핍을 공유합니다. 바로 동작에 부착된 권한 체인 (Authority Chain)이 없다는 점입니다.

에이전트는 동작했습니다. 하지만 그 동작에 대해 서명된 것은 아무것도 없습니다.

감사 가능성 (Auditability)의 실제 모습

모델은 간단합니다. 모든 에이전트 동작은 서명된 토큰 (Signed Token)을 생성합니다.

const { token } = await pq.sign({
  sub:       "agent_payment_processor",
  action:    "approve_transfer",
...

이 토큰은 특정 에이전트가 특정 시간에 특정 동작을 수행했다는 암호학적 증거 (Cryptographic Proof)입니다. 토큰이 검증되면 해당 동작은 정당합니다. 검증되지 않는다면 무언가 변조되었거나 에이전트가 침해된 것입니다.

폐기 (Revocation)가 나머지 절반을 차지합니다. 에이전트가 침해되면 토큰이 만료될 때까지 기다리는 것이 아니라 즉시 자격 증명 (Credentials)을 폐기해야 합니다. 이후의 모든 검증 (Verify) 호출은 즉시 거부됩니다.

이를 통해 관찰 가능성 (Observability)이 제공할 수 없는 두 가지를 얻을 수 있습니다.

변조 방지 기록 (Tamper-evident records) — 동작 로그는 서명을 깨뜨리지 않고서는 사후에 변경될 수 없습니다.

즉각적인 자격 증명 폐기 (Instant credential revocation) — 무언가 잘못된 것으로 보이면 에이전트의 자격 증명을 회수하며, 토큰이 만료되는 5분 후가 아니라 즉시 신뢰를 중단합니다.

양자 내성 (Post-quantum) 관점

서명 인프라가 중요합니다. 만약 오늘 RSA나 ECDSA를 기반으로 에이전트 감사 가능성을 구축한다면, 이는 양자 컴퓨터가 이번 10년 내에 깨뜨릴 알고리즘 위에 구축하는 것과 같습니다. NIST는 2024년 8월에 양자 내성 표준 (Post-quantum standards)을 확정했습니다. ML-DSA-65 (FIPS 204)가 서명 표준입니다.

지금 감사 가능성 (Auditability)을 구축한다는 것은 위협이 현실화되었을 때도 여전히 유효할 알고리즘을 기반으로 구축함을 의미합니다. 나중에 마이그레이션(Migration)을 수행하는 비용은 오늘 제대로 해두는 것보다 훨씬 더 높습니다.

FIPSign은 바로 이 목적을 위해 제가 구축한 API로, 양자 내성 서명 (Post-quantum signing), 검증 (Verification), 그리고 서비스형 폐기 (Revocation as a service)를 제공합니다. 에이전트는 그저 또 다른 sub일 뿐입니다. 기존 아키텍처(Architecture)를 변경할 필요가 없습니다. 감사 가능성 계층은 여러분이 이미 실행 중인 무엇이든 그 위에 위치합니다. JS/TS 및 Python SDK를 사용할 수 있습니다.

질문해야 할 가치가 있는 질문

오늘날 프로덕션 환경에 에이전트를 배포하는 대부분의 팀은 "에이전트가 무엇을 했는가?"라는 질문에 답할 수 있습니다.

하지만 "그것을 증명할 수 있는가?"라는 질문에 답할 수 있는 팀은 훨씬 적습니다.

만약 여러분의 에이전트가 재무적, 법적, 의료적, 운영적 측면에서 실제적인 결과가 따르는 결정을 내리고 있다면, 두 번째 질문은 곧 닥쳐올 것입니다. 지금 이 질문에 답할 수 있는 팀은 감사가 시작될 때 컴플라이언스 (Compliance) 스토리를 갖추게 될 것입니다. 그렇지 못한 팀은 압박 속에서 감사 가능성 계층을 재구축해야 할 것입니다.

인프라는 이미 존재합니다. 위협 모델 (Threat model)은 실재합니다. 마이그레이션은 지금 하면 저렴하지만, 나중에는 비싸집니다.

여러분의 스택에서 에이전트 감사 가능성을 고민하고 있다면, 여러분이 어떻게 접근하고 있는지 진심으로 듣고 싶습니다. 댓글을 남겨주세요. 특히 폐기 타이밍을 까다롭게 만드는 탐지 지연 (Detection latency) 문제에 직면해 보셨다면 더욱 좋습니다.