AI 에이전트 사내 도입 설계 가이드 | 최소 권한과 사람 승인 기준

AI 에이전트를 개발할 때 사내 고객 관계 관리 시스템과 이메일, 파일 저장소를 AI 에이전트에 연결하면 정보 조회와 이메일·파일 발송을 하나의 흐름으로 자동화할 수 있습니다. 결제 시스템까지 연결하면 자동화할 수 있는 업무 범위가 넓어지지만, 잘못 실행했을 때의 영향도 함께 커집니다.

고객 정보를 읽기만 해야 하는 에이전트에 필요 이상의 권한을 주면 외부 주소로 파일을 보내거나 잘못된 수신자에게 이메일을 발송할 수 있습니다. 결제와 권한 변경까지 허용했다면 한 번의 오판으로 금전 손실이 발생하고 계정의 접근 범위도 바뀔 수 있습니다.

AI 에이전트 권한은 읽기·작성·삭제·외부 전송·결제·권한 변경으로 나눠 설계해야 합니다. 최소 권한은 업무 수행에 필요한 기능과 데이터만 허용하는 보안 원칙입니다. 각 권한의 기본값은 최소 권한으로 제한하는 것이 중요합니다.

되돌릴 수 없거나 금전·개인정보에 영향을 주는 작업에는 사람의 승인과 감사 로그(누가 언제 어떤 작업을 요청하고 승인했는지 남기는 기록)를 적용해야 합니다. 승인 게이트(실행 전 담당자가 허용 여부를 확인하는 절차)를 두면 어떤 작업을 자동으로 실행하고 어떤 작업을 사람이 확인할지 구분할 수 있어, AI 에이전트 개발 과정에서 자동화 속도와 통제 수준을 함께 관리할 수 있습니다.

인증정보도 계속 유효한 키를 공유하기보다 작업이 끝나면 만료되도록 유효 기간을 짧게 설정해 발급해야 합니다. 감사 로그는 사고 원인을 찾고 권한 정책을 수정하는 근거가 됩니다.

1. AI 에이전트에 권한 설계를 먼저 해야 하는 이유는 무엇일까?

AI 에이전트 권한 설계는 업무 시스템에 도구를 연결하기 전에 마쳐야 하는 운영 통제 사항입니다. 에이전트가 접근할 데이터와 실행할 행동을 구분하지 않으면 프롬프트 인젝션(외부 문서나 입력값에 악성 지시를 넣어 AI의 행동을 조작하는 공격), 오작동, 계정 탈취가 고객정보 유출과 오발송, 무단 결제 같은 손실로 즉시 이어지기 때문입니다.

실제 사례로는 Microsoft 365 Copilot의 EchoLeak(CVE-2025-32711)이 있습니다. 공격자가 악성 지시를 숨긴 이메일을 보내면 Copilot이 이를 일반 자료가 아닌 명령으로 받아들이고, 사용자가 별도로 클릭하지 않아도 접근 가능한 사내 정보를 외부로 전송할 수 있는 취약점이었습니다. Microsoft는 서버 측에서 문제를 수정했으며 실제 고객 피해는 확인되지 않았습니다. 이 사례는 AI가 이메일과 사내 문서에 접근할 수 있을 때 읽기 권한만으로도 정보 유출 위험이 생길 수 있음을 보여줍니다.

기존 챗봇은 잘못된 답변을 내놓더라도 사용자가 내용을 검토한 뒤 사용할 수 있습니다. 반면 에이전트는 답변을 이메일 발송이나 데이터 변경 같은 실제 행동으로 이어집니다. 따라서 실행 전에 권한 범위와 승인 조건을 정해야 합니다.

권한은 연결하는 시스템별로 구분해야 합니다. 같은 고객 관계 관리 시스템에서도 고객명을 조회하는 행동과 계약 조건을 수정하는 행동은 위험 수준이 다릅니다. 하나의 계정에 모든 권한을 부여하면 위험한 행동만 선별해 차단하기 어렵습니다.

1-1. 도구를 연결한 뒤 어떤 보안 사고가 발생할 수 있을까?

