신뢰 경계를 벗어날 수 없는 보안 에이전트 구축하기

Shaked Zin, 공동 창업자 겸 CEO

운영 인프라에 대한 실시간 접근 권한을 가지되, 읽기 전용으로 구성하고 런타임에 에이전트가 범위를 넓힐 경로를 차단하는 방식.

'모델들이 길들여지지 않은 해커'라는 제목의 기사들이 피드 곳곳에서 보이고 있고, 논쟁은 대부분 의도(intent)에 관한 것입니다. 하지만 의도는 가장 흥미롭지 않은 부분입니다. 중요한 것은 여러분이 바로 그 모델들을 자신의 인프라에 직접 접근하도록 내어주려 한다는 것이고, 보안을 자동화할 때 이들이 행동에 대한 최종 결정을 내리도록 하는 것은 미친 짓일 수 있습니다. 에이전트가 실수를 멈추기 전까지는 데이터 삭제나 클라우드 인프라 구성을 변경하는 것을 에이전트의 환각(hallucinate)에 맡길 여유가 없습니다.

이를 우회하는 한 가지 방법은 핵심 인프라 부분을 데이터 레이크(data lake)로 미러링하여 에이전트가 그곳에서 작동하게 하고, 라이브 인프라를 직접 건드리지 않도록 하는 것입니다. 모든 SaaS 보안 제품들이 그렇게 작동합니다: Palo Alto Networks, CrowdStrike, Wiz 및 AI 네이티브의 도전자들 모두 그렇습니다. 이는 유효한 경로이지만 대가가 따릅니다: 비용, 부분적인 데이터, 동기화 지연(sync delay), 그리고 가장 중요하게는 데이터 주권 상실과 막대한 운영 오버헤드 사이에서 선택해야 한다는 것입니다.

고전적인 방어자-공격자 비대칭성(defender-attacker asymmetry)은 현실이며, 공격자들이 최첨단 모델(frontier models)과 코딩 에이전트를 이용해 잠재적인 모든 틈을 찾아 자동으로 악용할 수 있게 되면서 더 큰 문제가 되고 있습니다. 자원만으로는 예전처럼 이 격차를 보상해주지 못합니다: 여러분에게는 인프라에 직접 접근하는 주권적(sovereign) 에이전트가 필요합니다.

저희는 일부 대기업 파트너들로부터 비슷한 패턴을 들었습니다. 이들은 한 프론티어 랩의 최고급 모델에 제한적인 초기 접근 권한을 부여받았습니다. 마침내 공격자들이 가진 것보다 더 뛰어난 추론 능력을 갖춘 모델에 접근할 수 있게 되었지만, 그렇게 민감한 접근 권한을 맡길 만큼 신뢰할 수 있는 에이전트가 없었기 때문에, 프롬프트 내에 코드 저장소를 복사하여 붙여넣는 방식을 택했습니다. 이는 비용이 많이 들고, 런타임(runtime)이 없는 코드이며, 동기화(sync)도 없고, 조직의 나머지 부분과 분리된 전담 특수 임무팀이라는 오버헤드까지 발생시켰습니다.

에이전트에게 인프라에 대한 최소 권한 읽기 전용 접근(least-privilege read-only access)을 부여해야 합니다. 하지만 그것만으로는 충분하지 않습니다. 대규모 조직에서 서버 측의 ID 및 접근 관리(identity and access management)는 경향상 벗어나게 됩니다(drift). 기회를 준다면 에이전트는 자신의 경계를 바꿀 창의적인 방법을 찾아낼 것입니다.

저희가 인프라 보안 심층 연구 에이전트인 Cynative를 구축하면서 이 격차를 해결하기 위해 취한 접근 방식은 양방향 아키텍처(two-sided architecture)입니다. 바로 샌드박스(sandbox)와 액션 게이트(action gate)입니다. 샌드박스는 외부 세계에 대한 접근 권한이 전혀 없는 상태로 모델이 작성한 코드를 실행합니다. 네트워크, 파일 시스템, 호스트 API 등 아무것도 접근할 수 없으며, 명시적으로 등록된 도구들만 사용할 수 있습니다. 액션 게이트는 자격 증명(credential)이 첨부되기 전에 모든 커넥터 호출을 읽기 전용 정책에 따라 승인하며, 실패 시 폐쇄(fails closed)됩니다. 이 에이전트는 선택적 필터를 우회할 수 있는 것이 아니라 구조적으로 읽기 전용입니다.

이러한 방식으로 주권적인 에이전트(sovereign agent)는 필요한 실시간 데이터에 대해 추론하기 위한 코딩 에이전트의 유연성을 갖추면서도, 어떤 경우에도 실시간 인프라를 변경하거나 데이터를 유출할 수 없습니다. 동일한 원칙은 나머지 부분 전체에 적용됩니다. 클라우드 제공업체 자체 세션도 읽기 전용으로 유지하고, 시크릿(secrets)은 모델에 도달하기 전에 마스킹하며, 실패 시 폐쇄되는 감사 로그(audit log)를 사용합니다. 하지만 각각이 별개의 문제입니다.

모델은 여전히 당신이 가리키는 모든 것을 볼 수 있습니다. 따라서 Cynative는 단일 바이너리로 배포되어, 당신이 선택하는 어떤 모델 엔드포인트(cloud provider가 이미 제공하는 것 포함) 안에서 실행됩니다. 이를 통해 인프라스트럭처, 모델, 에이전트 모두 같은 계정 내에 위치하게 됩니다. 즉, 당신의 인프라 내부에서 당신의 인프라에 대한 보안을 운영하는 것입니다.

만약 자체적인 보안 에이전트를 구축하고 있다면, 경계가 유지되려면 두 가지 조건이 충족되어야 합니다. 첫째, 추론 환경(reasoning environment)은 명시적으로 허용되지 않은 어떤 것도 도달할 수 없어야 하며, 둘째, 허용되는 집합(allowed set)은 설계 시점에 결정되어야 하고 에이전트가 실행 중에 이를 확장할 경로가 없어야 합니다. 이 두 가지를 잘못 설정하면 경계는 모델이 필요하다고 판단하는 순간 재해석할 자유가 있는 단순한 제안에 불과하게 됩니다. 하지만 제대로 구현한다면, 프로덕션 환경에 적용하고 안심할 수 있습니다.

저희는 이것을 오픈 소스 프로젝트로 구축하여 여러분이 자유롭게 사용할 수 있도록 했습니다. 이를 통해 인프라스트럭처에 대한 심층적인 연구를 수행하거나, 이 아키텍처를 활용하여 자체 보안 에이전트를 구축하는 프레임워크로 사용하고 워크플로우와 로직을 구현할 수 있습니다.

코드 및 문서는 다음에서 확인하세요: github.com/cynative/cynative