AI Agent 최소 권한 실천：능력 태그 기반 인가 모델 · Insights

'일단 돌리기'가 남기는 부채

Agent 도입은 대개 이런 경로를 따릅니다. 쓸 수 있는 토큰을 주고, 업무 흐름을 통과시키고, 가치를 확인하고, 운영에 올립니다.

이 경로 자체가 틀린 것은 아닙니다. 가치 검증을 먼저 하는 것은 타당한 공학적 판단입니다. 문제는 다음 단계입니다. 권한을 나중에 다시 조인 팀이 거의 없다는 점입니다. 디버깅 편의로 건넨 조직 전체 통용 토큰이 그대로 Agent와 함께 운영 환경으로 들어갑니다.

그 결과는 이론상의 이야기가 아닙니다. Agent의 행위는 코드로 고정되지 않고 모델이 동적으로 결정합니다. 즉 '지금 할 수 있는 것'과 '앞으로 할 일' 사이에 확정적인 대응 관계가 없습니다. 작업에 필요한 범위를 넘는 권한을 쥐여줄 때, 실질적으로는 모델의 판단력을 보안 경계로 쓰고 있는 셈입니다. 그리고 그 모델의 판단력이야말로 프롬프트 인젝션이 노리는 대상입니다.

기존 IAM으로 부족한 이유

기업에는 성숙한 ID·접근 관리 체계가 있지만, 그대로 Agent에 적용하면 세 가지 어긋남이 생깁니다.

주체가 안정적이지 않습니다. IAM은 주체(사용자, 서비스)의 행동 양식이 비교적 고정되어 있다고 전제합니다. Agent의 행위는 작업, 맥락, 모델 버전에 따라 달라지므로 정적 역할로 기술하는 것 자체에 무리가 있습니다.

권한 단위가 맞지 않습니다. IAM은 보통 리소스와 작업 단위로 인가합니다(“S3 버킷 X를 읽을 수 있음”). 반면 Agent의 리스크 단위는 능력입니다(“임의의 로컬 파일을 읽을 수 있음”, “외부로 통신할 수 있음”). 같은 능력이 여러 도구와 리소스에 걸칠 수도 있고, 하나의 도구가 여러 능력을 동시에 가질 수도 있습니다.

인가 시점이 다릅니다. 기존 인가는 도입 시점의 일회성 판단입니다. Agent 생태계에서는 도구가 수시로 추가·삭제되고 MCP Server는 조용히 갱신됩니다. 권한 면이 계속 움직이므로 필요한 것은 한 번의 승인이 아니라 지속적인 평가입니다.

능력 태그: '무엇을 할 수 있는가'를 표준화하기

현실적인 방법은 도구와 권한 사이에 추상화 층을 두는 것입니다. 그것이 능력 태그입니다.

“이 MCP Server의 이름이 무엇인가”가 아니라 “활성화되면 Agent가 어떤 능력을 얻는가”를 묻고, 그 답을 태그 집합으로 표준화합니다. 대표적인 능력 영역은 다음과 같습니다.

파일 시스템: 임의 경로 읽기 / 지정 디렉터리 읽기 / 쓰기 / 삭제
프로세스 실행: 셸 명령 / 자식 프로세스 생성
네트워크: 외부 요청 / 포트 수신 / 내부망 접근
자격 증명: 환경 변수 읽기 / 비밀 저장소 접근 / 기존 세션 사용
데이터 작업: 영속 데이터 읽기 / 수정 / 삭제
대외 통신: 메일 발송 / 콘텐츠 게시 / 결제 실행

이 어휘의 가치는 비교 가능하고 정책화할 수 있다는 점에 있습니다. “셸 실행 태그를 가진 도구는 모두 사람의 승인을 거친다”고 정하면 도구마다 논의할 필요가 없습니다. 도구 갱신 후 태그를 다시 붙이고, 태그 변화를 재평가의 계기로 삼을 수도 있습니다. 선언된 능력이 바뀌었다면 리스크 면이 바뀐 것입니다.

인가의 3원칙

1. 도구 단위가 아니라 작업 단위로 인가합니다.

Agent가 완료해야 할 작업에 어떤 능력이 필요한지 먼저 정의하고, 그에 따라 도구와 자격 증명을 고릅니다. 이 순서가 중요합니다. 반대로 — 도구를 먼저 고르고 그것이 요구하는 권한을 보는 방식 — 하면 거의 확실히 과도한 인가에 이릅니다. 도구 제작자는 더 많은 상황을 덮기 위해 더 넓은 권한을 요구하는 경향이 있기 때문입니다.

2. 능력 조합에 주의합니다.

단독으로는 무해한 능력도 조합하면 그렇지 않습니다. “로컬 파일 읽기”와 “외부 요청”을 합치면 데이터 반출 능력이 되고, “환경 변수 읽기”와 “셸 실행”을 합치면 자격 증명 탈취와 횡적 이동이 됩니다. 인가 심사는 능력 집합의 상호작용을 봐야 하며, 항목마다 체크하는 작업으로는 부족합니다.

실제 사고의 상당수가 여기서 비롯됩니다. 개별 도구는 모두 타당해 보이는데, 합쳐졌을 때 완전한 공격 경로가 열립니다.

3. 비가역적 작업은 별도로 관문을 둡니다.

삭제, 결제, 대외 발송, 운영 설정 변경. 이들의 공통점은 실수를 되돌릴 수 없다는 것입니다. 일반 권한에서 떼어내, Agent가 아무리 신뢰받더라도 명시적 확인이나 독립적 승인을 요구해야 합니다.

구현: 세 단계

도입 시: 각 도구/MCP Server에 능력 감사를 수행하고, 태그 집합을 만들고, 선언과 구현을 대조합니다(캘린더만 읽는다는 도구의 구현에 파일 쓰기 능력이 있다면, 그 불일치 자체가 리스크 신호입니다). 여기서 block / need_review / pass 판정을 산출합니다.

실행 시: 자격 증명을 Agent별·작업별로 분리하고, 범위를 최소화하며, 개별 폐기가 가능하게 합니다. 네트워크 아웃바운드 허용 목록을 최후의 방어선으로 둡니다. 도구가 오염되어도 데이터는 나갈 수 없습니다.

지속적으로: Agent의 실제 도구 호출을 기록하고 인가 범위와 대조합니다. 오랫동안 쓰이지 않은 능력은 회수해야 합니다. 가장 간과되기 쉬우면서 비용이 가장 낮은 조이기 수단입니다. 도구 버전이 바뀌면 재평가를 촉발합니다.

'쓸 수 있는가'에서 '무엇을 할 수 있는가'로

Agent 보안의 중심 질문은 “이 도구가 악의적인가”에서 “이 도구가 활성화되면 Agent가 승인을 요하는 어떤 능력을 얻는가”로 옮겨가고 있습니다. 앞의 것은 악성 탐지의 문제이고, 뒤의 것은 능력 감사의 문제입니다. 그리고 기업의 도입 판단이 필요로 하는 것은 뒤의 답입니다.

이것이 SkillSec의 방법론적 토대입니다. Agent 생태계의 컴포넌트(Skills, MCP Server)를 능력 영역별로 분해하고 등급이 매겨진 증거로 판정을 뒷받침해, 권한 판단을 '악해 보이는가'가 아니라 '무엇을 할 수 있는가' 위에 세웁니다.

최소 권한은 새로운 개념이 아닙니다. Agent 맥락에서 더 어려워지고 더 중요해졌을 뿐입니다. 이번에는 권한을 받은 주체가 스스로 무엇을 할지 결정하기 때문입니다.

---