• 에이전트 개발팀이 고객 관계 관리 시스템과 이메일을 연결했다고 가정해 보겠습니다. 에이전트가 전체 고객정보를 조회하고 외부 이메일까지 발송할 수 있다면, 하나의 요청만으로도 정보가 유출될 수 있습니다.
• 에이전트가 외부 문서나 입력값에 포함된 악성 지시를 정상적인 요청으로 받아들이면 고객 목록을 조회할 수 있습니다. 이후 공격자가 지정한 주소로 목록을 전송하는 행동까지 이어질 수 있습니다.
• 사용자의 정상적인 요청도 사고를 일으킬 수 있습니다. 수신자 필터를 잘못 해석하면 안내 메일이 전체 고객에게 발송됩니다. 파일 경로를 혼동하면 내부 계약서를 외부에 공유할 수도 있습니다.

AI 에이전트 권한 관리는 읽기·작성·삭제·외부 전송·결제·권한 변경을 각각 분리하는 것에서 시작합니다. 위험 등급을 정할 때는 데이터가 얼마나 민감한지와 실행 후 원래 상태로 복구할 수 있는지를 함께 판단해야 합니다. 고객정보 권한도 필드(고객명·연락처처럼 시스템에서 정보를 나누어 저장하는 항목)와 대상 고객 범위에 따라 나눠야 합니다.

조회 권한이라고 해서 안전하다고 단정할 수는 없습니다. 개인정보나 계약 정보는 조회되는 순간 외부 전송에 활용될 수 있기 때문입니다. 따라서 민감한 데이터는 조회할 필드와 대상 고객까지 제한해야 합니다.

1-2. AI 에이전트의 과도한 권한은 왜 위험할까?

OWASP는 Excessive Agency(에이전트에 과도한 기능과 권한, 자율성을 부여해 의도하지 않은 행동이 실행되는 위험)를 설명합니다. 업무 목표를 달성하는 데 필요한 범위보다 더 많은 도구를 제공하면 공격자가 악용할 수 있는 행동도 늘어납니다.

예를 들어 상담 답변 작성이 목표라면 고객정보를 읽는 권한만 필요합니다. 고객정보를 수정하거나 삭제하고 이메일을 발송하는 권한까지 제공할 근거는 없습니다. 에이전트 구축 시에는 목표별로 별도 계정과 권한 묶음(업무에 필요한 접근 권한을 목적별로 모은 구성)을 만드는 편이 안전합니다.

OWASP AI Agent Security Cheat Sheet도 최소 권한, 명시적 승인, 실행 기록을 주요 통제로 제시합니다. 특히 외부 전송이나 결제처럼 되돌리기 어려운 행동은 승인 게이트를 거쳐야 합니다.

최소 권한을 적용할 때는 에이전트가 업무를 완료하는 데 필요한 데이터와 행동만 허용해야 합니다. 여기에 짧은 수명의 인증정보(시스템이 계정이나 요청의 신원을 확인하는 데 사용하는 정보)를 적용하면 계정이 탈취돼도 공격자가 악용할 수 있는 시간을 줄일 수 있습니다.

승인 게이트에서는 사람이 실행 직전에 요청 내용과 대상을 확인하고 허용하거나 차단합니다. 모든 도구 호출(AI 에이전트가 연결된 시스템에 작업 실행을 요청하는 것)과 승인 결과는 감사 로그에 저장해야 사고 원인과 영향을 추적할 수 있습니다.

결국 통제 수준은 모델 성능보다 에이전트가 할 수 있는 행동과 할 수 없는 행동을 나누는 권한 분배에서 결정됩니다. 에이전트가 무엇을 할 수 있는지만 확인하지 말고, 무엇을 하지 못하도록 막았는지도 먼저 검토해야 합니다.

2. 읽기·작성·삭제·외부 전송·결제 권한은 어떤 위험 등급으로 나눠야 할까?

• [기본] AI 에이전트의 읽기 권한은 조회할 데이터 범위를 제한해 기본 권한으로 운영하는 것이 원칙입니다.
• [중위험] 작성 권한은 작성 대상·템플릿·처리량을 제한하고 중위험 권한으로 봅니다.
• [고위험] 삭제·외부 전송·결제·권한 변경은 복구가 어렵고 피해 범위가 크므로 고위험으로 분류하고, 승인 게이트를 반드시 적용해야 합니다.

AI 에이전트의 위험 등급은 기능 이름만 보고 정하지 않고, 실패했을 때 어떤 결과가 발생하는지를 기준으로 판단합니다. 같은 읽기 작업이라도 공개 문서 한 건을 조회하면 저위험이지만, 고객 개인정보 전체를 조회하면 고위험일 수 있습니다. 따라서 설계 단계에서 허용 범위와 승인 조건을 함께 문서화해야 합니다.

