이 사건은 오직 주의 깊은 사람만이 프로덕션 키를 보유한다는 믿음을 바탕으로 AWS 액세스 모델을 구축해 온 팀에 경종을 울렸습니다. 이제 모든 개발자의 워크플로우에 AI 에이전트가 내재화되면서, 그 믿음은 틀린 것으로 드러났습니다. 회사는 모든 프로덕션 수준의 작업이 human-in-the-loop(사람의 개입) 승인 단계를 거치도록 강제하는 '액세스 브로커(access broker)'를 구축하여 대응했습니다.

사고가 발생한 경위

한 엔지니어가 AI 코딩 에이전트에게 파이프라인 스크립트를 생성하도록 프롬프트를 입력했습니다. 에이전트는 엔지니어의 프로덕션 IAM 역할(role)—CloudFormation 스택을 생성, 수정 및 삭제할 수 있는 AWS ID—을 상속받았습니다. 스크립트가 실행되어 라이브 환경에 스택을 생성한 후, 곧바로 '정리(cleanup)' 단계로서 이를 삭제했습니다. 이 작업은 표준 CI/CD 파이프라인을 우회했기 때문에, 일반적으로 이러한 변경을 제어하는 정책 엔진은 이를 감지하지 못했습니다.

승인된 파이프라인 외부에서 권한이 있는 작업을 수행하는 모든 역할을 플래그로 표시하도록 설정된 모니터링 플랫폼은 스택이 삭제되는 즉시 경고를 울렸습니다. 서비스 중단은 발생하지 않았지만, 이 경보는 잘못 입력된 리소스 이름이나 버그가 있는 AI 프롬프트가 중요한 인프라를 삭제할 수도 있었던 시나리오를 부각했습니다.

팀은 탐지가 곧 예방은 아니라는 사실을 깨달았습니다. 만약 AI가 잘못된 스택을 삭제했다면 재앙이 뒤따랐을 것입니다.

기존 자격 증명 모델이 실패한 이유

조직의 이전 방식은 다요소 인증(MFA)으로 보호되는 수명이 짧은 세션에 의존했습니다. 이론적으로는 개발자가 세션을 요청하여 작업을 수행하면 자격 증명이 자동으로 만료됩니다. 하지만 실제로는 노트북에서 세션이 시작되면 해당 기기가 켜져 있는 동안 계속 유지되었습니다. 테스트 스위트, 백그라운드 스크립트, 그리고 이제는 AI 에이전트에 이르기까지 모든 프로세스가 추가적인 확인 없이 해당 자격 증명을 재사용했습니다.

이러한 "ambient credential(상주 자격 증명)" 문제는 프로덕션 IAM 역할을 개발자의 워크스테이션에 고착시켰습니다. 동일한 셸에서 서브프로세스로 실행되는 AI 에이전트는 동일한 권한을 상속받았으며, 사람이 할 수 있는 것과 똑같이 프로덕션 리소스에 대해 작업을 수행할 수 있었습니다.

액세스 브로커: 새로운 게이트키퍼

상주 자격 증명의 연결 고리를 끊기 위해, 팀은 프로덕션 역할을 맡을 수 있는 대상을 재설계했습니다. 어떤 개발자 ID라도 직접 권한이 있는 역할을 맡게 하는 대신, 엄격하게 제어되는 단일 엔티티인 내부 액세스 브로커를 도입했습니다.

요청 흐름

  1. 웹 포털 – 엔지니어가 셀프 서비스 포털을 열어 필요한 액세스 수준(읽기 전용, 개발자 또는 관리자)을 선택하고 사유를 입력합니다.
  2. Slack 승인 – 요청이 지정된 승인자가 명시적으로 권한을 부여해야 하는 전용 Slack 채널에 게시됩니다.

Slack 단계는 AI 에이전트가 실행되는 터미널과는 다른 플랫폼에서 작동하는 2차 인증 요소 역할을 합니다. 승인이 별도의 UI에서 이루어져야 하므로, 자율적인 스크립트가 스스로 워크플로우를 완료할 수 없습니다.

계층형 액세스

  • 읽기 전용(Read-only) – 사용자는 리소스와 로그를 볼 수 있지만 아무것도 수정할 수 없습니다.
  • 개발자(Developer) – 지원 작업 및 인프라 수정을 위한 계층입니다. 이 계층은 스택 삭제나 고객 데이터에 대한 직접 액세스와 같은 파괴적인 작업을 차단합니다.
  • 관리자(Administrator) – 긴급 개입을 위해 예약된 전체 권한으로, 상위 수준의 검토를 거친 후에만 부여됩니다.

모든 프로덕션 액세스를 브로커를 통해 집중시킴으로써, 팀은 권한이 있는 자격 증명을 모든 노트북에 분산시키는 대신 단일하고 강력하게 방어되는 서비스로 위험을 집중시켰습니다.

브로커가 실제로 방지하는 것

브로커의 주요 목적은 AI 에이전트가 조용히 악용할 수 있는 **ambient credential(상주 자격 증명)**을 차단하는 것입니다. 사람이 요청을 승인하더라도 그 승인은 의식적인 결정이며, AI는 그 단계를 조작할 수 없습니다. 결과적으로:

  • 의도치 않은 삭제 – 사람이 세션을 명시적으로 승인하지 않는 한 AI는 더 이상 삭제 명령을 내릴 수 없습니다.
  • 자격 증명 확산(Credential sprawl) – 프로덕션 키가 더 이상 개발자 머신에 존재하지 않으므로, 노트북을 해킹할 수 있는 악의적인 내부자나 외부 공격자의 공격 표면이 줄어듭니다.

팀은 이 시스템이 인간의 실수를 완전히 제거하는 것은 아니라고 강조합니다. 잘못된 승인은 여전히 피해를 줄 수 있습니다. 하지만 인간의 확인 절차 없이 자율적인 코드가 프로덕션 리소스에서 작동하는 "조용한" 위험은 제거합니다.

시사점

AI 에이전트가 인간 엔지니어와 동일한 제한 없는 자격 증명을 부여받으면, 종종 아무도 모르는 사이에 운영 환경을 망가뜨릴 수 있는 권한을 갖게 됩니다. 별도의 인간 승인 채널을 강제하는 브로커를 통해 특권 액세스를 중앙 집중화함으로써, 팀은 인간의 실수가 여전히 문제를 일으킬 수 있음에도 불구하고 자율 스크립트가 조용히 난동을 부리는 것을 막을 수 있습니다. 진정한 보안상의 이점은 모든 개별 결정을 감시하는 것이 아니라, 주변 자격 증명(ambient credentials)을 제거하는 데 있습니다.