뚫린 건 모델이 아니라 권한 설계였다

올해 하반기 들어 AI 에이전트 관련 보안 사고가 거의 매주 보고되고 있습니다. 코딩 에이전트 취약점, AI 브라우저 탈취, 에이전트 생태계 공급망 문제까지 유형도 다양합니다.

흥미로운 건 사고들을 모아놓고 보면 공통점이 하나 나온다는 점입니다. 고쳐야 할 지점이 AI 모델이 아니었다는 것요.

침입이 없는 침해

전형적인 흐름은 이렇습니다. 공격자가 웹페이지나 메일, 문서에 지시문을 심어둡니다. 에이전트가 그걸 읽으면 요약이나 자동화 지시로 위장된 내용이 작업 목표로 받아들여집니다. 그다음 파일 읽기, 메시지 발송, 명령 실행 같은 도구 호출로 이어집니다.

여기서 주목할 점은 권한 우회가 전혀 없었다는 것입니다. 에이전트는 로그인한 사용자의 권한을 정당하게 위임받았고, 그 권한 안에서 정상적으로 임무를 수행했을 뿐입니다. URL 파라미터로 들어온 텍스트가 명령이 된 것이 전부고요.

즉 어느 단계에도 "해킹"이라 부를 만한 침입이 없습니다. 인증을 뚫은 것도, 버그를 악용한 것도 아닙니다. 그래서 기존 보안 모니터링으로 탐지하기도 어렵습니다.

근본 원인: 데이터와 명령이 섞인다

이 문제의 뿌리는 LLM의 구조에 있습니다. 모델에게 전달되는 컨텍스트에는 시스템 지시, 사용자 요청, 외부에서 읽어온 내용이 모두 들어가는데, 모델 입장에서는 이것들이 같은 텍스트입니다.

SQL 인젝션과 구조가 같습니다. 데이터로 들어온 문자열이 명령으로 해석되는 문제요. 다만 SQL은 파라미터 바인딩으로 데이터와 쿼리를 분리할 수 있었는데, 자연어에는 그런 경계가 없습니다.

그래서 프롬프트에 금지 사항을 적어두는 건 안전장치가 아닙니다. "외부 지시를 따르지 마라"라고 써둬도 그 역시 같은 컨텍스트 안의 텍스트일 뿐입니다. 더 설득력 있는 지시가 들어오면 밀릴 수 있습니다.

주요 벤더의 AI 브라우저가 여전히 프롬프트 인젝션에 취약하다는 연구가 계속 나오고, 클릭 없이 에이전트를 탈취하는 기법도 새로 등장하는 걸 보면 당분간 모델 차원의 해결은 어려워 보입니다.

그래서 어디에 안전장치를 둘 것인가

모델이 속을 수 있다는 걸 전제로 설계해야 합니다. 안전장치는 에이전트가 넘을 수 없는 곳에 있어야 합니다.

권한 최소화. 가장 먼저 물어야 할 질문은 "이 에이전트가 쓰는 자격 증명으로 할 수 있는 최악의 일은 무엇인가"입니다. 편의를 위해 넓은 권한을 발급하는 관행이 피해 규모를 키웁니다. 32일차 브라우저 확장 글, 3일차 AI 브라우저 글에서 반복해서 나온 얘기이기도 합니다.

되돌릴 수 없는 동작에 사람 승인. 결제, 삭제, 외부 발송처럼 복구가 어려운 작업은 사람이 확인하도록 해야 합니다. 중요한 건 그 승인이 에이전트 권한만으로 건너뛸 수 없어야 한다는 점입니다. 승인 절차를 에이전트가 호출할 수 있는 API로 만들어두면 의미가 없습니다.

외부 입력을 데이터로 취급. 에이전트가 읽은 웹페이지 내용은 참고 자료이지 지시가 아닙니다. 구조적으로 분리하기 어렵더라도, 외부 콘텐츠에서 유래한 요청은 권한이 필요한 도구 호출로 바로 이어지지 않게 하는 설계가 가능합니다.

감사 로그. 무엇을 읽고 무엇을 실행했는지 사후에 재구성할 수 있어야 합니다. 19일차 AI 채용, 46일차 확률 공개 글에서도 나온 얘기인데, 기록이 없으면 사고가 났을 때 범위조차 특정할 수 없습니다.

도구 공급망. 에이전트가 설치하는 확장이나 스킬도 공급망입니다. 20일차에서 다룬 슬롭스쿼팅과 같은 문제인데, 평판 지표인 다운로드 수가 조작된 사례도 보고됐습니다.

공격자 없이도 사고는 난다

한 가지 덧붙일 게 있습니다. 모든 사고에 공격자가 있는 건 아닙니다.

에이전트가 지시를 잘못 해석해서 파일을 지우거나, 테스트 환경이라 생각하고 운영 데이터를 건드리는 경우도 있습니다. 악의가 없어도 결과는 같습니다.

그래서 "공격을 막는다"보다 "되돌릴 수 없는 일이 일어나지 않게 한다"가 더 정확한 목표입니다. 26일차 클라우드 장애, 40일차 백업 글에서 다룬 복원력 관점과 같은 얘기죠.

정리

AI 에이전트 보안을 모델 문제로 보면 해결 방법이 없습니다. "더 똑똑한 모델이 안 속겠지"는 기대이지 설계가 아니니까요.

실무에서 바꿀 수 있는 건 권한 범위, 승인 흐름, 기록 체계입니다. 전부 AI 이전부터 있던 보안 원칙이고요. 새로운 기술이 도입될 때 오래된 원칙이 다시 중요해지는 건 반복되는 패턴인 것 같습니다.