OWASP(Open Worldwide Application Security Project, 소프트웨어 보안 지침을 제공하는 비영리 재단)는 Excessive Agency(과도한 대리 권한)를 에이전트에 필요 이상의 기능·권한·자율성을 부여한 상태로 설명합니다. 최소 권한과 고영향 작업에 대한 사람의 승인이 핵심 통제입니다. 이는 에이전트 구축 전에 위험 등급을 먼저 정해야 하는 근거가 됩니다.

표의 승인 기준은 기본값이며, 작성 권한도 작성한 내용을 고객에게 즉시 발송하거나 대량 레코드(한 건의 고객이나 거래를 나타내는 데이터 묶음)를 수정한다면 고위험으로 올려야 합니다. 반대로 삭제는 소프트 삭제와 복구 기능을 갖췄더라도 사람 승인을 유지하는 편이 안전합니다.

2-1. 조회 권한은 어떤 데이터 범위까지 허용해야 할까?

도입 초기에는 전사 데이터를 모두 조회하게 하지 말고, 담당 조직과 고객군으로 범위를 좁혀야 합니다. CRM에서는 담당 고객 레코드와 업무에 필요한 필드만 조회할 수 있도록 권한을 열어 주는 방식이 적합합니다.

주민등록번호와 계좌정보는 마스킹하고, 계약 금액은 역할에 따라 조회 범위를 제한해야 합니다. 대량 조회와 파일 내려받기에는 별도 기준을 적용하고, 기준을 넘으면 사람의 승인을 받은 뒤 감사 로그를 남겨야 합니다.

2-2. 삭제·외부 전송·결제는 왜 고위험 작업으로 분류해야 할까?

고위험 여부는 작업을 되돌리기 어려운지와 외부에 미치는 영향이 큰지를 기준으로 판단합니다. 금전 손실이나 법적 책임이 발생하는 작업도 고위험에 해당합니다. 삭제 권한은 소프트 삭제를 기본으로 적용하고, 복구 가능 기간과 백업 상태를 승인 화면에서 확인해야 합니다.

외부 전송을 통제하려면 수신자 도메인 허용 목록(전송을 허용한 이메일 도메인 목록)을 정하고 첨부파일 유형을 제한해야 합니다. 결제 승인 단계에서는 사람이 거래 대상과 금액을 재확인하게 해야 하며, 구현 과정에서 누적 결제 한도와 중복 결제 차단도 함께 구현해야 합니다.

2-3. 권한 변경 작업은 누가 승인해야 할까?

사용자 계정 추가는 업무 요청자와 시스템 책임자가 나눠 승인해야 합니다. 관리자 권한을 부여하거나 접근 범위를 확대할 때는 보안 책임자의 검토까지 추가해야 합니다. 요청자가 자신의 요청을 승인하지 못하도록 권한 분리를 적용하는 것이 핵심입니다.

에이전트에는 승인된 작업에만 유효한 짧은 수명의 인증정보를 발급하는 것이 원칙입니다. 감사 로그에는 요청자와 승인자 정보를 기록하고, 실행 대상·결과·복구 이력도 함께 남겨야 합니다. 이는 권한 분리와 최소 권한을 요구하는 NIST(미국 국립표준기술연구소) 통제 기준에도 부합합니다.

3. AI 에이전트의 최소 권한 원칙은 어떻게 구현해야 할까?

최소 권한 원칙을 구현하려면 AI 에이전트에 필요한 시스템, 데이터 필드, 실행 시간과 호출 횟수만 허용해야 합니다. 관리자 계정은 공유하지 말고 작업별 서비스 계정을 발급해야 합니다. 여기에 짧은 수명의 인증정보를 사용하면 오남용이 발생해도 피해 범위를 제한할 수 있습니다.

권한을 설계할 때는 허용할 작업을 먼저 정의한 뒤, 정의하지 않은 작업은 모두 차단해야 합니다. API(Application Programming Interface, 시스템 간 기능 호출 규칙) 권한 범위도 조회와 수정, 삭제처럼 실행 유형별로 분리하는 편이 안전합니다.

OWASP도 AI 에이전트의 자격 증명(시스템이 접근 주체를 확인할 때 사용하는 정보)을 안전하게 관리하고 최소 권한을 적용하도록 권고합니다. 권한을 넓게 부여한 뒤 사용하지 않는 기능을 차단하면, 차단해야 할 기능을 빠뜨리기 쉽습니다.

