wyzz.log

17. 제로트러스트와 AI 에이전트 접근제어

8 min read

왜 지금 이 얘기를 해야 하나

07-에이전틱 AI와 MCP 보안과 14-AI 에이전트가 선을 넘을 때에서 계속 반복된 결론이 하나 있다 — “에이전트에게 얼마나 좁은 권한을 줄 것인가”가 사실상 모든 사고 시나리오의 분기점이었다는 것 이번 글은 그 질문에 정면으로 답하는 프레임워크, 제로트러스트를 AI 에이전트 영역으로 확장하는 논의를 정리함

배경이 되는 숫자도 있음 기업 내 비인간 신원(서비스 계정, API 키, 인증서, 머신 토큰)이 매년 40% 이상 증가하면서 일부 조직에서는 인간 신원 대비 40:1, 많게는 100:1 비율까지 벌어졌다고 함 여기에 자율적으로 도구를 호출하는 에이전트까지 더해지면, “이 신원이 지금 무슨 권한으로 뭘 하고 있는지”를 사람이 실시간으로 파악하기가 사실상 불가능해짐

기존 제로트러스트와 무엇이 다른가

제로트러스트 자체는 새 개념이 아니다 — “암묵적 신뢰 없음, 모든 요청을 매번 검증”이라는 원칙(NIST SP 800-207)은 이미 사람·기기 대상으로 정착되어 있음 2026년 시점에 달라진 것은 에이전트가 더 이상 수동적인 “도구”가 아니라 워크플로우의 능동적 참여자로 취급되어야 한다는 인식임

구분사람/기기 대상 제로트러스트AI 에이전트 대상 제로트러스트
신원 수명계정 단위로 길게 유지세션·작업 단위로 짧게, 필요 시 즉시 폐기
권한 부여 시점사전에 역할(role) 기반으로 고정작업 시작 시점에 의도(intent) 기반으로 동적 발급
위임 체인단순 (사람→시스템)복잡 (사용자→에이전트→하위 에이전트→도구, 다단계)
모니터링 대상로그인·접근 이벤트도구 호출 하나하나, 프롬프트-액션 인과관계

핵심 구성요소

에이전트 신원(Agent Identity): 각 에이전트에게 사람 계정을 재사용시키지 않고, SPIFFE/SPIRE가 발급하는 단명(short-lived) 암호학적 신원(SVID) 같은 워크로드 고유 신원을 부여함 이렇게 하면 어떤 요청이 “사람이 직접” 한 것인지 “에이전트가 대신” 한 것인지, 그리고 어떤 에이전트인지가 로그에 명확히 남음

위임 체인 보존: 사용자가 에이전트에게, 에이전트가 다시 하위 에이전트나 MCP 서버에 권한을 위임하는 다단계 구조에서는 “누구를 대신해 행동하는지”가 중간에 유실되기 쉽다(컨퓨즈드 디퓨티 문제와 연결) OAuth 2.0 Token Exchange(RFC 8693)의 act 클레임처럼 위임 주체를 토큰에 명시적으로 남기는 방식이 대안으로 제시됨

JIT(Just-In-Time) 접근: 상시 권한(standing privilege) 대신, 작업이 시작될 때 의도를 선언하고 그 작업에 필요한 범위·시간만큼만 권한을 발급한 뒤 종료 즉시 회수함 사고가 나도 노출되는 권한의 폭발 반경이 줄어듦

성숙도 등급화: CSA의 Agentic Trust Framework(ATF)는 에이전트를 접근 범위에 따라 “인턴급”부터 “프린시펄급(핵심 시스템 접근)“까지 단계별로 분류하자고 제안한다 — 사람 조직의 직급·권한 체계를 에이전트에도 그대로 적용하는 접근임

현실은 아직 따라가지 못한다

2026년 조사에 따르면 배포된 AI 에이전트 중 실제로 모니터링·보안 통제가 적용된 비율은 절반이 안 된다는 보고도 있음 프레임워크는 빠르게 나오는데 실제 구현은 뒤처지는 전형적인 과도기 국면

참고할 표준/프레임워크

  • NIST SP 800-207 (Zero Trust Architecture) — 원조 제로트러스트 표준, 에이전트 확장 논의의 기반
  • OWASP Top 10 for Agentic Applications — 에이전트 특화 위협 분류 (06-OWASP Top10 for LLM 정리의 에이전트 버전)
  • CSA Agentic Trust Framework(ATF) — 에이전트 성숙도·권한 등급 모델
  • SPIFFE/SPIRE, OAuth 2.0 Token Exchange(RFC 8693), SCIM — 실제 구현에 쓰이는 오픈 표준들

대응 방향

  • 인벤토리부터: 조직 내 모든 AI 에이전트·머신 신원을 목록화 — 뭐가 있는지 모르면 통제도 불가능 (08-Shadow AI와 데이터 유출 대응과 같은 맥락)
  • 신원 정책 수립: 에이전트별 고유 신원, 생성·폐기 라이프사이클 정의
  • 최소 권한 + JIT: 상시 권한을 없애고 작업 단위로 동적 발급
  • 위임 체인 명시화: 다단계 호출에서도 “원래 누구 대신”인지 토큰에 남기기
  • 도구 호출 단위 모니터링: 로그인 이벤트가 아니라 각 도구 호출·액션 단위로 이상 탐지

더 생각해볼 것들

  • 우리 조직에 이미 존재하는 AI 에이전트(RPA, 챗봇, 코드어시스턴트 포함)를 지금 다 나열할 수 있을까
  • JIT 접근을 도입하면 “속도”라는 에이전트의 장점과 “매번 승인/검증”이라는 보안 요구가 충돌하지 않을까 — 그 균형은 어디서 잡아야 할까
  • 성숙도 등급화(인턴급~프린시펄급)를 실제 사내 에이전트에 적용해본다면 지금 우리 에이전트들은 어느 등급쯤 될까

Sources:

Backlinks