AI 에이전트 보안, 권한·승인·감사를 분리해야 하는 이유

 

AI가 위험해지는 순간은 답변을 넘어 시스템을 움직일 때입니다

AI 에이전트가 웹을 검색하고, 내부 문서를 읽고, 프로그램을 실행하며, 외부 서비스에 요청을 보내는 기능은 업무 자동화의 폭을 넓힙니다. 동시에 잘못된 명령·악성 콘텐츠·설정 오류가 실제 시스템의 권한과 만나면 위험도 커집니다. 최근 보도는 인터넷에 접근 가능한 평가 환경에서 AI 모델의 예기치 않은 행동이 관찰된 여러 사례를 다뤘습니다. 사례마다 격리 환경의 취약점, 테스트 설정, 제3자 구성 문제가 달라 기술적 사실관계를 하나로 묶어 단정할 수는 없습니다.

그렇지만 운영 원칙은 사건별로 적용할 수 있습니다. AI가 사용할 수 있는 도구를 최소화하고, 비밀값을 안전하게 다루며, 돌이키기 어려운 행동은 실행 전에 승인받고, 모든 행동을 나중에 추적할 수 있게 해야 합니다. 모델의 출력 필터만 강화하는 방식으로는 도구 호출과 계정 권한에서 발생하는 위험을 충분히 관리하기 어렵습니다.

사건의 원인을 구분하지 않으면 엉뚱한 통제를 강화하게 됩니다

AI 보안 이슈를 논의할 때는 모델의 행동, 평가 환경의 설정, 연결된 도구의 권한을 나눠 살펴야 합니다. 인터넷 접근이 발생한 이유가 샌드박스 탈출인지, 시험자가 의도적으로 접근을 허용한 것인지, 외부 테스트 시스템의 설정 실수인지에 따라 재발 방지책은 달라집니다. 모두를 ‘모델 통제 실패’로 부르면 네트워크 분리나 비밀관리 같은 운영 결함을 놓칠 수 있습니다.

보도는 여러 조직이 유사한 위험 신호를 공개했다는 점에서 의미가 있지만, 발생한 행동이 실제 공격 성공이나 데이터 피해로 이어졌는지까지 자동으로 뜻하지는 않습니다. 따라서 조직의 대응도 공포에 기반한 전면 차단보다 사용 중인 에이전트의 연결 관계를 정확히 파악하는 데서 시작해야 합니다. 누가 어떤 모델을 쓰는지보다, 그 모델이 어떤 도구와 데이터·계정에 닿는지가 먼저입니다.

권한은 에이전트가 아니라 작업 흐름에 맞춰 잘게 나눠야 합니다

AI에 ‘업무를 하라’는 넓은 권한을 부여하면, 문서 요약·검색처럼 안전한 업무와 운영 데이터 변경·외부 전송처럼 위험한 업무가 같은 계정 아래 섞일 수 있습니다. 프롬프트 인젝션은 웹페이지나 문서에 포함된 지시가 에이전트의 행동을 바꾸도록 유도하는 공격 방식입니다. 이때 에이전트가 강한 쓰기 권한을 갖고 있다면 단순한 정보 오염이 실제 변경 작업으로 이어질 수 있습니다.

대응은 도구의 목록을 작성한 뒤 읽기·쓰기·삭제·외부 전송·배포 권한을 나누는 것입니다. 개발 환경과 운영 환경도 분리하고, 데이터 조회용 에이전트가 관리 콘솔이나 결제 시스템을 호출하지 못하게 해야 합니다. 필요한 경우에도 허용된 도메인·API·명령 형식만 통과시키는 중개 계층을 두면 모델의 자유로운 도구 선택 범위를 줄일 수 있습니다. 이것은 AI 기능을 없애는 방식이 아니라, 업무 목적을 벗어난 행동이 곧바로 실행되지 않게 하는 설계입니다.

자격증명은 노출을 전제로 줄이고 바꾸는 구조가 필요합니다

에이전트에는 데이터베이스, 저장소, 고객관리 시스템, 클라우드 플랫폼을 연결하는 토큰이 필요할 수 있습니다. 그러나 장기 관리자 키를 프롬프트나 구성 파일, 개발용 환경변수에 넣어두면 로그·백업·오류 출력·외부 도구 결과를 통해 노출될 수 있습니다. 한 개의 키가 여러 시스템을 제어한다면 사고 범위도 커집니다.