3-1. 관리자 계정 대신 작업별 서비스 계정을 써야 하는 이유는 무엇일까?

사람의 계정을 공유하면 누가 실제로 작업을 실행했는지 구분하기 어렵습니다. 관리자 API 키가 노출되면 에이전트에 필요하지 않았던 삭제나 권한 변경 기능까지 실행될 수 있습니다.

서비스 계정은 에이전트별·기능별로 분리해야 합니다. 그러면 파일 조회용 계정이 외부 전송이나 삭제 기능을 호출하지 못하도록 차단할 수 있습니다.

운영 환경과 테스트 환경의 서비스 계정도 나눠야 합니다. 테스트에 사용한 권한이 운영 시스템에 남지 않도록 운영에 반영하기 전 API 권한 범위를 다시 검수해야 합니다.

결제 기능은 조회와 결제 요청, 환불, 결제수단 변경 권한을 각각 분리하는 것이 안전합니다. 환불이나 결제수단 변경처럼 금전적 영향이 큰 작업은 사람이 별도로 승인하도록 설정해야 합니다.

3-2. 짧은 수명의 인증정보는 얼마나 자주 갱신해야 할까?

짧은 수명의 인증정보는 만료 시간이 지나면 접근을 자동으로 차단합니다. 삭제와 결제, 권한 변경에는 실행 건마다 발급되는 단기 토큰을 적용하고, 일반 조회·작성에는 작업 세션 단위 토큰을 사용하는 기준이 적절합니다.

실제 만료 시간은 시스템 위험도와 운영 환경에 맞춰 정해야 합니다. 인증정보가 노출된 뒤 이를 회수할 때까지 허용할 수 있는 피해 시간보다 짧게 설정하는 것이 기준입니다.

시스템은 토큰을 자동으로 발급·갱신할 수 있어야 하며, 문제가 생기면 즉시 폐기할 수 있어야 합니다. 갱신에 필요한 비밀값은 비밀정보 저장소에 두고, 프롬프트나 애플리케이션 로그에는 남기지 않아야 합니다.

고정 API 키가 꼭 필요하다면 사용할 수 있는 시스템과 호출 출발지를 제한해야 합니다. 담당자가 바뀌거나 기능을 폐기할 때 즉시 회수할 수 있도록 소유자와 폐기 절차도 함께 기록해야 합니다.

3-3. 고객 데이터는 어떤 필드부터 마스킹해야 할까?

데이터 마스킹은 원문 대신 일부를 가리거나 대체값을 반환하는 처리입니다. 주민등록번호와 결제수단 정보, 비밀번호·토큰 같은 인증정보는 에이전트가 원문을 읽지 못하도록 우선 제한해야 합니다.

민감한 계약 조건도 업무 목적에 필요한 항목만 반환해야 합니다. 고객 등급 확인이 목적이라면 계약서 전체를 제공하지 말고 등급과 계약 상태만 반환하는 방식이 적절합니다.

결제카드 원문은 AI 에이전트로 전달하지 않고 결제 시스템이 발급한 대체 식별값을 사용해야 합니다. 이렇게 하면 데이터가 유출되더라도 실제 결제정보가 노출될 위험을 줄일 수 있습니다.

구현 단계에서는 입력 데이터뿐 아니라 도구 실행 결과도 점검해야 합니다. 조회 API가 불필요한 고객 필드까지 반환하면 에이전트의 출력이나 로그에 민감정보가 남을 수 있기 때문입니다.

권한 설계가 끝나면 허용되지 않은 호출이 실제로 차단되는지 테스트해야 합니다. 서비스 계정과 API 권한 범위가 바뀔 때는 승인자와 변경 사유를 감사 로그에 남겨야 추후 오작동 원인을 확인할 수 있습니다.

4. 어떤 AI 에이전트 작업부터 사람 승인을 거치게 해야 할까?

사람 승인은 외부에 영향을 주거나 실행 후 되돌리기 어려운 작업에 적용해야 합니다. 고객 이메일 발송, 파일 삭제, 외부 전송, 결제 실행, 권한 변경은 승인 결과를 확인한 뒤 처리하도록 설계하는 것이 안전합니다.

승인 정책은 작업의 영향도와 실행 후 복구 가능성을 기준으로 사람의 승인 여부를 판단합니다. 금전 손실이나 개인정보 노출 가능성이 있다면 자동 실행보다 사람 승인을 우선해야 합니다.

