AI 에이전트에게는 OAuth 스코프만으로는 부족한 이유 (그리고 내 LLM이 차를 걸어오라고 말한 이유)

최근에 가벼운 모델을 통해 실행해 본 프롬프트입니다.

"차를 씻어야 하는데, 세차장이 집에서 단지 50미터 떨어져 있어요. 차를 가져갈까요 아니면 걸어갈까요?"

모델은 연료와 시동(cold-start) 배출가스를 절약하기 위해 집에 차를 두고 세차장까지 걸어가야 한다고 설명하는, 매우 잘 형식화되고 논리 정연한 답변을 저에게 주었습니다.

이것은 우스꽝스럽고 쉽게 발견할 수 있는 논리적 오류입니다. 하지만 개발자로서 우리는 이것에 조금 겁을 먹어야 합니다.

우리는 고립된 채팅 인터페이스에서 벗어나 자율적인 AI 에이전트를 구축하는 방향으로 빠르게 이동하고 있습니다. LangGraph나 사용자 지정 TypeScript 루프를 사용하여 이러한 워크플로우를 오케스트레이션하든, 우리는 갑자기 이 비결정론적(non-deterministic) 모델들에게 툴 호출을 실행하고, 인프라 API에 접속하며, 데이터베이스를 조작할 수 있는 주체성(agency)을 부여하게 됩니다.

비결정론적 AI를 위한 결정론적 인증의 문제점
만약 오늘날 에이전트를 구축하고 있다면, 어떻게 접근 권한을 보호하고 있습니까?

우리 대부분은 우리가 아는 것에 의존합니다: API 키와 OAuth 스코프. 하지만 read, write, 또는 admin과 같은 표준 OAuth 스코프는 예측 가능한 루틴을 실행하는 결정론적 소프트웨어를 위해 설계되었습니다.

이것들은 AI에게는 완전히 불충분합니다.

에이전트에게 쓰기(write) 권한이 있는 토큰을 주더라도, 인증 서버는 에이전트가 왜 요청을 하는지는 신경 쓰지 않습니다. 만약 고정확도의 최첨단 모델(frontier model)이 환각(hallucinates)을 일으켜 파괴적인 명령을 자신 있게 내리기로 결정한다면, 표준 인증 방식은 기꺼이 토큰을 검증하고 폭발 반경(blast radius)을 실행할 것입니다.

추론 엔진이 예측 불가능한 논리적 붕괴에 취약하다면, 신뢰나 보안을 당연하게 여길 수 없습니다.

에이전트 접근 보안 브로커(AASB) 구축
우리는 LLM의 추론 과정을 '고칠' 수는 없지만, 그 경계는 반드시 통제해야 한다는 것을 깨달았습니다. 이것이 바로 우리가 SecuriX를 구축하는 이유입니다.

단순한 소비자용 래퍼(Consumer wrapper)를 만드는 대신, 우리는 SecuriX를 처음부터 B2B 인프라 API 레이어로 설계했습니다. 이는 에이전트 액세스 보안 브로커(Agent Access Security Broker) 역할을 수행하며, AI 에이전트와 백엔드 서비스(기업 데이터) 사이에 위치하는 특화된 프록시(Proxy)로 작동합니다.

우리가 이 문제를 해결하는 방법은 다음과 같습니다:

코드형 정책 (Policy-as-Code): 우리는 Open Policy Agent (OPA)와 Rego를 활용합니다. 광범위한 스코프(Scope)에 의존하는 대신, 네트워크 프록시 레이어에서 API 도구 호출을 가로채고 필터링하는 세밀한 Rego 스크립트를 작성합니다.

수학적 경계 (Mathematical Boundaries): 프롬프트의 특정 컨텍스트를 기반으로 에이전트가 접근할 수 있는 파라미터(Parameter), 값(Value), 엔드포인트(Endpoint)에 대해 정확하고 수학적인 경계를 정의합니다.

초안 전용 강제 및 감사 추적 (Draft-Only Enforcement & Audit Trails): 운영 환경을 망가뜨리지 않고 에이전트가 규칙에 따라 어떻게 행동하는지 확인하기 위해 "초안 전용 (Draft-Only)" 모드에서 정책을 테스트할 수 있습니다. 이 모든 과정은 완전한 감사 추적(Audit trails)과 즉각적인 킬 스위치(Kill switches)를 갖춘 신뢰 포털(Trust Portal)에 의해 뒷받침됩니다.

설령 기반 모델이 혼란을 겪어 사용자에게 "차를 세차장까지 끌고 가라"고 말하는 것과 같은 상황이 발생하더라도, 에이전트는 여러분이 정의한 Rego 정책에 의해 물리적으로 제한되어 있기 때문에 인프라는 안전하게 유지됩니다.

우리는 공개적으로 구축하고 있습니다 (Building in Public)
AI를 위한 보안 도구는 여전히 서부 개척 시대와 같으며, 우리는 이를 올바르게 구현하고 싶습니다.
커뮤니티의 다른 빌더(Builder)분들의 의견을 듣고 싶습니다. AI 에이전트에게 API 접근 권한을 부여할 때, 현재 가드레일(Guardrails)을 어떻게 처리하고 계신가요? 체크 로직을 하드코딩하고 계신가요, 아니면 그저 시스템 프롬프트(System prompt)가 잘 버텨주기만을 기도하고 계신가요?

댓글에서 함께 논의해 봅시다. 👇