AI 에이전트를 도입한 기업의 65%가 에이전트가 의도한 범위 밖의 행동을 한 경험이 있다고 답했습니다. 그런데 같은 조사에서 94%의 IT·보안 책임자는 자사의 에이전트가 필요 이상의 권한을 갖고 있지 않다고 확신했습니다. 이 간극은 권한을 처음 줄 때만 확인해서는 에이전트를 통제하기 어렵다는 사실을 보여줍니다.
사고가 난 뒤 로그를 열어 원인을 찾는 방식으로는 늦습니다. 에이전트가 파일을 읽고, 고객 정보를 조회하고, 메일을 발송하는 바로 그 순간에 해당 행동이 승인된 범위인지 확인해야 합니다. 작은 조직도 비싼 보안 제품부터 도입할 필요는 없습니다. 업무 범위를 좁히고, 읽기와 쓰기를 나누고, 되돌릴 수 없는 행동 앞에 사람의 승인을 두는 것부터 시작할 수 있습니다.
조사에서 확인된 위험은 어느 정도인가
Cequence Security와 Enterprise Management Associates가 2026년 8월 발표한 조사는 직원 1,000명 이상 기업에서 AI 에이전트를 도입하거나 검토하는 IT·보안 책임자 202명을 대상으로 했습니다. 응답자의 94%는 에이전트 권한이 과도하지 않다고 확신했지만, 최소 권한을 실제 적용한 조직은 33%였습니다.
응답 기업의 65%는 에이전트가 의도한 범위를 벗어난 행동을 경험했습니다. 전체의 29%는 데이터 노출, 금전 손실, 운영 중단, 평판 훼손처럼 측정 가능한 영향으로 이어졌고, 36%는 피해 직전에 막은 사례를 보고했습니다. 특정 기업군을 대상으로 한 공급업체 의뢰 조사이므로 모든 조직의 사고율로 일반화할 수는 없습니다. 다만 에이전트에 대한 확신과 실제 통제 사이의 차이를 점검할 근거로는 유효합니다.
| 확인 항목 | 조사 결과 | 실무에서 읽을 의미 |
|---|---|---|
| 권한이 과도하지 않다는 확신 | 94% | 정책이 있다는 사실과 실행 통제는 다름 |
| 최소 권한 실제 적용 | 33% | 다수는 넓은 상시 권한을 유지 |
| 범위 밖 행동 경험 | 65% | 의도와 실제 행동 사이에 간극이 존재 |
| 행동 순간에 권한 검증 | 34% | 사전 부여보다 실행 시점 검증이 부족 |
| 중단·폐기된 에이전트 파일럿 | 31% | 사용하지 않는 자격 증명 회수도 필요 |
권한을 줬는데도 왜 사고가 생기나
첫째, 기존 권한 체계는 사람의 판단과 주저함을 전제로 만들어졌습니다. 사람에게 파일 접근 권한이 있다고 해서 매번 모든 파일을 열지는 않습니다. 이상한 상황에서는 멈추고 묻기도 합니다. 그러나 에이전트는 접근 가능한 도구를 작업 수행 수단으로 해석할 수 있습니다. 따라서 에이전트의 권한은 단순한 상한선이 아니라 실제 행동 가능성으로 봐야 합니다.
둘째, 인증 토큰은 한 번 발급되면 여러 작업에서 계속 쓰일 수 있습니다. 조사에서 특정 행동을 시도하는 순간에 권한을 다시 평가하는 조직은 34%였습니다. 처음 연결할 때는 필요한 권한이었더라도 업무가 끝나거나 역할이 바뀐 뒤에는 불필요할 수 있습니다. 중단된 파일럿의 자격 증명을 회수하는 절차까지 운영 규칙에 포함해야 하는 이유입니다.
셋째, 개별 행동은 정상이어도 행동의 연결이 사고를 만들 수 있습니다. 고객 데이터 조회와 메일 발송이 각각 허용됐더라도, 조회한 내용을 승인되지 않은 외부 주소로 보내면 데이터 유출이 됩니다. JetStream Security가 공개한 제품 설명도 개별 도구 호출뿐 아니라 행동의 순서를 실행 전에 평가해야 한다는 점을 강조합니다. 이는 해당 업체가 제시한 설계 접근이며, 모든 환경에서 효과가 검증됐다는 뜻은 아닙니다.
좁은 스코프가 왜 보안과 성능을 함께 높이나
좁은 스코프는 에이전트 하나에 하나의 과업, 필요한 데이터, 명확한 산출물만 부여하는 방식입니다. “고객 문의를 처리하라”는 넓은 지시에는 문의 분류, 이력 조회, 답변 작성, 환불 판단, 외부 발송이 한꺼번에 들어갑니다. 결과가 잘못되면 어느 단계에서 오류가 생겼는지 찾기 어렵고, 에이전트에는 조회·수정·발송 권한이 모두 필요해집니다.
반대로 “문의를 다섯 유형으로 분류하라”처럼 범위를 좁히면 필요한 데이터와 권한이 줄어듭니다. 오류가 나도 분류 기준만 확인하면 되고, 결과 표본을 뽑아 정확도를 측정할 수 있습니다. 좁은 스코프는 단순한 보안 제한이 아니라 틀린 지점을 찾아 개선을 축적하기 위한 조건입니다.
| 구분 | 넓은 스코프 | 좁은 스코프 |
|---|---|---|
| 과업 | 고객 문의 전체 처리 | 문의 유형 분류 |
| 권한 | 조회·수정·발송 | 필요한 데이터 조회 |
| 오류 확인 | 최종 결과 전체를 재검토 | 분류 기준과 표본을 점검 |
| 개선 | 프롬프트와 흐름 전체 수정 | 오류가 난 단계만 수정 |
| 재사용 | 특정 업무에 종속 | 다른 흐름의 분류 단계로 재사용 |
작은 조직은 어떤 통제부터 만들 수 있나
첫 번째는 읽기와 쓰기를 분리하는 것입니다. 조사·요약·분류 업무에는 읽기 전용 계정을 연결합니다. 삭제, 발송, 결제, 게시 권한이 붙은 계정을 조사용 자동화에 함께 사용하지 않습니다. 같은 서비스 안에서도 조회 도구와 변경 도구를 나누는 편이 안전합니다.
두 번째는 되돌릴 수 있는 행동과 없는 행동을 구분하는 것입니다. 초안 저장과 임시 분류는 되돌릴 수 있지만 메일 발송, 결제, 파일 삭제, 외부 공유는 완전히 되돌리기 어렵습니다. 되돌리기 어려운 행동은 흐름의 마지막에 두고 사람의 명시적 승인을 통과하게 합니다.
세 번째는 외부로 나가는 경로를 한곳으로 모으는 것입니다. 여러 자동화가 각자 메일과 외부 API 전송 권한을 가지면 통제 지점도 흩어집니다. 수신자나 대상 시스템이 승인 목록 밖이면 멈추도록 하고, 발신 기록을 한곳에서 확인할 수 있어야 합니다.
네 번째는 확인할 로그를 미리 정하는 것입니다. 로그를 많이 남기는 것보다 어떤 이상이 어느 기록에 나타나는지 정하는 편이 중요합니다. 자동화마다 실패 신호, 중단 기준, 최종 책임자를 한 줄씩 적어두면 사고 대응 시간이 짧아집니다. 에이전트에 역할·권한·담당자를 붙이는 구조는 BNY의 디지털 직원 운영 사례에서도 확인할 수 있습니다.
도입 전에 무엇을 확인해야 하나
- 에이전트의 과업을 한 문장으로 설명할 수 있는가
- 그 과업에 필요하지 않은 읽기·쓰기 권한이 연결돼 있지 않은가
- 발송·결제·삭제·외부 공유 전에 사람의 승인이 있는가
- 업무가 끝난 에이전트와 중단된 파일럿의 자격 증명을 회수하는가
- 범위 밖 행동을 발견했을 때 자동으로 멈출 조건이 있는가
- 결과에 최종 책임을 지는 사람이 정해져 있는가
AI 에이전트의 사고를 줄이는 핵심은 더 많은 로그를 쌓는 데 있지 않습니다. 작게 맡기고, 적게 열어주고, 실행 직전에 다시 확인하는 것입니다. 모델과 도구는 바뀌어도 이 운영 기준은 다음 자동화에 재사용할 수 있습니다. 작은 조직이 먼저 축적해야 할 자산도 바로 이 경계와 통제의 기준입니다.