Human in the Loop(HITL, 실행 과정에 사람이 개입하는 통제 방식)는 위험 작업을 사람이 직접 수행한다는 뜻이 아닙니다. AI 에이전트가 준비한 요청을 승인자가 검토하고 실행을 허용하는 구조입니다.

승인 게이트는 실행 직전에 조건과 승인 결과를 확인하는 통제 지점입니다. NIST의 AI 위험관리 프레임워크(AI 시스템의 위험을 관리하기 위한 지침)도 사람의 감독과 개입 절차를 AI 시스템 운영 통제에 포함합니다.

4-1. 이메일 작성과 이메일 발송은 왜 분리해야 할까?

에이전트는 이메일 초안을 만드는 기능과 실제 발송 권한을 분리해야 합니다. 초안은 자동으로 만들 수 있지만, 수신자와 본문, 첨부파일, 발송 시점은 담당자가 확인해야 합니다.

특히 사내 CRM의 고객 정보를 활용하면 이메일 오발송이 미치는 영향이 커집니다. 승인 화면에서는 변경된 항목과 개인정보 포함 여부를 한눈에 확인할 수 있어야 합니다.

승인 후 본문이나 첨부파일이 바뀌었다면 기존 승인은 무효로 처리해야 합니다. 승인자가 검토한 내용과 실제 발송 내용이 달라지는 문제를 막기 위한 조치입니다.

4-2. 결제 승인에는 한도와 다단계 검토를 어떻게 적용할까?

결제 기능은 금액뿐 아니라 공급처와 계좌가 변경되었는지도 검사해야 합니다. 반복 결제라도 결제 한도를 넘거나 신규 계좌가 등록되면 재승인을 받아야 합니다.

다단계 승인은 회사의 기존 결재규정과 같은 금액 구간을 사용합니다. 실무 담당자는 거래 내용을 확인하고, 상위 승인자는 예산과 공급처 변경에 따른 위험을 검토하는 방식이 적절합니다.

결제가 실패해 자동으로 재시도하더라도 승인된 금액과 횟수를 넘겨서는 안 됩니다. 승인 요청과 실행 결과를 같은 식별값으로 기록하면 중복 결제 여부를 추적할 수 있습니다.

4-3. 긴급 작업에서 승인 절차를 우회해도 될까?

긴급 상황에서도 일반 계정에 승인 우회 권한을 부여하면 안 됩니다. 권한 설계 단계에서 비상 권한(break-glass, 장애 대응용 임시 권한)을 별도로 만들고 사용 조건을 미리 정해야 합니다.

비상 권한은 지정된 담당자만 제한된 시간 동안 사용할 수 있어야 합니다. 허용할 작업과 대상 시스템의 범위를 좁히고, 실행 사유와 명령 기록을 감사 로그로 보관해야 합니다.

작업이 끝나면 권한을 즉시 회수하고 다른 관리자가 사후 검토해야 합니다. NIST SP 800-53도 관리자 계정처럼 높은 권한을 가진 계정 관리와 감사 기록을 주요 접근 통제로 다룹니다.

5. AI 에이전트 감사 로그에는 누가 무엇을 했는지 어디까지 남겨야 할까?

AI 에이전트 감사 로그에는 요청자, 에이전트 식별자, 사용 도구, 접근 데이터 범위, 실행 행동, 승인자, 결과, 오류, 권한 변경 이력을 남겨야 합니다. 이 기록이 있어야 오발송·오결제·데이터 유출의 원인과 책임 범위를 추적할 수 있습니다.

모델 응답만 저장하면 실제 실행 주체와 승인 과정을 확인하기 어렵습니다. 따라서 모델 응답뿐 아니라 실제로 누가 실행했고 누가 승인했는지도 함께 기록해야 합니다.

OWASP는 보안 이벤트가 발생한 시간·위치와 관련 주체·행동을 기록하고, 로그를 무단 접근과 변조로부터 보호하도록 권고합니다. 비밀번호와 접근 인증정보는 로그에 직접 저장하지 않아야 합니다.

개인정보처리시스템의 접속기록은 1년 이상 보관·관리해야 합니다. 5만명 이상의 정보주체 개인정보를 처리하거나 고유식별정보 또는 민감정보를 처리하는 경우에는 2년 이상 보관·관리해야 합니다.

5-1. 감사 로그에서 반드시 식별해야 하는 주체는 누구일까?

