생성형 AI가 기업 업무에 도입되기 시작했을 때 주요 관심사는 얼마나 정확한 답변을 생성하는가에 있었습니다. 따라서 기업의 데이터와 업무 맥락을 활용해 답변의 정확도를 높이는 동시에, 민감한 정보가 외부로 노출되지 않도록 관리하는 것이 중요한 보안 과제였습니다. 하지만 AI가 질문에 답하는 도구에서 직접 업무를 수행하는 에이전트로 발전하면서 보안에서 고려해야 할 범위도 달라지고 있습니다.
AI 에이전트는 이메일과 문서를 읽고 필요한 정보를 찾는 데서 그치지 않고, 연결된 도구와 권한을 이용해 메일을 발송하거나 파일과 데이터를 수정하고, API를 호출하거나 코드를 실행합니다. 에이전트가 더 많은 일을 할수록 실수나 공격이 실제 업무에 미치는 영향 역시 커집니다. 신뢰할 수 없는 이메일이나 문서에 포함된 명령이 에이전트의 행동에 영향을 미치는 간접 프롬프트 인젝션 역시 이러한 환경에서 고려해야 할 보안 위협입니다.
때문에 기업의 AI 보안 시작점은 AI가 어떤 데이터에 접근할 수 있는지, 어떤 도구를 사용할 수 있는지, 어디까지 스스로 실행할 수 있는지, 그리고 문제가 발생했을 때 그 행동을 추적하고 중단할 수 있는지까지 함께 관리하는 방향으로 확장 되어야 합니다.
이번 글에서는 AI 에이전트가 어떤 경로로 사고를 일으킬 수 있는지 살펴보고, 업무의 위험 수준에 따라 에이전트의 권한과 실행 범위를 정하는 기준, 그리고 실제 운영 과정에서 필요한 통제 방법을 정리해 보겠습니다.
답변에서 실행으로, AI 에이전트의 변화
1) AI 에이전트가 기존 챗봇과 다른 점
일반적인 챗봇은 사용자의 질문에 답변을 생성하고, 실제 행동은 사용자가 결과를 확인한 뒤 직접 수행합니다. 반면에 AI 에이전트는 주어진 목표를 여러 단계로 나누고 필요한 도구와 데이터를 선택해 작업을 이어갑니다. 이메일 발송, 파일 수정, API 호출, 코드 실행처럼 시스템 상태를 바꾸는 행동도 수행할 수 있습니다.
이 차이는 오류가 미치는 범위를 바꿉니다. 챗봇의 부정확한 답변은 다시 확인하고 수정할 수 있지만, 에이전트가 잘못된 대상에게 메일을 보내거나 운영 데이터를 변경하면 실제 업무에 바로 영향을 줍니다. 따라서 AI 에이전트 보안은 답변의 정확성과 함께 행동의 범위와 실행 권한을 다뤄야 합니다.
2) 승인된 AI도 위험할 수 있는 이유
기업이 검토한 모델을 사용해도 연결된 도구와 권한까지 자동으로 안전해지지는 않습니다. 에이전트에 넓은 권한이 부여돼 있거나 외부 콘텐츠에 숨은 명령을 구분하지 못하면, 정상적인 업무 과정에서도 의도하지 않은 행동이 실행될 수 있습니다.
Microsoft는 2026년 5월 AI 에이전트 개발 프레임워크인 Semantic Kernel에서 프롬프트 공격이 연결된 도구를 거쳐 호스트 환경의 코드 실행으로 이어질 수 있는 취약점을 공개했습니다. 현재 취약점은 수정됐지만, 이 사례는 AI가 도구와 연결되는 순간 입력 내용의 문제가 실제 시스템 행동으로 확대될 수 있음을 보여줍니다.
AI 에이전트가 사고를 만드는 두 가지 경로
1) 모델의 실수와 외부 공격
AI 에이전트의 사고는 크게 에이전트가 정상적인 지시를 잘못 처리하는 경우와, 외부에서 들어온 악성 명령에 영향을 받는 경우로 나눌 수 있습니다. 발생 원인은 다르지만, 넓은 권한을 가진 에이전트가 실제 도구를 실행할 때 피해가 커진다는 공통점이 있습니다.
2) 에이전트가 지시를 잘못 해석하는 경우
업무 지시가 모호하면 에이전트가 목표를 필요 이상으로 넓게 해석하거나 잘못된 대상을 선택할 수 있습니다. 여러 단계를 수행하는 동안 처음에 주어진 제한을 놓치고 같은 행동을 반복하는 상황도 발생합니다. 공격자가 개입하지 않아도 불분명한 지시와 넓은 실행 권한의 조합만으로 사고가 생길 수 있습니다.
3) 외부 콘텐츠가 에이전트를 조종하는 경우
간접 프롬프트 인젝션은 이메일, 문서, 웹페이지, 소스 코드처럼 에이전트가 읽는 자료 안에 악성 명령을 숨기는 공격입니다. 사용자는 단순히 문서를 요약하라고 요청했지만, 에이전트는 문서 속 명령을 사용자의 지시로 받아들여 다른 도구를 실행할 수 있습니다.
현재의 AI 모델은 신뢰할 수 있는 지시와 외부에서 가져온 내용을 항상 정확하게 구분하지 못합니다. 입력 단계에서 악성 명령을 탐지하는 기술이 필요하지만, 탐지를 통과한 공격까지 고려해 에이전트가 사용할 수 있는 도구와 권한 자체를 제한하는 방어가 함께 적용돼야 합니다.
4) AI는 누구의 권한으로 일하는가
에이전트가 직원의 계정이나 여러 시스템에서 공유하는 인증 정보를 그대로 사용하면, 어떤 행동을 사람이 수행했고 어떤 행동을 AI가 수행했는지 구분하기 힘들어집니다. 문제가 발생했을 때 담당자와 책임 범위를 확인하거나 특정 에이전트의 권한만 빠르게 회수하는 데도 한계가 생깁니다.
기업은 에이전트마다 구분 가능한 신원과 운영 책임자를 지정하고, 맡은 업무에 필요한 권한만 연결해야 합니다. 프로젝트가 끝나거나 담당자가 바뀌면 사용하지 않는 권한과 인증 정보가 함께 회수되도록 전체 수명주기도 관리할 필요가 있습니다.
5) 최종 답변만으로는 부족한 활동 기록
AI 에이전트가 남긴 최종 답변만 저장하면 실제 실행 과정은 보이지 않습니다. 사고를 조사하려면 어떤 계정을 사용했는지, 어떤 도구와 데이터를 선택했는지, 어떤 권한으로 요청을 보냈는지, 실행이 성공했는지까지 확인할 수 있어야 합니다.
Microsoft도 에이전트의 응답만 기록하고 도구 호출과 권한 범위, 시스템별 승인 판단을 남기지 않으면 사고 원인을 재구성하기 힘들다고 설명합니다. 질문과 답변, 도구 호출, 권한 확인, 실행 결과를 연결한 기록이 필요한 이유입니다.
AI 에이전트의 권한을 정하는 3 가지 기준
에이전트의 권한을 일괄적으로 허용하거나 차단하면 업무별 위험 차이를 반영하기 힘듭니다. 같은 에이전트라도 문서를 읽는 작업과 외부로 메일을 보내는 작업에는 서로 다른 통제 수준이 필요합니다. 권한을 설계할 때는 다음 세 가지 기준을 먼저 확인할 수 있습니다.
되돌릴 수 있는가
검색과 초안 작성은 결과가 잘못돼도 다시 생성할 수 있습니다. 반면 외부 발송, 결제 승인, 데이터 삭제, 운영 환경 배포는 실행 이후 완전히 되돌리기 힘들거나 복구에 큰 비용이 듭니다. 되돌리기 어려운 행동일수록 실행 전에 사람의 확인을 거치고, 대상과 범위를 다시 표시해야 합니다.
잘못됐을 때 피해 범위가 얼마나 큰가
같은 수정 작업이라도 개인의 임시 문서를 바꾸는 것과 여러 부서가 사용하는 운영 데이터베이스를 변경하는 것은 영향이 다릅니다. 접근 대상과 사용자 수, 외부 고객에게 미치는 영향, 금전적 손실 가능성을 기준으로 권한을 세분화해야 합니다. 피해 범위가 큰 행동에는 더 좁은 권한과 강한 승인 절차가 필요합니다.
신뢰할 수 없는 입력을 다루는가
외부 이메일과 웹페이지, 업로드된 문서는 출처를 확인하기 힘든 명령을 포함할 수 있습니다. Meta의 Agents Rule of Two는 프롬프트 공격의 피해를 줄이기 위해 한 세션에서 다음 세 가지 특성 가운데 최대 두 가지만 허용하도록 권고합니다.
① 신뢰할 수 없는 외부 입력 처리
② 민감한 시스템이나 사내 데이터 접근
③ 시스템 상태를 바꾸거나 외부와 통신
세 가지가 모두 필요한 작업은 에이전트가 완전히 자율적으로 실행하지 않도록 사람의 승인이나 별도의 검증을 적용해야 합니다. 이 원칙만으로 모든 위험이 해결되지는 않지만, 외부 입력에서 민감 데이터 접근과 실제 행동까지 이어지는 공격 경로를 끊는 기준으로 활용할 수 있습니다.
실행 전부터 사고 이후까지 이어지는 다층 통제
하나의 보안 장치가 모든 실수와 공격을 막아주지는 못합니다. 실행 전에는 에이전트가 변경할 대상과 사용할 도구를 확인하고, 실행 중에는 허용된 데이터와 시스템 안에서만 작업하도록 제한해야 합니다. 작업이 끝난 뒤에는 도구 호출과 권한 사용, 변경 결과를 기록해 문제가 발생했을 때 전체 과정을 확인할 수 있어야 합니다.
1) 실행 전과 실행 단계: 계획 확인과 권한 제한
영향이 큰 작업은 에이전트가 세운 실행 계획과 변경 대상, 사용할 도구를 먼저 보여주도록 설정해야 합니다. 지시가 모호하거나 대상이 정확하지 않을 때는 에이전트가 임의로 실행하지 않고, 작업을 멈춘 뒤 추가 정보를 요청하도록 하는 방식이 안전합니다.
실행 단계에서는 업무에 필요한 데이터와 도구만 연결하고, 읽기 권한과 수정 권한을 구분해야 합니다. 추가 권한이 필요한 경우에는 정해진 작업 시간에만 일시적으로 제공하고, 이후 자동으로 만료되도록 설정할 수 있습니다. 외부 발송이나 데이터 삭제, 운영 환경 변경처럼 되돌리기 어려운 작업에는 사람의 승인을 적용해야 합니다.
코드 실행과 외부 통신은 허용된 범위 안에서만 이루어지도록 제한하고, 이상 행동이 감지되면 작업을 자동으로 중단할 수 있어야 합니다.
2) 실행 후: 기록과 복구
에이전트의 전체 활동을 시간 순서대로 남기고, 정책 위반이나 반복 실행과 같은 이상 징후를 확인해야 합니다. 변경 가능한 작업에는 이전 상태로 되돌리는 절차를 마련하고, 계정 중지와 인증 정보 교체, 권한 회수도 실제 사고 대응처럼 정기적으로 점검할 필요가 있습니다.
이러한 통제를 조직의 정책만으로 일관되게 적용하기에는 한계가 있어, AI의 작업 범위와 결과를 기술적으로 관리하고 검증하는 도구도 함께 필요합니다. 개발 환경에서는 CodeCenter를 활용해 AI의 작업 범위와 변경 이력을 관리하고, Code Intelligence의 자동화된 보안 테스트로 AI가 생성하거나 수정한 코드의 결함과 보안 취약점을 확인해 개발 과정의 안전성과 효율성을 높일 수 있습니다.
사람의 승인이 실제 통제로 작동하려면
1) 승인 횟수보다 중요한 승인 시점
모든 행동마다 승인을 요구하면 사용자는 반복되는 알림에 익숙해져 내용을 충분히 확인하지 않고 승인할 수 있습니다. 형식적인 승인 절차가 늘어날수록 중요한 위험 신호가 다른 알림에 묻힐 가능성도 커집니다.
따라서 승인 횟수를 늘리는 것보다 되돌리기 어렵고 피해 범위가 큰 행동에 사람의 판단을 집중해야 합니다. 승인 화면에는 에이전트가 하려는 작업과 대상, 사용 권한, 예상되는 변경 결과를 간결하게 보여줘야 합니다.
2) 배포 이후에도 달라지는 권한과 위험
AI 에이전트의 위험 수준은 처음 배포할 때 정해진 상태로 유지되지 않습니다. 모델이 업데이트되고 새로운 도구와 데이터가 연결되거나 업무 절차가 바뀌면 기존 권한이 필요 이상으로 넓어질 수 있습니다.
기업은 주요 변경 이후 권한을 다시 검토하고, 사용하지 않는 계정과 인증 정보를 정리해야 합니다. 운영 중에는 에이전트별 활동과 정책 위반을 지속적으로 확인하고, 문제가 발생했을 때 신원 중지, 권한 회수, 인증 정보 교체, 작업 복구가 빠르게 이어지도록 대응 절차를 준비해야 합니다.
마무리
AI 에이전트가 맡는 업무는 이메일과 문서 작업을 넘어 개발, 고객 대응, 데이터 처리, 시스템 운영으로 넓어지고 있습니다. 자동화의 성과는 에이전트에게 얼마나 많은 일을 맡겼는지보다, 맡긴 범위 안에서 행동을 확인하고 필요할 때 멈출 수 있는지에 달려 있습니다.
기업은 에이전트마다 신원과 책임자를 지정하고, 필요한 데이터와 도구만 사용할 수 있도록 권한을 나눠야 합니다. 외부 입력을 다루는 작업에는 더 강한 제한을 적용하고, 되돌리기 어려운 행동은 실행 전에 사람이 확인해야 합니다. 여기에 도구 호출과 권한 판단, 실행 결과를 연결한 활동 기록이 더해져야 사고 발생 시 원인을 빠르게 파악할 수 있습니다.
기업의 신뢰는 AI가 항상 옳을 것이라는 기대보다, 오류가 발생해도 영향이 정해진 범위 안에서 멈추고 과정을 확인할 수 있는 운영 체계에서 만들어집니다. 이러한 기반이 마련될 때 기업은 보안을 이유로 AI 활용을 늦추지 않고, 통제 가능한 범위에서 자동화를 안정적으로 확장할 수 있습니다.
