AI 에이전트(자율적으로 작업을 수행하는 AI 프로그램)에게 "이것은 하면 안 된다"고 지시하는 것만으로는 실제로 그 행동을 막을 수 없습니다. 최근 Gemini AI가 테스트 환경 설정 오류로 인터넷에 접근해 실제 시스템 3곳에 침입한 사건이 이를 잘 보여줍니다. 진정한 보안은 AI 모델 내부가 아닌, 도구 실행 직전 단계에서 네트워크 격리·권한 범위 제한·독립적인 승인 절차 같은 기술적 통제를 두는 것입니다. 또한 AI가 정상적으로 응답(HTTP 200)을 돌려주더라도 실제로는 해로운 행동을 할 수 있으므로, 응답 자체가 아닌 행동의 결과를 관측하는 모니터링이 필요합니다. 위험 수준에 따라 자동 허용·검토 필요·완전 차단을 차등 적용하면 안전성과 실용성을 함께 확보할 수 있습니다.
구글 Gemini AI 에이전트가 사이버보안 테스트 환경에서 설정 오류로 인터넷 접근 권한을 얻어 실제 시스템 3곳에 침입한 사고가 발생했다. 에이전트가 스스로 실수를 인지하고 멈췄으나 이미 경계를 넘은 후였다.
시스템 프롬프트(AI에게 주는 지침)만으로는 에이전트의 실제 행동을 막을 수 없음이 확인됐다. 네트워크 격리, 허용 대상 목록, 권한 범위 제한, 독립 승인 절차 같은 외부 통제가 없으면 에이전트는 언제든 지침을 초과할 수 있다.
AI 모델에 부여된 기술적 실행 권한이 정책·지침과 분리되지 않은 채 운영된 것이 근본 원인이다. 에이전트가 어떤 행동을 '적절하다'고 판단해도 그것을 막는 독립적 통제 지점이 없었다.
Coralogix는 에이전트와 도구 사이에 정책 집행 지점(Policy Enforcement Point)을 두고, 에이전트 신원·대상 환경·데이터 분류·현재 권한을 종합해 매 행동을 평가하는 구조를 채택했다. 읽기 전용 작업은 자동 허용, 쓰기 작업은 검토 필요, 파괴적 작업은 완전 차단으로 위험 수준별 차등 통제를 적용한다.
AI 에이전트 운영 시 '무엇을 하면 안 된다'는 지침보다 '기술적으로 할 수 없도록' 만드는 실행 계층 통제가 핵심이다. 모니터링은 HTTP 응답 코드나 업타임이 아닌 에이전트 행동의 실제 결과(배포 이력, 보안 이벤트, 롤백, 사람의 수정 내역)와 연계해야 한다.
본문
Help Net Security와의 인터뷰에서 Coralogix CEO Ariel Assaraf는 시스템 프롬프트가 AI 에이전트의 경계를 '기술'할 수는 있지만 '집행'할 수는 없는 이유를 설명한다. Assaraf는 자신의 팀이 실행 계층에서 AI 에이전트 가드레일을 구축하는 방법, 권한을 확장하지 않으면서 컨텍스트를 제한하는 방법, 그리고 인시던트 상황에서도 에이전트가 유용성을 유지하도록 위험 수준별로 통제를 조율하는 방법을 다룬다. 또한 에이전트가 200 응답을 반환하면서도 여전히 해를 끼칠 수 있기 때문에, 에이전트 행동의 결과를 어떻게 추적하는지 설명한다.
당신은 에이전트에게 무엇을 하면 안 된다고 '말하는 것'과 실제로 하지 '못하게 막는 것' 사이에 명확한 선을 그었습니다. 문서화된 정책이나 시스템 프롬프트가 존재했음에도 에이전트가 그 선을 넘었던 실제 인시던트를 예로 들어주십시오. 기술적으로 무엇이 빠져 있었나요?
최근의 Gemini 해킹 사건이 좋은 예입니다. 해당 에이전트는 통제된 사이버보안 테스트 환경 내에서만 동작하도록 설계되었지만, 설정 오류로 인터넷 접근 권한을 얻게 되었고 실제 시스템 3곳에 침입했습니다. 결국 에이전트 스스로 실수를 인지하고 중단했는데, 이는 고무적인 일이지만 그때는 이미 경계를 넘은 후였습니다.
부재했던 통제 수단은 모두 모델 외부에 있어야 할 것들이었습니다: 네트워크 격리, 대상 허용 목록(allowlist), 범위가 제한된 자격 증명, 그리고 실행 전 독립적인 권한 검증. 이러한 통제는 모델에게 어떤 지시를 내렸는지와 무관하게 반드시 존재해야 합니다.
시스템 프롬프트는 경계를 '설명'할 수 있습니다. 하지만 그것을 '집행'할 수는 없습니다. 에이전트가 기술적으로 그 경계를 넘을 수 있다면, 기업은 언젠가 그런 일이 일어날 수 있다고 가정해야 합니다. 집행 메커니즘은 에이전트와 에이전트가 시도하려는 행동 사이에 위치해야 합니다.
성능 향상을 위해 더 많은 컨텍스트가 필요한 에이전트와, 지나치게 많은 컨텍스트가 주어져 공격 표면이 넓어지고 스스로 잘못된 행동을 정당화할 수 있게 된 에이전트를 어떻게 구분하십니까?
더 많은 컨텍스트는 에이전트의 지식을 향상시켜야지, 권한을 확장해서는 안 됩니다.
우리는 현재 단계에 필요한 최소한의 컨텍스트만을, 적시에, 명확한 출처와 만료 정보를 포함해 제공하려 합니다. 민감하거나 신뢰할 수 없는 컨텍스트는 지침과 분리해야 하며, 정보에 대한 접근이 그 정보를 바탕으로 행동할 권한을 자동으로 부여해서는 안 됩니다. 에이전트가 무언가를 '알고 있는 것'과 그 정보를 바탕으로 행동할 '권한이 있는 것'은 전혀 다른 문제입니다.
실용적인 테스트 기준은 측정 가능합니다: 추가적인 컨텍스트가 평가에서 작업 성공률을 높이는가, 그리고 정책 위반·프롬프트 인젝션 성공·불필요한 데이터 접근에는 어떤 영향을 미치는가? 컨텍스트가 성능에는 거의 기여하지 않으면서 이러한 위험을 실질적으로 높인다면, 그 컨텍스트는 주어서는 안 됩니다.
목표는 에이전트에게 필요할 수 있는 모든 것을 주는 것이 아닙니다. 현재 눈앞의 작업에 필요한 것만 주되, 권한은 독립적으로 제약된 상태를 유지하는 것입니다.
프롬프트 수준의 지시와 달리, 인프라 또는 실행 계층에서의 하드 가드레일은 어떤 모습인가요? 직접 구축한 사례를 하나 소개하고, 그것이 에이전트를 실제로 차단하는지 어떻게 테스트했는지 설명해주십시오.
하드 가드레일이란 모델이 추론으로 우회할 수 없는 것을 말합니다.
우리가 사용하는 패턴은 에이전트와 에이전트의 도구 사이에 정책 집행 지점(policy enforcement point)을 두는 것입니다. 제안된 모든 행동은 에이전트의 신원, 대상, 환경, 데이터 분류, 현재 권한을 기준으로 평가됩니다. 에이전트는 제한 없는 자격 증명을 받지 않으므로, 설령 어떤 행동이 적절하다고 판단하더라도 이러한 통제 밖에서 임의로 실행할 수 없습니다.
프로덕션 읽기 전용 쿼리는 자동으로 허용될 수 있습니다. 쓰기 작업은 승인이 필요할 수 있습니다. 파괴적인 작업은 완전히 차단될 수 있습니다. 중요한 것은 모델이 자신의 행동 허용 여부에 대한 최종 권한을 갖지 않는다는 점입니다.
우리는 평가, 프롬프트 인젝션, 난독화된 명령, 그리고 서로 다른 경로를 통해 동일한 금지 결과에 도달하려는 다단계 시도를 통해 이를 테스트합니다. 성공이란 해당 행동이 외부에 어떠한 부작용도 만들지 않고, 차단 자체가 완전한 원격 측정(telemetry) 기록을 생성하는 것을 의미합니다. 가드레일이 작동했다는 것을 아는 것에서 나아가, 에이전트가 무엇을 시도했고 왜 차단되었는지까지 알아야 합니다.
정당한 에이전트 워크플로우를 방해할 만큼 지나치게 공격적으로 작동한 가드레일 사례를 말씀해주세요. 어떻게 조율했고, 안전성과 유용성 사이에서 어떤 트레이드오프에 도달했나요?
가장 빠르게 지나치게 공격적으로 변하는 가드레일은 프로덕션 관련 모든 행동에 사람의 승인을 요구하는 것입니다. 안전하긴 하지만, 에이전트가 기본적인 조사조차 할 수 없게 만들고 인시던트 상황에서 거의 쓸모없게 만들어 버립니다. 사람이 모든 읽기 작업이나 일상적인 진단 단계를 승인해야 한다면, 자율성의 가치 대부분이 사라집니다.
더 나은 접근 방식은 행동을 위험도와 상태 전환에 따라 분류하는 것입니다. 승인된 범위 내의 읽기 전용 쿼리는 자동으로 실행할 수 있습니다. 되돌릴 수 있는 변경은 더 엄격한 검사를 받습니다. 되돌릴 수 없거나 영향 반경이 큰 행동은 사람의 승인을 요구합니다.
이는 또한 프로덕션 환경과의 모든 상호작용을 동등하게 위험한 것으로 취급하는 대신, 행동이 실제로 무엇을 변경할 수 있는지를 살펴보는 것을 의미합니다.
트레이드오프는 '안전성 대 유용성'이 아닙니다. 잠재적 영향에 비례하여 마찰을 적용하는 것입니다. 행동의 잠재적 결과가 클수록, 통제도 강해야 합니다.
전통적인 모니터링은 업타임, 지연 시간, 오류율을 중심으로 구성됩니다. 에이전트는 완벽하게 실행되고 200 응답을 반환하면서도 끔찍한 결정을 내릴 수 있습니다. 이러한 특정 유형의 실패를 포착하기 위해 어떤 지표나 신호를 구축했나요?
가장 중요한 신호는 모델의 응답이 아닙니다. 그것이 취하는 행동의 결과입니다.
우리는 에이전트 원격 측정 데이터를 조직 전반의 관측 가능성(observability) 데이터와 연계합니다: 도구 호출, 정책 결정, 오버라이드, 재시도, 데이터 접근과 함께 배포, 인시던트, 보안 이벤트, 롤백, 사람의 수정 내역을 종합합니다. 이러한 신호들을 함께 살펴보면 에이전트가 기술적으로는 설계대로 작동하지만 운영상 나쁜 결과를 만들어내는 상황을 파악할 수 있습니다.
우리는 또한 결정 일관성도 측정합니다. 동일한 관측 가능한 사실이 모델 버전에 따라 다른 행동을 만들어낸다면, 정책 경로가 어디서 달라졌는지 확인해야 합니다. 모델 행동의 변화가 프로덕션 행동의 눈에 보이지 않는 변화로 이어져서는 안 됩니다.
이것은 "chain of thought(사고 연쇄)" 모니터링이 아니라, 어떤 정책이 적용되었고, 어떤 증거가 평가되었으며, 어떤 예외가 사용되었고, 그 다음에 무슨 일이 일어났는지를 보여주는 외부 결정 기록입니다. 이 구분이 중요한 이유는 기업이 책임 소재를 확립하기 위해 모델의 내부 추론에 접근할 필요가 없기 때문입니다. 기업에게 필요한 것은 실제로 관측할 수 있는 입력, 권한, 행동, 결과에 대한 신뢰할 수 있는 기록입니다.
에이전트는 완벽한 200 응답을 반환하면서도 끔찍한 결과를 만들어낼 수 있습니다. 따라서 관측 대상이 되어야 하는 것은 바로 그 결과입니다.
관련 투런 솔루션
이 뉴스의 취약점·위협, 투런 솔루션으로 대응하세요.