요청자와 승인자뿐 아니라 에이전트, 서비스 계정, 최종 실행 시스템도 각각 구분해 기록해야 합니다. 이 주체들을 한 계정으로 묶어 기록하면 사람이 승인했는지, 에이전트가 독자적으로 실행했는지 판단할 수 없습니다.

특히 결제와 외부 전송에서는 승인자와 실제 실행자를 모두 기록해야 합니다. 승인 대상과 최종 실행 내용이 다르면 언제 누가 내용을 변경했는지까지 확인할 수 있어야 합니다.

5-2. 프롬프트와 원문 데이터도 모두 저장해야 할까?

프롬프트와 원문 데이터를 전부 저장하는 방식은 피해야 합니다. 감사 로그에는 재현에 필요한 입력 요약, 정책 판정 결과, 실행 변수를 우선 기록하는 편이 안전합니다.

원문이 꼭 필요하면 마스킹을 적용해야 합니다. 원문 로그의 열람 권한과 보존 기간도 운영 로그보다 엄격하게 설정해야 합니다.

NIST는 로그를 수집하는 데서 그치지 않고 저장·분석·폐기까지 전 과정을 관리하도록 제시합니다. 실무에서는 데이터의 민감도에 따라 보존 기간과 접근 권한을 나눠야 한다는 의미입니다.

5-3. 장애나 분쟁이 발생했을 때 어떤 순서로 추적해야 할까?

장애가 발생하면 실행 ID를 기준으로 추적을 시작합니다. 요청 접수, 권한 검증, 사람 승인, 도구 호출, 실행 결과를 시간순으로 확인해야 합니다.

그다음 권한 변경 이력과 재시도 기록을 대조하면 승인 범위를 벗어난 실행이 언제 발생했는지 찾을 수 있습니다. 분쟁에 대응할 때는 해당 기록을 수정할 수 없도록 보호하고, 누가 언제 열람했는지도 기록해야 합니다.

여러 업무 시스템을 연결한 경우 모든 시스템이 동일한 실행 ID를 기록해야 합니다. 그래야 이메일 발송과 파일 조회 같은 연속 작업을 하나의 사건으로 재구성할 수 있습니다.

6. 권한 통제가 포함된 AI 에이전트 개발은 어떻게 시작해야 할까?

권한 통제가 포함된 AI 에이전트를 개발하려면 업무 시나리오와 연결 시스템을 확정한 뒤 위험 등급(에이전트의 행동이 미칠 영향과 피해 가능성에 따라 나눈 수준), 권한 정책, 승인 흐름, 감사 로그를 함께 설계해야 합니다. 기능을 구현한 뒤 보안을 덧붙이면 권한 구조를 다시 설계해야 합니다.

초기 설계에서는 구현할 기능을 나열하기보다 에이전트가 언제 실행되고 승인되거나 차단되는지부터 정해야 합니다. AI 에이전트 보안 설계가 완료돼야 개발자가 허용된 데이터 범위와 차단할 행동을 코드에 정확히 반영할 수 있기 때문입니다.

6-1. AI 에이전트 도입 전에 어떤 요구사항을 정리해야 할까?

요구사항 문서에는 자동화할 업무와 연결할 시스템을 구체적으로 적어야 합니다. 고객 관계 관리 시스템을 조회한 뒤 이메일을 발송한다면 어떤 데이터 항목을 조회할지, 누구에게 보낼지, 어떤 조건에서 발송할지까지 정의해야 하죠.

데이터는 공개 정보, 사내 정보, 개인정보, 결제 정보처럼 민감도에 따라 분류합니다. 같은 조회 기능이라도 개인정보가 포함되면 접근 범위와 감사 로그를 다르게 설계해야 합니다.

허용 행동과 금지 행동도 각 행동을 기준으로 구분해야 합니다. 이메일 초안 작성은 허용하되 외부 발송은 승인 후 실행하고, 고객 데이터 삭제와 관리자 권한 변경은 기본적으로 차단하는 방식이 적합합니다.

승인자와 장애 대응 책임자도 사전에 지정해야 합니다. 승인 요청이 장시간 처리되지 않거나 에이전트가 반복 실행될 때 누가 실행을 중단하고 원인을 조사할지까지 정해야 운영 공백을 막을 수 있습니다.

NIST의 AI 위험관리 프레임워크는 AI 시스템의 수명주기 전반에서 역할과 책임을 명확히 정하도록 권고합니다. 실무에서는 개발에 착수하기 전에 업무 책임자와 보안 담당자가 각각 무엇을 검토할지 문서화한다는 뜻입니다.

