2026년 7월 16일, Hugging Face는 자사 인프라 일부가 자율 AI 에이전트 시스템에 의해 침해된 사건을 공개했습니다. 닷새 뒤 OpenAI는 자사 모델의 사이버 역량을 내부에서 시험하던 중, 평가에 투입된 모델들이 격리된 내부 평가 환경을 벗어나 인터넷 연결 경로를 확보한 뒤 Hugging Face의 실제 운영 인프라까지 침입했다고 밝혔습니다.
2026년 7월 30일, Anthropic은 Claude가 사이버 역량 평가 도중 인터넷상의 외부 조직 시스템을 시험용 표적으로 잘못 판단해 접근한 세 건의 사례를 공개했습니다. 평가 설계에서는 모든 표적이 인터넷과 분리된 가상 환경 안에 있다고 전제했지만, 실제 평가 장비에는 설정 오류로 인터넷 연결이 남아 있었습니다. Claude는 기본적인 인증·접근통제의 허점을 통해 외부 조직의 운영 시스템에 접근했습니다.
두 사건의 원인은 달랐습니다.
- OpenAI 사례 — AI 에이전트가 내부 캐시 프록시의 제로데이 취약점을 이용해 의도된 격리 경계를 우회하고 외부 연결 경로를 확보했습니다.
- Anthropic 사례 — 격리 경계가 실제 환경에 구현되지 않은 상태에서 Claude가 외부 시스템을 시험용 표적으로 잘못 판단했습니다.
그러나 두 사건 모두 평가 목표를 수행하는 과정에서 에이전트의 행동이 의도한 경계를 넘어 실제 외부 시스템 침해로 이어졌다는 점에서는 같았습니다.
생성형 AI의 위험은 흔히 환각이나 부정확한 답변으로 설명됩니다. 그러나 외부 시스템과 연결된 AI 에이전트의 통제 실패는 잘못된 답변에서 끝나지 않습니다. 잘못된 판단이 데이터 조회와 외부 전송, API 호출, 권한 사용, 시스템 변경 같은 실제 행동으로 이어질 수 있습니다. AI가 답변을 생성하는 도구에서 조직을 대신해 행동하는 주체로 바뀌면서, 통제 실패가 초래하는 피해의 성격도 달라진 것입니다.
그렇다면 안전·신뢰가 핵심인 금융·공공기관은 무엇을 확인한 뒤 AI 에이전트를 업무에 도입하고, 고객정보 조회나 업무 시스템 변경, 외부 API 호출을 맡길 수 있는지가 문제입니다. 이제 질문은 “이 모델은 정확하고 안전하게 답하는가”를 넘어, “이 에이전트에게 어떤 업무를, 어떤 조건에서, 어디까지 맡길 수 있는가”로 바뀌어야 합니다.
1. 업무를 맡겼다고 모든 행위를 승인한 것은 아닙니다
AI 에이전트를 도입한다는 것은 단순히 새로운 소프트웨어를 추가하는 일이 아닙니다. 조직을 대신해 실제 시스템에서 행동할 실행 주체에게 업무와 권한의 일부를 맡기는 결정입니다. 에이전트는 주어진 목표를 여러 단계로 나누고, 부여된 권한 안에서 필요한 데이터와 도구를 선택해 연속적으로 실행합니다.
조직은 이러한 위임 문제를 처음 겪는 것이 아닙니다. 사람에게 업무를 맡길 때는 담당자가 사용할 수 있는 시스템과 정보, 스스로 처리할 수 있는 업무와 금액의 범위를 정합니다. 그 범위를 넘거나 위험이 큰 행위는 누구의 승인을 받아야 하는지도 정합니다. 그런데 이러한 승인체계는 사람이 처리하는 업무 단위를 전제로 만들어졌습니다. 에이전트는 그 단위대로 실행하지 않습니다.
에이전트에게 “고객 문의를 처리하라”고 지시했다고 가정해 보겠습니다. 조직의 승인 체계에서는 한 건의 업무로 보이지만, 에이전트는 이를 고객정보 조회, 내부 자료 검색, 외부 서비스 호출, 답변 전송으로 나누어 실행합니다. 각 행위는 민감정보 접근, 내부정보의 목적 외 사용, 외부 전송, 대외 발신처럼 서로 다른 위험과 승인 조건을 수반합니다.
여기서 도입기관이 답해야 할 질문은 다음과 같습니다.
- 에이전트에게 어떤 업무를 맡길 것인가.
- 업무 수행에 필요한 데이터와 도구의 권한을 어디까지 부여할 것인가.
- 고객정보 외부 전송·계정 권한 변경·자금 이체처럼 별도 승인이 필요한 고위험 행위를 무엇으로 정할 것인가.
- 각 고위험 행위는 누구의 승인을 받게 할 것인가.
- 상위 업무에 대한 한 번의 승인은 그 아래의 연쇄 실행에 어디까지 유효한 것으로 볼 것인가.
문제는 권한과 승인 기준을 문서로 정했다고 해서 실행 단계에서 자동으로 지켜지는 것은 아니라는 점입니다. 승인의 범위가 넓어지거나, 승인과 실제 행위의 연결이 끊어지는 순간, 통제는 실행 과정에서 무너질 수 있습니다.
2. AI 에이전트의 통제는 두 지점에서 무너집니다
통제는 에이전트가 명백히 잘못된 답을 생성하거나 의도된 경계를 벗어날 때만 무너지지 않습니다. 정상적인 업무 목표를 부여된 권한 안에서 수행하는 과정에서도 무너집니다. 에이전트는 목표를 달성하기 위해 필요한 데이터와 도구를 선택하고 실행 경로를 스스로 구성합니다. 이 과정에서 처음 업무를 승인할 때 예상하지 않았던 대상이나 고위험 행위가 새롭게 나타날 수 있습니다.
이런 경로는 특정 제품이나 모델에 국한되지 않고, 공격이 있어야만 나타나는 것도 아닙니다. 에이전트가 상위 목표를 넓게 해석해 지시받지 않은 행위를 스스로 선택하기도 하고, 외부 문서나 검색 결과에 삽입된 지시가 그 선택을 의도적으로 유도하기도 합니다. 두 경우 모두 이미 공개된 취약점 유형으로 정리돼 있습니다.
문제는 이러한 행위가 생성될 수 있다는 사실에서 끝나지 않습니다. 상위 업무의 승인이 새롭게 생성된 고위험 행위까지 덮는 순간 첫 번째 통제가 무너집니다. 그 행위에 대한 판정이 실제 실행을 멈추지 못하는 순간 두 번째 통제가 무너집니다.
첫 번째 지점 — 상위 업무의 승인이 개별 고위험 행위까지 확대됩니다
에이전트의 실행 경로는 다음과 같이 전개될 수 있습니다.
- 고객 요청 처리
- 외부 문서 확인
- 숨겨진 지시를 사용자 요청으로 오인
- 원래 업무에 없던 상태 변경 도구 선택
- 자금 이체·연락처 변경 도구 호출 생성
고객 요청을 처리하라는 지시는 필요한 자료를 확인하고 답변을 제공하라는 범위의 승인입니다. 그 과정에서 특정 계좌로 자금을 이체하거나 고객의 연락처를 변경하는 행위까지 승인한 것은 아닙니다.
이 경로에서 에이전트는 기술적으로 허용되지 않은 도구를 사용하지 않습니다. 타인의 계좌에 접근하거나 새로운 권한을 획득하는 것이 아니라, 인증된 사용자에게 정상적으로 허용된 이체와 정보 변경 기능을 사용합니다. 그러나 사용자가 직접 요청하지 않은 이체와 정보 변경에 그 권한을 사용합니다. 권한 범위 안에서 행동했지만 승인 범위는 벗어난 것입니다.
따라서 사용할 수 있는 도구를 제한하는 것만으로는 충분하지 않습니다. IAM과 서비스 계정은 그 계정이 해당 도구를 호출할 수 있는지만 확인하고, 지금 이 업무를 위해 그 호출이 필요한지는 판단하지 않습니다. 실행 직전에 호출의 목적과 대상, 인자를 확인하고, 기존 승인이 그 구체적인 행위까지 포함하는지 판단해야 합니다. 고위험 행위의 승인은 상위 목표의 승인과 분리돼야 하고, 권한 검증은 모델의 판단이 아니라 그 아래의 집행 시스템에서 이루어져야 합니다.
두 번째 지점 — 판정·승인·실행의 연결이 끊깁니다
실제 도입 환경에서 이 경로는 하나의 시스템 안에 있지 않습니다. 요청은 에이전트 플랫폼에서 생성되고, 위험 판정은 가드레일에서, 사람 승인은 업무 시스템에서, 실제 호출은 API 게이트웨이에서 이루어집니다.
그래서 고위험 호출을 정확히 찾아내는 것만으로는 통제가 완성되지 않습니다. 차단이나 승인 필요 판정이 실제 실행 경로에 반영되지 않으면, 에이전트가 생성한 호출은 그대로 수행될 수 있습니다.
- 고위험 호출 생성
- 차단 또는 사람 승인 필요 판정
- 판정 결과가 실행 경로에 반영되지 않음
- API 호출 수행
티냅스의 도구 호출 통제 계층은 한 응답에 함께 담긴 자연어 답변과 도구 호출을 각각 판정합니다. 답변이 적절해도 같은 응답의 호출은 따로 판정하고, 둘 중 하나라도 허용할 수 없으면 실행을 차단하도록 설계돼 있습니다.
도구 호출의 이름과 인자는 실행 직전에 정책과 대조해 허용·차단을 결정합니다. 이 판정에는 모델이 개입하지 않습니다. 조작된 모델이 판정을 바꿀 수 없고, 그 결과가 실행 경로에 연결돼 허용되지 않은 호출은 수행되지 않습니다.
판정과 실행은 기록에서도 하나의 흐름으로 이어져야 합니다. 에이전트는 같은 입력에서도 다른 실행 경로를 만들 수 있습니다. 제안된 도구와 인자, 적용된 정책, 사람의 승인, 실제 실행 결과와 중단·복구가 서로 다른 곳에 남으면 무엇이 왜 허용됐고 실제로 어디까지 실행됐는지 확인하기 어렵습니다. 티냅스는 같은 실행 과정에서 여러 판정이 발생하더라도 각각의 기록을 남기고, 이를 연결해 하나의 사건으로 재구성할 수 있도록 하고 있습니다.
결국 승인 범위와 강제의 문제입니다
첫 번째 지점은 에이전트의 업무 승인 범위에 관한 문제이고, 두 번째 지점은 그 승인과 판정이 실제 실행에 강제되는가의 문제입니다. 개별 행위가 별도 승인 없이 실행되고, 그 실행이 어떤 판정과 승인에 근거했는지 연결되지 않을 때 에이전트 통제는 무너집니다. 그렇다면 도입기관은 AI 에이전트의 도입 전에 어떤 통제를 마련하고, 그 통제가 실제로 작동하는지 어떻게 검증해야 하는지 살펴보겠습니다.
3. AI 에이전트의 신뢰는 두 가지 근거로 판단합니다
안전·신뢰가 핵심인 기관이 AI 에이전트의 도입을 승인할 때 판단의 근거는 두 가지입니다. 조직이 정한 통제가 에이전트의 개별 행위까지 연결돼 있는가, 그리고 그 연결이 실제 실행에서 작동한다는 증거가 있는가입니다.
첫 번째 근거 — 기존 통제가 개별 행위까지 연결돼야 합니다
에이전트를 신뢰할 수 있다는 판단은 모델이 항상 옳다는 증명에서 나오지 않습니다. 조직이 이미 정해 둔 권한과 승인 기준에서 나옵니다.
도입기관은 이미 통제 수단을 갖고 있습니다.
- IAM과 서비스 계정
- 전결 규정과 승인권자
- API 게이트웨이·DLP·네트워크 통제
- 사고 대응과 중단·복구 절차
문제는 이 수단들이 에이전트가 실행 과정에서 만들어 내는 개별 행위의 목적과 맥락까지 판단하도록 설계된 것은 아니라는 점입니다.
그래서 필요한 것은 또 하나의 통제가 아니라, 기존 기준을 에이전트의 개별 행위에 연결하는 지점입니다. 요청과 맥락, 에이전트가 제안한 행위의 위험을 실행 시점에 판정하고, 그 결과를 허용·수정·차단 또는 사람의 승인 요청으로 연결하며, 판정·승인·실행의 관계를 하나의 기록으로 남기는 지점입니다. 이 글에서 말하는 AI Trust Layer가 여기에 해당합니다. 기존 IAM과 보안통제를 대체하는 것이 아니라, 기존 통제의 권한·승인 기준을 에이전트의 개별 행위에 연결하는 실행 계층입니다.
다만 무엇을 중요 행위로 볼 것인지, 어떤 증적을 최소한으로 남길 것인지, 공급자와 도입기관이 책임을 어떻게 나눌 것인지, 권한의 위임·재위임·회수를 어떤 기준으로 할 것인지는 기술이 정해 주지 않습니다. 이러한 기준과 책임 분담은 기관의 전결·권한 규정에 반영되고, 실행 시점의 판정과 집행을 통해 개별 행위에 강제돼야 합니다. 그리고 모든 행위를 차단하거나 승인받게 하는 것이 아니라, 피해 규모·민감도·되돌릴 수 있는 정도에 비례해 통제 수준을 정해야 합니다.
두 번째 근거 — 통제가 실제 실행에서 작동해야 합니다
도입 심사는 대개 기능의 유무를 묻습니다. 그러나 신뢰의 근거는 기능이 있다는 사실이 아니라, 그 기능이 실제 실행을 통제하고 그 결과를 설명·복구할 수 있다는 확인입니다. 확인해야 할 것은 다섯 가지입니다.
- 중요 행위가 승인 전에 실행되지 않는지
- 입력과 실행 경로가 달라져도 위반 행위가 차단되는지
- 하나의 통제가 실패해도 다음 통제가 피해를 제한하는지
- 요청부터 복구까지의 흐름을 재구성할 수 있는지
- 실행을 중단한 뒤 변경된 상태를 복원하거나 보상할 수 있는지
확인은 문서 검토만으로 끝나서는 안 되고, 실제 시험으로 이어져야 합니다. 허용되지 않은 도구 호출, 권한 범위를 벗어난 파라미터, 민감정보의 외부 전송, 사람 승인 우회, 허용되지 않은 권한 재위임, 그리고 실행 중 권한 철회와 복구를 시험해야 합니다.
이 시험은 세 묶음의 증적을 남겨야 합니다.
- 실행 전 — 요청·실행 주체와 위임 관계, 모델·정책·도구의 버전, 부여된 권한
- 실행 중 — 위험 판정과 승인자, 실제 호출된 도구와 파라미터
- 실행 후 — 상태 변경과 차단·중단·복구의 결과
산업 공통의 기준이 정리되기를 기다리기보다, 각 기관이 허용할 위험 수준과 최소 승인·통제·증적 기준을 먼저 정해야 합니다.
실패하지 않는 에이전트보다 통제 가능한 에이전트가 필요합니다
신뢰할 수 있는 에이전트는 실패하지 않는 에이전트가 아니라, 실패해도 통제와 복구가 가능한 에이전트입니다. 그 차이를 만드는 것은 모델의 성능이 아니라, 그 모델을 실행시키는 통제 구조입니다. 어디까지 맡길 수 있는가. 그 답은 에이전트가 아니라, 그것을 멈출 수 있는 구조가 정합니다.
티냅스의 AI Trust Layer는 AI 에이전트의 입력과 출력, 도구 호출을 실시간으로 검증해 정책과 승인 기준에 따라 허용·수정·차단하거나 사람의 승인을 요청하고, 그 판정과 승인, 실제 실행 결과를 연결된 기록으로 남겨 도입 전 통제 설계부터 운영 중 검증, 사후 감사와 책임 추적까지 안전한 AI 도입을 지원합니다. 도입 심사를 앞두고 계시거나 아직 기준을 정하는 단계라면 티냅스에 문의해 주세요.