효과적인 방법은 비밀을 중앙 비밀관리 서비스에 보관하고, 요청한 작업에 필요한 범위만 가진 짧은 수명 토큰을 일시 발급하는 것입니다. 가능하다면 모델이 키 자체를 받지 않고, 권한 검사를 거친 중개 서비스가 작업을 수행하도록 해야 합니다. 토큰 회전과 폐기, 사용량 감시, 비정상 위치·시간대 호출 탐지는 운영 비용이 들지만, 의심 상황에서 접근을 끊고 원인을 확인할 수 있게 만듭니다.

사람 승인은 자동화를 포기하라는 뜻이 아닙니다

AI 에이전트의 모든 호출을 사람이 확인하면 업무 흐름은 느려지고 승인 피로가 생깁니다. 그렇다고 모든 행동을 자동화하면 작은 판단 오류가 대량 이메일 발송, 대규모 데이터 이동, 코드 배포처럼 되돌리기 어려운 결과를 낳을 수 있습니다. 답은 위험 기반의 승인 경계입니다.

읽기 전용 검색, 정해진 형식의 내부 요약, 제한된 테스트 작업은 자동 실행과 모니터링을 조합할 수 있습니다. 반면 고객·직원 정보의 외부 이동, 금전·계약과 관련된 처리, 운영 인프라 변경, 권한 상승, 실제 배포는 실행 전 사람의 확인을 기본값으로 둘 필요가 있습니다. 승인 화면에는 대상, 변경 내용, 전송 데이터, 비용·영향, 복구 방법이 드러나야 합니다. 담당자가 알아들을 수 없는 승인 요청은 실질적 통제가 되기 어렵습니다.

감사 로그는 설명책임과 사고 대응을 동시에 지탱합니다

AI가 도구를 사용한 과정은 사용자 요청부터 최종 결과까지 이어진 기록으로 남아야 합니다. 어떤 입력이 들어왔고, 모델이 어떤 도구를 선택했으며, 권한 확인과 승인이 있었는지, 외부 시스템은 무엇을 반환했는지 연결돼야 합니다. 민감정보를 로그에 복제하지 않는 마스킹 원칙도 함께 필요합니다.

로그를 변조하기 어렵게 보관하고 보안 모니터링과 연동하면, 사고 후 조사뿐 아니라 진행 중인 이상 행동도 감지할 수 있습니다. 평소와 다른 대량 다운로드, 승인 없는 외부 도메인 요청, 비정상 권한 요청, 반복된 실패가 대표적인 경보 대상입니다. 통제는 문서에만 존재해서는 안 되며, 로그를 이용해 정책 위반과 예외 사용을 정기적으로 검토해야 합니다.

AI 안전은 모델만의 문제가 아니라 시스템 설계의 문제입니다

인터넷 연결형 AI의 보안 위험은 한 가지 모델의 성향이나 특정 사건으로만 설명할 수 없습니다. 평가용 샌드박스, 외부 도구, 계정 권한, 비밀 관리, 사람이 개입하는 절차, 모니터링 체계가 함께 작동하는 시스템 문제입니다. 개별 보도 사례의 공격 성공 여부와 기술 원인은 계속 검증해야 하지만, 운영 통제의 필요성은 그와 별개로 점검할 수 있습니다.

핵심 판단 기준은 단순합니다. 해당 에이전트가 필요한 범위를 넘는 권한을 갖고 있는지, 비밀값이 쉽게 노출될 구조인지, 고위험 실행을 멈추고 사람이 판단할 지점이 있는지, 문제가 생겼을 때 행동 경로를 재현할 로그가 있는지를 묻는 것입니다. 통제가 너무 강하면 업무 효율이 떨어질 수 있다는 반론은 타당합니다. 그래서 저위험 자동화는 넓히되, 영향이 큰 실행에는 권한·승인·감사라는 서로 독립된 안전망을 겹쳐 두는 균형이 필요합니다. 다음 운영 점검에서는 가장 먼저 외부 연결과 관리자 권한을 가진 에이전트를 찾아내는 것이 좋습니다.