6-2. 권한 정책은 개발·테스트·운영 환경에서 어떻게 분리해야 할까?

개발 환경에서는 샘플 데이터와 제한된 테스트 계정만 사용해야 합니다. 운영 환경의 실제 고객 데이터나 결제 인증정보를 개발자의 로컬 환경에 복사하면 접근 경로를 추적하기 어려워집니다.

테스트 환경에서는 승인 워크플로우와 차단 규칙이 실제로 작동하는지 검증합니다. 외부 전송과 결제 요청은 테스트용으로 지정한 대상에서만 실행하고, 운영 시스템의 API와 분리해야 하죠.

운영 환경에는 검증된 권한 정책만 적용해야 합니다. 개발·테스트·운영 계정과 인증정보를 각각 발급하고, 인증정보에는 짧은 유효기간을 설정하며 필요한 기능만 사용할 수 있도록 권한을 부여하는 방식이 안전합니다.

NIST SP 800-53은 최소 권한 통제를 요구합니다. 실무에서는 환경별로 계정을 분리하고 운영 권한을 제한하는 방식으로 적용할 수 있습니다.

6-3. AI 에이전트의 권한 통제는 누가 검수해야 할까?

업무 책임자는 에이전트의 허용 행동과 승인 조건을 검토합니다. 보안 또는 개인정보 담당자는 데이터 접근 범위, 외부 전송, 인증정보 보관 방식이 사내 정책과 법적 요건에 맞는지 확인해야 합니다.

테크리더는 권한 검사가 코드에 빠짐없이 구현됐는지 검수합니다. 코드 리뷰에서는 승인 전 실행을 막는 조건, API 호출 제한, 오류 발생 시 중단 처리, 감사 로그 누락 여부를 주로 확인합니다.

그릿지 올인원 개발은 AI 활용 개발과 테크리더 코드 검수를 결합합니다. 기능을 구현하는 단계부터 권한 정책과 승인 워크플로우, 로그 요구사항이 코드에 반영됐는지 확인하는 방식입니다.

권한 통제를 포함한 개발 순서는 다음과 같이 정리할 수 있습니다. 각 단계의 활동과 산출물, 검토 책임자는 아래 표에서 확인할 수 있습니다.

운영 지표에는 도입 전 점검 체크리스트 완료율과 승인 누락 건수, 권한 변경 건수를 포함하는 게 좋습니다. 배포 전 기준값과 점검 주기는 조직의 보안 정책에 맞춰 확정해야 합니다.

AI 에이전트를 통한 안전한 자동화는 적절한 권한부여가 핵심입니다.

AI 에이전트의 권한을 설계하는 일은 자동화 범위를 줄이는 작업이 아닙니다. 에이전트가 직접 실행할 수 있는 범위와 사람의 판단을 받아야 하는 지점을 정해, 안전하게 자동화할 수 있는 범위를 넓히는 기준을 세우는 일입니다.

읽기·작성·삭제·외부 전송·결제·권한 변경을 위험도에 따라 나누고, 각 작업에는 최소 권한을 부여해야 합니다. 짧은 수명의 인증정보와 승인 게이트, 감사 로그도 함께 적용해야 이러한 통제가 실제 운영에서도 유지됩니다.

특히 외부 전송과 결제, 권한 변경처럼 영향이 큰 작업은 실행 전에 사람이 대상과 금액, 범위를 확인해야 합니다. 실패하거나 취소된 시도까지 기록하면 사고 원인과 책임 범위를 빠르게 확인할 수 있습니다.

처음부터 모든 업무를 자동화하기보다 읽기 전용 시나리오로 시작하는 편이 안전합니다. 이후 로그와 승인 결과를 검토하면서 작성, 외부 전송, 결제 순으로 권한을 확대하면 운영 기준도 흔들리지 않습니다.

그릿지는 권한 정책과 승인 흐름, 검수 이력을 에이전트 구축 범위에 함께 반영합니다. AI 활용과 테크리더의 코드 검수를 결합해 빠른 구축과 유지보수 가능성을 함께 점검합니다.

AI 에이전트 개발을 검토하고 있다면 기능 목록보다 권한 표와 승인 조건을 먼저 준비하세요. 이 기준이 있어야 담당자와 연결 시스템이 바뀌어도 같은 통제 원칙을 유지할 수 있습니다.

