에이전트가 닿을 수 없는 경계가 가장 안전한 경계다
AI 에이전트가 여러 조직의 인프라를 운영한다면, 보안은 악몽이 됩니다.
위험은 에이전트가 영리한 실수를 저지르는 것이 아닙니다. 진짜 위험은 에이전트가 엉뚱한 사람을 위해 아주 일상적인 일을 수행하는 것입니다.
고객 A 대신 고객 B를 위해 티켓을 작성하거나 비밀값(secret)을 교체하는 것은 보안 침해(breach)입니다. 보안 침해는 패치로 해결할 수 없습니다. 반드시 공개해야 합니다.
대부분의 사람들은 권한(permissions)으로 이 문제를 해결하려 합니다. 에이전트가 접근할 수 있는 항목의 목록을 만들고, 모든 동작을 그 목록과 대조하여 확인합니다.
이 방식은 실패합니다. 권한 방식은 리소스가 존재한다는 것을 전제로 하며, 단지 '안 된다'고 말할 뿐입니다. 만약 규칙에 버그가 있거나 누락된 케이스가 있다면, 에이전트는 잘못된 데이터에 접근하게 됩니다.
저는 다른 모델을 사용합니다. 잘못된 데이터가 구조적으로 존재하지 않게 만드는 것입니다.
고객 A를 위한 세션에서는 고객 B의 리소스가 존재하지 않습니다. 자격 증명(credentials)은 로드되지 않으며, 엔드포인트(endpoints)는 맵에 존재하지 않습니다. 요청할 대상이 없으므로, 거부할 대상도 없습니다.
규칙에는 버그가 있을 수 있지만, 시스템의 물리적 구조에는 버그가 없습니다.
저는 이 사실을 뼈저리게 배웠습니다. 비밀값 관리자(secrets manager)만 있으면 충분하다고 생각했습니다. 비밀값을 격리하면 테넌트(tenant)도 격리될 것이라고 믿었습니다. 제 생각이 틀렸습니다.
비밀값 관리자는 비밀값을 격리하지만, 엔드포인트를 격리하지는 않습니다. 에이전트가 고객 A에 대한 올바른 토큰을 가지고 있더라도, 해당 주소가 설정에 포함되어 있다면 고객 B의 주소로 요청을 보낼 수 있습니다.
유출은 비밀값에서 발생하는 것이 아니라, 라우팅(routing)에서 발생합니다.
저는 모든 리소스를 하나의 레코드로 결합하여 이 문제를 해결했습니다: • Resource (리소스) • Endpoint (엔드포인트) • Credential (자격 증명) • Owning tenant (소유 테넌트)
소유자를 확인하지 않고는 주소를 얻을 수 없습니다. 데이터를 전송하는 라이브러리는 테넌트가 세션과 일치하지 않으면 작동을 거부합니다. 주소는 소유자와 결합되었을 때만 존재하기 때문에, 하드코딩으로 이를 우회할 수도 없습니다.
저는 세 가지 방어 계층을 사용합니다:
- 구조적 격리(Structural isolation): 잘못된 데이터가 존재하지 않도록 합니다.
- 바이패스 차단(Bypass block): 에이전트가 원시 도구(raw tools)를 사용하여 체크를 건너뛰지 못하게 합니다.
- 이그레스 스코핑(Egress scoping): 세션이 허용된 주소로만 통신할 수 있도록 합니다.
이는 '페일 클로즈(fail closed, 오류 시 차단)' 시스템을 구축합니다.
이전 업무에서 저는 '페일 오픈(fail open, 오류 시 허용)'을 주장했습니다. 에이전트가 어떤 동작이 안전한지 확신할 수 없다면, 일단 진행해야 한다고 생각했습니다. 의구심이 생길 때마다 멈춰버리는 에이전트는 쓸모가 없으니까요.
하지만 테넌트 경계는 다릅니다. 에이전트가 자신이 만지고 있는 데이터가 누구의 것인지 확신할 수 없다면, 반드시 멈춰야 합니다.
행동의 불확실성은 움직임을 초래한다. 소유권의 불확실성은 반드시 정지로 이어져야 한다.
'아니오'라고 답하는 검증 로직을 만들지 마라. 검증이 필요한 형태 자체를 제거하라.
출처: https://dev.to/artemmatviychuk/the-safest-boundary-is-the-one-the-agent-cant-reach-across-20ad
선택 사항 학습 커뮤니티: https://t.me/GyaanSetuAi