AI 에이전트 권한 관리: 작업 단위로 권한을 주는 법

에이전트에게 스프레드시트 하나를 맡기려고 연결 화면을 열면, 선택지가 두 개뿐인 경우가 많습니다. 드라이브 전체에 대한 권한을 주거나, 그 파일을 "링크가 있는 누구나 편집"으로 열어 두거나. 2026년 9월 Hacker News에 올라온 한 질문이 딱 이 상황이었습니다. 파일 하나면 되는데 계정 전체를 넘겨야 하는 구조입니다.

AI 에이전트 권한 관리는 에이전트가 어떤 데이터와 도구에, 누구의 이름으로, 언제까지 접근할 수 있는지를 정하고 기록하는 일입니다. 기업에서는 이 문제가 더 커집니다. 에이전트를 ERP에 연결하면서 서비스 계정을 하나 만들고, 그 계정에 많은 권한을 몰아주는 식입니다. 에이전트가 무엇을 할지 미리 다 알 수 없으니 일단 권한을 많이 주는 건데, 이렇게 한번 준 권한은 좀처럼 다시 줄어들지 않습니다.

사람 권한 관리와 무엇이 다를까요?

사람의 권한은 직무에 따라 다릅니다. 재무팀 직원은 재무 시스템에 들어가고, 하는 일이 바뀌면 권한도 바뀝니다. 한 사람이 처리하는 양에는 한계가 있고, 특이한 상황이 생기면 동료가 눈치채거나, 행정상 결재 라인에서 눈에 보일 수밖에 없습니다.

AI Agent는 한 번 받은 권한 안에서 쉬지 않고, 사람보다 훨씬 빠르게 일합니다. 권한이 많으면 실수 한 번으로 생기는 피해도 그만큼 커집니다. OWASP는 LLM 애플리케이션 10대 위험 목록(2025년판)에 이 문제를 "Excessive Agency(과도한 행위 능력)"라는 항목으로 올렸고, 원인으로 아래 세 가지를 얘기했습니다.

• 과도한 기능: 메일을 읽는 도구인데 삭제와 발송까지 할 수 있는 경우
• 과도한 권한: 조회만 하면 되는데 DB 쓰기와 삭제 권한까지 있는 경우
• 과도한 자율: 문서 삭제처럼 영향이 큰 행동을 사람 확인 없이 실행하는 경우

모두 모델 성능과는 관계가 없고, 에이전트에게 어떤 권한을 허용했느냐에서 생기는 문제입니다.

금융권이 정한 MCP 도입 조건

국내에서는 금융권이 이 문제를 가장 구체적으로 정리했습니다. 바이라인네트워크가 9월 29일 보도한 KB데이터시스템의 금융 보안 콘퍼런스 발표(2026년 9월 22일, 여의도)에 따르면, 금융권이 MCP를 도입할 때는 아래 조건을 갖춰야 합니다.

신원 전파

직원이 로그인한 신원이 에이전트의 도구 실행까지 그대로 이어져야 합니다. SSO와 IAM에 연결해 두면, 에이전트가 누구를 대신해 작업했는지가 기록으로 남습니다. 공용 서비스 계정을 쓰면 직원 본인에게 없는 권한을 에이전트를 거쳐 쓰게 되는 문제가 생깁니다.

도구 노출 제어

직무에 따라 쓸 수 있는 도구를 제한합니다. 재무 에이전트 권한만 있는 직원은 감사 에이전트의 도구를 쓰지 못하게 하는 식입니다. 권한을 확인하는 단계보다 앞에서, 도구 목록에 아예 보이지 않게 합니다.

읽기와 쓰기 분리

잔액 조회 같은 읽기는 에이전트가 자동으로 처리하고, 이체나 승인처럼 상태를 바꾸는 작업은 사람의 승인을 받습니다. 같은 에이전트가 하는 일이라도 영향이 얼마나 큰지에 따라 다르게 하는 겁니다.

승인 레지스트리와 호출 기록

내부 검증을 거친 도구만 화이트리스트로 등록하고, 모든 호출에 대해 주체, 대상, 오간 데이터, 플랫폼을 기록합니다.

발표의 요지는 에이전트에게 무엇을 맡길지 정하기 전에, 데이터 접근 통제부터 설계해야 한다는 것입니다.

이 조건을 한 번에 다 갖출 필요는 없습니다. 이체, 외부 발송, 고객 정보 조회처럼 사고가 났을 때 비용이 큰 업무부터 적용하고, 내부 문서 요약 같은 업무는 기록만 남기는 것부터 시작해도 됩니다.

작업 단위 권한이란?

여기서 더 나아가면 권한을 주는 단위가 바뀝니다. 시스템마다 권한을 주던 방식이, 작업 하나마다 필요한 만큼만 주고 작업이 끝나면 회수하는 방식으로 바뀝니다.

1Password CTO Nancy Wang은 2026년 9월 28일 Okta의 Oktane 행사에서 이 방식을 소개했습니다. 에이전트에게는 작업 하나에 필요한 권한만 그때그때 주고, 비밀번호 같은 자격 증명은 에이전트나 모델에 보여 주지 않은 채 필요한 순간에만 쓰게 합니다. 그는 이를 인턴에 비유했습니다.