권한 통제가 포함된 AI 에이전트 올인원 개발 상담 신청으로 현재 시스템과 자동화 목표를 점검해 보세요. 그릿지가 업무 범위와 위험 등급, 승인 절차를 기준으로 안전한 도입 순서를 함께 구체화합니다.

👉 AI 에이전트를 더 잘 활용하는 MCP 연결법 알아보기

Q&A

Q1. AI 에이전트에 CRM 고객 정보를 모두 읽을 수 있게 해도 될까요?

AI 에이전트의 CRM 고객 정보 읽기 권한은 필요한 고객군과 필드로 제한해야 합니다. 담당 업무와 무관한 연락처, 주민등록번호 같은 민감정보, 비밀번호나 토큰 등 인증정보는 접근 대상에서 제외하세요. 조직·담당자·기간 조건을 함께 걸고, 조회 기록을 남겨 과도한 접근을 점검하는 방식이 안전합니다. 권한은 정기적으로 재검토해야 합니다.

Q2. AI 에이전트가 이메일을 자동 발송해도 되는 업무는 어디까지일까요?

AI 에이전트의 이메일 자동 발송은 반복 안내처럼 영향이 낮은 업무에만 허용해야 합니다. 사전 승인된 템플릿, 수신자 조건, 발송 시간과 횟수를 고정해 오발송 범위를 막으세요. 신규 고객에게 보내는 메시지, 계약·가격·민감정보를 포함한 내용은 발송 전 담당자 승인을 거치도록 설계하는 것이 원칙입니다. 이 기준은 예외 발송에도 적용하세요.

Q3. 파일 삭제 권한은 AI 에이전트에 아예 주면 안 되나요?

AI 에이전트에 파일 삭제 권한을 줄 수는 있지만, 즉시 영구 삭제를 허용하면 안 됩니다. 삭제는 지정된 폴더와 파일 유형으로 제한하고 먼저 휴지통으로 이동시키세요. 실행 전 승인과 복구 가능 기간을 적용한 뒤, 대상·요청자·실행 결과를 로그에 남겨야 실수와 악의적 요청을 추적할 수 있습니다.

Q4. AI 에이전트 결제 권한에는 얼마의 한도를 설정해야 할까요?

AI 에이전트 결제 권한의 한도는 업무별 결제 규모와 예산 통제 기준에 맞춰 정해야 합니다. 기존 공급처의 반복 결제와 신규 공급처 결제를 분리하고, 예산 잔액과 결제 목적을 확인하는 규칙을 두세요. 한도 초과, 신규 수취인, 조건 변경 결제는 담당자 또는 책임자의 추가 승인을 반드시 거쳐야 합니다.

Q5. 짧은 수명의 인증정보는 왜 필요한가요?

짧은 수명의 인증정보는 장기 API 키가 유출됐을 때 공격자가 접근할 수 있는 기간을 줄이기 위해 필요합니다. 단기 토큰을 사용하고 자동 갱신과 즉시 폐기 절차를 함께 구성하세요. 인증정보는 코드나 프롬프트에 넣지 말고 비밀정보 저장소에서 관리하며, 사용 이력과 비정상 호출도 점검해야 합니다.

Q6. AI 에이전트 감사 로그는 얼마나 오래 보관해야 할까요?

AI 에이전트 감사 로그 보관 기간은 개인정보, 보안, 계약상 의무와 사고 조사에 필요한 기간을 기준으로 정해야 합니다. 누가 어떤 데이터에 접근했고 무엇을 실행했는지, 승인자와 결과를 함께 기록하세요. 로그에도 민감정보가 남을 수 있으므로 마스킹하고, 열람 권한을 제한해 원본의 신뢰성을 보호하는 것이 중요합니다.

참고 출처

• NIST CSRC, Least Privilege — https://csrc.nist.gov/glossary/term/least_privilege
• OWASP LLM06 Excessive Agency — https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
• OWASP AI Agent Security Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
• PCI Security Standards Council, PCI DSS — https://www.pcisecuritystandards.org/standards/pci-dss/
• NIST AI RMF Playbook — https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook
• OWASP Logging Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
• 개인정보보호위원회, 「개인정보의 안전성 확보조치 기준」 제8조 — https://www.law.go.kr/LSW/admRulSideInfoP.do?admRulSeq=2100000265956&chrClsCd=010201&dashNo=&docCls=jo&joBrNo=00&joNo=0008&urlMode=admRulScJoRltInfoR
• NIST AI RMF 1.0 — https://www.nist.gov/itl/ai-risk-management-framework