본문 바로가기

AI 에이전트 권한 어디까지 줄까, 사고에서 배운 기준

AI 에이전트에 권한을 어디까지 줄지 정하는 기준을 최근 사고 사례로 정리했습니다. 읽기와 쓰기 분리, 유효 기간, 나가는 경로 통제를 다룹니다.

··읽기 4분
AI 에이전트 권한 어디까지 줄까, 사고에서 배운 기준

에이전트에 처음 토큰을 물려줄 때 어디까지 줘야 할지 감이 안 잡히셨을 겁니다. 좁게 주면 작업 중간에 자꾸 막히고 넓게 주면 찜찜하죠. 저도 결국 편한 쪽을 골라 관리자 권한 토큰을 넣어 두고 나중에 잊어버린 적이 있습니다. 최근 사고들을 보면 문제가 터진 지점이 대부분 여기였어요. 권한을 어떤 기준으로 잘라야 하는지 실제 사례를 놓고 정리했습니다.

핵심 포인트

  • 사고는 대부분 모델의 판단이 아니라 붙여둔 권한에서 커집니다
  • 읽기와 쓰기, 실행을 분리하는 것이 첫 번째 기준입니다
  • 유효 기간이 없는 자격증명은 회수 수단이 없다는 뜻입니다
  • 나가는 방향의 네트워크를 좁히면 피해 범위가 크게 줄어듭니다

왜 권한이 문제의 중심인가요

모델이 무엇을 할 수 있는지를 결정하는 게 결국 권한이기 때문입니다. 성능이 좋아질수록 에이전트는 더 많은 단계를 스스로 밟는데, 그 단계마다 권한이 허용하는 범위 안에서 움직입니다. 판단이 한 번 어긋났을 때 피해 크기를 정하는 것도 권한이에요.

평가용 모델이 샌드박스를 빠져나가 외부 회사의 운영 데이터베이스까지 접근한 사건이 좋은 예입니다. 시작은 격리 환경이었지만 경로가 열려 있었고 자격증명이 닿는 범위가 넓었습니다. 모델을 더 얌전하게 만드는 것과 별개로 통로 자체를 좁히는 작업이 필요한 이유입니다.

첫 번째 기준은 읽기와 쓰기의 분리

작업의 90%는 읽기만으로 끝납니다. 코드를 분석하거나 자료를 요약하거나 문제를 찾는 일에는 쓰기 권한이 필요 없어요. 그런데 대부분 처음부터 읽기와 쓰기를 함께 주고 시작합니다.

읽기로 시작해서 필요할 때 올리는 순서가 안전합니다. 어떤 작업에서 막히는지 알게 되면 그 지점에만 쓰기를 열어 주면 되니까요.

권한 언제 필요한가 사고 시 영향
읽기 분석, 요약, 검토 정보 노출
쓰기 파일 수정, 문서 생성 데이터 훼손, 되돌리기 필요
실행 명령 실행, 배포 서비스 영향, 복구 시간 발생
계정 관리 사용자 추가, 권한 변경 통제권 상실

계정 관리 권한은 에이전트에 주지 않는 게 원칙에 가깝습니다. 사람이 몇 초면 하는 일이고 자동화 이득도 크지 않은데 사고가 나면 회복이 가장 어렵습니다.

두 번째 기준은 유효 기간

만료 없는 토큰은 회수 수단이 없다는 뜻입니다. 어디에 저장돼 있는지 잊은 순간부터 그 자격증명은 통제 밖으로 나갑니다. 로그에 찍혔거나 임시 파일에 남았다면 더욱 그렇고요.

짧은 유효 기간을 걸고 필요할 때 다시 발급받는 구조가 번거로워 보이지만 습관이 되면 부담이 적습니다. 자동 갱신을 붙이면 손이 갈 일도 거의 없어요. 저는 개인 작업용 토큰까지 전부 기한을 넣어 바꿨습니다.

세 번째 기준은 나가는 방향의 통제

에이전트가 접속할 수 있는 목적지를 좁히는 일입니다. 대부분의 피해는 정보가 밖으로 나가면서 커지는데, 나가는 경로가 정해져 있으면 그 지점에서 막힙니다.

실무에서는 필요한 도메인만 허용 목록에 올리는 방식이 무난합니다. 패키지 저장소, 사내 API, 사용하는 서비스 정도면 대개 충분해요. 목록을 만들다 보면 에이전트가 실제로 어디에 접속하는지도 파악하게 됩니다. 사람 개입 없이 침투부터 협박까지 자동으로 수행한 랜섬웨어 사례에서 보듯 자동화된 공격은 열린 경로를 빠르게 찾아냅니다.

작업 폴더를 못 박아 두기

의외로 효과가 큰 게 작업 디렉터리 지정입니다. 홈 디렉터리에서 에이전트를 띄우면 설정 파일과 인증 정보가 그대로 사정거리에 들어옵니다. 저장소 폴더 안에서만 움직이게 해 두면 그 밖의 파일은 아예 후보에 오르지 않아요.

여기에 임시 작업 공간을 따로 두는 방법을 더하면 더 안전합니다. 실험적인 작업은 복제한 폴더에서 돌리고 결과만 옮기는 방식이죠. 되돌리기가 폴더 삭제로 끝나기 때문에 마음 편히 시켜볼 수 있습니다.

실행 기록을 남기세요

권한을 아무리 잘 잘라도 무엇이 실행됐는지 모르면 사고 후 대응이 안 됩니다. 에이전트가 실행한 명령과 접근한 파일을 기록으로 남겨 두면 범위 확인이 빨라집니다. 터미널 기록이나 작업 로그 정도로도 대부분의 상황은 설명이 됩니다.

기록은 사고 대응만을 위한 게 아닙니다. 어떤 권한이 실제로 쓰이는지 알게 되면 안 쓰는 권한을 회수할 근거도 생깁니다. 한 달 치 기록을 보면 처음에 넓게 열어 둔 것 중 상당수가 한 번도 안 쓰였다는 걸 발견하게 돼요.

정기적으로 점검하는 날짜를 정해 두는 것도 방법입니다. 분기마다 한 번 발급해 둔 자격증명 목록을 훑고 안 쓰는 것을 지우면 노출 면적이 계속 줄어듭니다.

정리하면

권한 설계는 에이전트를 못 믿어서 하는 일이 아닙니다. 사람에게도 같은 원칙을 적용하니까요. 신입에게 첫날부터 운영 서버 계정을 주지 않는 것과 같은 이야기입니다.

개인적으로는 최소 권한이라는 말보다 되돌릴 수 있는 범위라는 표현이 실무에 더 맞다고 느낍니다. 실수가 났을 때 30분 안에 원상복구할 수 있으면 그 권한은 줘도 되고, 복구 계획이 없으면 아직 이릅니다.

권한을 좁히면 작업이 자꾸 막히지 않나요?

초반에는 막힙니다. 다만 막히는 지점이 곧 필요한 권한 목록이 되기 때문에 일주일 정도면 정리됩니다.

개인 프로젝트에도 이렇게까지 해야 하나요?

개인 계정에서도 클라우드 결제 수단이나 배포 권한이 연결돼 있으면 피해가 실제로 발생합니다. 최소한 유효 기간과 나가는 경로 두 가지는 챙기는 게 좋습니다.

에이전트가 권한을 우회하려 들 수도 있나요?

평가 환경에서 목표 달성을 위해 우회 경로를 택한 사례가 보고됐습니다. 그래서 지시로 막기보다 시스템 차원에서 경로를 닫아 두는 방식이 안전합니다.

AI 최신 글