DeepSeek V4.1-Flash가 Pro를 대체한다…모델명 호환부터 확인해야 한다
AI 및 자동화 8
AI 에이전트에 관리자 권한을 주지 마라…작업마다 잠깐 빌려줘야 한다
업무 시스템에 연결되는 AI 에이전트에는 상시 관리자 권한을 주지 말고, 에이전트마다 고유한 신원을 부여해야 한다. 필요한 데이터·도구·행동만 허용하고 높은 권한은 해당 작업 동안에만 활성화한다. Microsoft의 에이전트 최소 권한 설계 지침 은 관리되는 신원과 작업 시간에 한정된 권한을 결합하고, 도구와 하위 시스템에서도 권한을 확인하도록 권고한다.
배포 전에는 ‘이 에이전트가 무엇을 할 수 있는가’보다 ‘어느 시스템의 어떤 대상에 어떤 행동을, 누구의 승인으로 할 수 있는가’를 적어야 한다. 문서 요약, 티켓 생성, 계정 변경을 하나의 포괄적인 역할로 묶으면 작업 경계가 사라진다. 읽기와 쓰기를 분리하고, 삭제·외부 전송·권한 변경처럼 영향이 큰 행동은 별도의 승인과 실행 경로로 다뤄야 한다.
에이전트마다 신원과 책임자를 정한다
고유 신원은 실행 기록을 특정 에이전트에 연결하는 출발점이다. 여러 에이전트가 서비스 계정이나 비밀키를 공유하면 어느 에이전트가 행동했는지 가리기 어렵고, 하나를 중지하려고 공용 자격 증명을 폐기하면 다른 업무도 영향을 받을 수 있다. 사용자를 대신해 실행한다면 에이전트 신원과 권한을 위임한 사용자 정보가 함께 남아야 한다.
신원을 나눴다고 실제 권한까지 좁아지는 것은 아니다. 서로 다른 역할의 권한이 도구와 하위 시스템을 거치며 합쳐지면, 개별 역할은 작아 보여도 결과적으로 넓은 작업을 수행할 수 있다. 역할 이름만 검토하지 말고 에이전트가 호출할 수 있는 도구를 따라가며 최종적으로 접근 가능한 데이터와 행동을 확인해야 한다.
배포 기준에는 에이전트의 책임자, 사용 목적, 연결 시스템, 위임 방식과 비활성화 방법이 포함돼야 한다. 책임자를 알 수 없는 공유 자격 증명으로 작동하거나 퇴역한 에이전트의 권한이 남아 있다면 신원 관리가 끝난 상태로 보기 어렵다. 파일럿에서는 기능이 정상적으로 실행되는지뿐 아니라, 해당 에이전트만 골라 중지할 수 있는지도 확인해야 한다.
도구 이름이 아니라 대상과 행동을 제한한다
도구 허용 목록에는 API 이름만 적어서는 부족하다. 어떤 자원을 읽고, 만들고, 수정하고, 삭제할 수 있는지까지 내려가야 한다. 예를 들어 문의 내용을 바탕으로 티켓을 만드는 에이전트라면 필요한 문의와 티켓에 대한 조회·생성 권한을 검토하고, 전체 업무 공간의 삭제나 관리자 설정 변경은 제외할 수 있다. 읽기 전용 작업에 쓰기 권한이 붙어 있으면 불필요한 실행 경로가 열린다.
OWASP의 AI 에이전트 보안 지침 은 도구별로 읽기·쓰기와 대상 자원을 제한하고 와일드카드 권한을 피하며, 영향이 큰 행동에는 사람의 승인을 두라고 권고한다. ‘모든 명령’이나 ‘모든 저장소’를 허용하는 설정은 처음에는 편리해 보여도 업무가 늘수록 실제 권한을 파악하기 어렵게 만든다. 모델의 지시문에 금지 사항을 적는 것과 별개로, 허용 목록 밖 호출은 실행 계층에서 거부돼야 한다.
권한 검사는 에이전트를 조정하는 계층에서 한 번 통과했다고 끝나지 않는다. 도구가 저장소나 업무 시스템을 호출할 때도 신원, 대상 자원, 요청한 행동을 다시 확인해야 한다. 앞단에는 좁은 역할을 부여했더라도 하위 연동 계정이 전체 관리자 권한으로 요청을 처리한다면 앞단의 제한만으로는 충분하지 않다.
조건부 예로, 고객 문의를 읽어 답변 초안을 만드는 에이전트를 생각해 보자. 문의 조회와 초안 작성은 같은 흐름에 있어도 고객에게 답변을 발송하는 행동은 외부에 보이는 별도 실행이다. ‘초안 작성 가능’과 ‘발송 가능’을 구분하고, 발송 권한을 허용한다면 대상과 내용을 확인할 승인 경로를 정해야 한다.
높은 권한은 해당 작업 동안만 빌린다
상시 관리자 권한을 없앤다고 필요한 업무를 모두 막을 필요는 없다. 기본 권한으로 자료를 읽고 실행안을 준비하게 한 뒤, 특정 작업에 높은 권한이 필요할 때만 임시 역할이나 짧은 수명의 자격 증명을 발급할 수 있다. 그 권한도 실행할 행동과 대상 자원에 묶어야 한다. 시간만 제한한 전체 관리자 권한은 작업 범위를 좁힌 권한과 다르다.
‘잠깐’이라는 표현을 실제 통제로 만들려면 발급 조건, 만료 시점, 재사용 가능 여부, 실패나 취소 시 폐기 방법이 정해져 있어야 한다. 만료된 자격 증명으로 같은 행동을 다시 요청했을 때 거부되는지, 앞서 승인받은 작업의 대상만 바꿔 실행할 수 없는지 시험해야 한다. 자격 증명을 발급한 곳에서 만료시켰더라도 도구나 하위 시스템이 이전 권한을 계속 받아들이는지도 살펴야 한다.
높은 권한이 필요한 예외 작업은 이유와 승인 경로를 남기는 편이 운영에 도움이 된다. 가령 특정 티켓의 상태를 고치려는 작업에 전체 업무 공간의 관리 권한을 빌려주면 노출 시간은 줄어도 수정 가능한 대상은 여전히 넓다. 먼저 작업에 맞는 좁은 역할을 만들고, 그 역할로 수행할 수 없는 행동에만 추가 권한을 검토해야 한다.
사람의 승인은 실행할 행동에 붙인다
사람의 승인은 ‘이 에이전트를 믿는다’는 포괄적 동의가 아니라 실제 실행할 행동에 대한 결정이어야 한다. 삭제, 대량 변경, 결제 시작, 권한 변경처럼 영향이 큰 요청은 실행 전에 대상과 내용을 보여줘야 한다. 에이전트가 행동을 제안하더라도 별도의 정책 서비스나 실행 구성 요소가 권한 범위와 승인 상태를 확인하도록 분리하면, 제안이 곧 실행이 되는 일을 막을 수 있다.
승인 기록에는 요청 주체, 도구, 대상 자원, 실행 매개변수와 유효 기간을 연결해야 한다. 승인 뒤 대상이나 금액 같은 핵심 매개변수가 바뀌었다면 기존 승인을 그대로 사용해서는 안 된다. 승인 화면이 있어도 실행 단계에서 기록의 유효성과 매개변수를 대조하지 않으면, 사람이 확인한 행동과 시스템이 수행한 행동이 달라질 수 있다.
거부와 시간 초과도 정상적인 처리 경로로 설계해야 한다. 승인 서비스가 응답하지 않거나 위험 분류·정책 조회·감사 기록에 실패했는데도 실행이 진행되면 장애가 승인 절차를 우회하는 통로가 된다. 이 경우 실행을 멈추고 요청 상태를 남겨야 운영자가 어디에서 막혔는지 파악할 수 있다.
감사 로그와 폐기 시험으로 배포 여부를 판단한다
대화 내용만 저장해서는 실제 실행을 재구성하기 어렵다. 감사 로그에는 에이전트와 위임 사용자, 적용된 역할과 권한 범위, 호출한 도구, 대상 자원, 승인 결과와 실행 결과를 같은 작업 식별자로 연결해 기록해야 한다. 민감한 원문이나 자격 증명을 그대로 남기지 않으면서도 누가 무엇을 허용했고 무엇이 실행됐는지 답할 수 있어야 한다.
중지 절차는 권한 부여 절차만큼 구체적이어야 한다. 에이전트를 비활성화하거나 비밀키를 교체해도 이미 발급된 토큰이 계속 통한다면 실행 가능성이 남는다. 중지 직후 새 요청을 거부하는지, 기존 자격 증명이 다시 사용되는지, 연결된 시스템에 오래된 권한이 남아 있는지를 확인해야 한다. 즉시 폐기할 수 없는 자격 증명이 있다면 만료 전까지 어떤 요청이 가능한지도 운영자가 알아야 한다.
배포 검토에서는 설명 문서의 ‘최소 권한 적용’ 표시보다 실제 허용·거부 시험과 그 기록이 중요하다. 다음 질문에 설정값과 호출 결과로 답할 수 있어야 한다.
- 각 에이전트의 고유 신원과 책임자가 확인되는가? 공유 자격 증명이 남아 있다면 어느 작업에 쓰이는지 구분할 수 있는가?
- 허용한 도구마다 대상 데이터와 읽기·쓰기 행동이 명시돼 있는가? 목록 밖 도구와 자원에 대한 호출은 실제로 거부되는가?
- 높은 권한의 발급·만료·폐기 조건이 정해져 있는가? 만료된 자격 증명이나 다른 작업의 승인으로 재실행할 수 없는가?
- 위험한 행동의 승인자는 정확한 대상과 내용을 보고 결정하는가? 승인 없이 실행하거나 승인 뒤 매개변수를 바꾼 요청이 차단되는가?
- 도구와 하위 시스템의 결과를 같은 작업 식별자로 추적할 수 있는가? 에이전트를 중지한 뒤 남은 토큰과 권한도 사용할 수 없게 되는가?
이 질문에 답하지 못하는 행동은 허용 범위를 좁히고 다시 시험해야 한다. 배포 통과 기준에는 에이전트가 허용된 일을 끝냈다는 기록과 함께, 허용하지 않은 일을 요청했을 때 권한 경계가 실제로 작동했다는 기록이 포함돼야 한다.
함께 읽기:
관련 기사
뉴스레터 구독
최신 Web3, AI, 암호화폐 뉴스를 이메일로 받아보세요.
0