Just like you would verify whatever an intern does before you allow them to move on to the next project, [it's the] same thing with agents.

보안 기업 Orchid Security가 The Hacker News에 기고한 에이전트 IAM 정리도 방향이 같습니다(자사 제품 영역을 다룬 기고문이라는 점은 감안해서 읽을 필요가 있습니다). 에이전트마다 구별되는 신원을 주고, 권한은 작업이 끝나면 만료되게 하고, 모든 행동을 기록해 곧바로 회수할 수 있어야 한다는 내용입니다. 이 글은 공용 서비스 계정도, 사람의 계정을 빌려 쓰는 것도 허용하지 않습니다.

작업 단위로 권한을 주면 사고 조사도 쉬워집니다. 예를 들어 에이전트가 전표를 잘못 수정했다면, 그 에이전트가 가진 권한 전체를 뒤질 필요 없이 그 작업에 허용된 권한만 보면 됩니다.

실전에서 자주 하는 실수

읽기와 쓰기가 한 도구에 섞인 경우

도구 목록을 직무별로 제한해도, 도구 하나가 조회와 삭제를 함께 제공하면 소용이 없습니다. OWASP가 "과도한 기능"을 따로 분류한 이유입니다. 도구를 등록할 때부터 읽기용과 쓰기용을 나눠 두면, 나중에 권한을 나누는 것보다 훨씬 수월합니다.

승인 요청이 너무 많은 경우

쓰기 작업마다 사람의 승인을 받게 하면 안전해 보입니다. 그런데 승인 요청이 하루 수백 건씩 쌓이면, 사람은 내용을 읽지 않고 누르기 시작합니다. 승인 대상은 되돌릴 수 없는 작업(외부 발송, 이체, 삭제, 권한 변경)으로 한정하고, 되돌릴 수 있는 작업은 기록과 사후 검토로 넘기는 편이 실제로는 더 안전합니다. 사후 검토를 어떻게 설계하는지는 에이전트 거버넌스 글에서 다뤘습니다.

권한을 시스템 이름으로 적은 경우

"ERP 읽기", "CRM 쓰기"로 권한을 적어 두면 작업 단위로 나눌 방법이 없습니다. 에이전트가 실제로 처리하는 건 그 안의 주문, 고객, 전표 같은 업무 대상인데, 권한 목록에는 그 단위가 없기 때문입니다.

하이퍼이지는 어디를 맡나요?

어떤 직무에 어떤 권한을 줄지는 최종적으로 고객사 보안·컴플라이언스 조직이 결정합니다. 하이퍼이지의 FDE는 현장에서 그 정책을 함께 설계하고, 정책을 업무 대상 기준으로 옮겨 적고 시스템에 반영하는 일을 맡습니다. 예를 들어 "ERP 쓰기" 대신 "이번 달 미결 전표 조회", "특정 전표의 상태 변경 요청"처럼 권한을 나눠 적습니다. 이렇게 적어 두면 무엇을 자동으로 처리하고 무엇에 승인을 받을지가 드러나고, 작업이 끝났을 때 무엇을 회수할지도 분명해집니다.

이렇게 하려면 업무 대상이 먼저 정의돼 있어야 합니다. Skein OS는 기업의 주문, 설비, 계약 같은 업무 대상과 그 관계를 온톨로지로 정의하고, 그 위에 54종 이상의 MCP 커넥터를 올립니다. 권한을 커넥터마다 설정하는 대신 온톨로지 객체와 행동 단위로 설정할 수 있는 이유입니다. MCP 도입의 전체 그림은 MCP로 기업 AI를 운영하는 법에 정리해 두었습니다.

자주 묻는 질문

에이전트가 몇 개 안 되는데도 권한 관리가 필요한가요?

에이전트 수보다 에이전트가 무엇을 바꿀 수 있는지가 기준입니다. 조회만 하는 에이전트 한두 개라면 호출 기록부터 남기는 것으로 충분합니다. 외부 발송이나 데이터 수정이 가능한 에이전트라면, 하나라도 읽기와 쓰기를 나누는 게 좋습니다.

기존 IAM으로 해결되지 않나요?

신원 확인과 역할 기반 권한은 기존 IAM을 그대로 씁니다. 다만 기존 IAM은 사람이 로그인해서 일하는 속도를 전제로 설계돼 있어, 작업마다 권한을 주고 회수하거나 에이전트별로 호출을 기록하는 부분은 따로 설계가 필요한 경우가 많습니다.

어디서부터 시작하면 되나요?

지금 에이전트가 쓰고 있는 계정과 도구를 목록으로 만드는 것부터 시작합니다. 공용 서비스 계정이 있다면 먼저 에이전트별 신원으로 나누고, 그다음 쓰기 권한이 있는 도구를 찾아 승인 대상을 정합니다.

정리

에이전트 권한 관리는 "에이전트에게 무엇을 시킬까"보다 "이 작업에 무엇이 필요한가"부터 따져 보는 일입니다. 권한을 시스템 이름 대신 업무 대상 기준으로 적어 두면, 에이전트를 여러 업무에 쓰면서도 작업 하나에 허용하는 권한은 꼭 필요한 만큼으로 제한할 수 있습니다.