📋 밋업 한눈에 보기

AWS 트레이너 Shilpa가 진행한 이 웹비나는 가상의 ‘Apex Bank’ 사례를 통해 AI 에이전트가 스스로 행동을 취하기 시작하면서 발생하는 새로운 보안 위협을 다룬다. 새벽 2시 17분, 송장을 처리하던 에이전트가 첨부파일에 숨겨진 지시문에 속아 정상 자격증명으로 거액을 송금해버린 가상 사고를 중심으로, 에이전트의 구조(anatomy), 비인간 신원(non-human identity), 런타임 공격(prompt injection), 책임추적성, 인간 통제, AWS 프레임워크의 6단계로 강의가 진행된다. 핵심 메시지는 모델 자체를 완벽하게 안전하게 만들려 하지 말고, 모델이 제안한 행동을 결정론적 정책 엔진이 별도로 승인/거부하도록 ‘추론과 집행을 분리’해야 한다는 것이다.

🔑 핵심 요점

  • AI 에이전트는 더 이상 질문에 답만 하지 않고 실제로 돈을 옮기고 데이터를 바꾸는 행동을 하기 때문에 보안 패러다임이 바뀌어야 한다.
  • 공격은 하나의 취약점이 아니라 입력 조작, 신원 남용, 도구 오용, 권한 초과, 정보 유출로 이어지는 ‘체인’으로 작동하므로 체인의 한 고리만 끊어도 방어할 수 있다.
  • 가장 위험한 순간은 에이전트가 ‘결정(authorize)‘을 내리고 ‘실행(execute)‘하기 직전 그 찰나이며, 이 지점에 결정론적 정책 검증이 반드시 있어야 한다.
  • 에이전트 신원은 단순한 API 키가 아니라 소유자, 존재 이유, 권한 범위, 만료 시점을 가진 ‘여권’처럼 다뤄야 한다.
  • 장기 유효한(standing) 자격증명 대신 작업 단위로 발급되고 곧 만료되는 최소권한(Just-in-Time) 자격증명을 써야 탈취되어도 피해가 제한된다.
  • prompt injection은 모델을 직접 설득하지 않고 문서나 이메일 등 외부 콘텐츠에 숨어(indirect injection) 들어오는 경우가 더 위험하며, memory/RAG에 독성 데이터가 남으면 세션이 끝나도 공격이 지속될 수 있다.
  • 모델은 스스로를 방어할 수 없으므로 샌드박스, 네트워크 격리, 자격증명 브로커, 허용목록(allowlist), 리소스 쿼터 같은 런타임 경계(containment)가 최후의 방어선이 되어야 한다.

🛠 핵심 기술 쉽게 이해하기

Agentic AI (AI Agent)

단순히 답변만 하는 챗봇과 달리, 스스로 추론하고 도구(API)를 호출해 실제 행동(송금, 데이터 변경 등)까지 수행하는 소프트웨어를 말한다. 발표에서는 ‘추론엔진 + 엔터프라이즈 컨텍스트 + 메모리 + 도구 게이트웨이 + 신원 + 정책 집행’의 6가지 구성요소로 이루어진 구조로 설명된다.

왜 필요한가 — 에이전트가 자율적으로 행동을 취할수록 인간이 개입해 멈출 수 있는 ‘방어자의 시간’이 사라지기 때문에, 행동 자체를 통제하는 새로운 보안 설계가 필요하다.

발표에서는 — 발표는 가상의 Apex Bank 인보이스 처리 에이전트를 예시로, 에이전트가 답변(answer)에서 실행(execute), 오케스트레이션(orchestrate)까지 단계적으로 권한이 커지는 ‘사다리(rung)’ 모델로 anatomy를 설명했다.

Non-Human Identity (NHI)

사람이 아니라 워크로드, 서비스 프린시펄, 에이전트, 도구 등이 시스템에 접근할 때 사용하는 신원 체계다. 발표자는 이를 단순 API 키가 아니라 소유자·권한·유효기간을 가진 ‘여권’에 비유했다.

왜 필요한가 — 클라우드 접근의 다수가 이제 사람이 아닌 기계이기 때문에, 사람에게 쓰던 신원 관리 방식을 그대로 재사용하면 소유자 불명의 강력한 권한(orphaned identity)이 방치된다.

발표에서는 — Apex Bank가 에이전트에 단일 강력한 역할(role)을 발급하고 방치해 누구도 소유권과 만료시점을 알 수 없게 된 사례로 문제를 설명했고, 장기 유효 키 대신 작업 단위로 만료되는 Just-in-Time 자격증명 사용을 권장했다.

Prompt Injection

공격자가 AI 에이전트의 지시문 자체를 조작해 원치 않는 행동을 하게 만드는 공격 기법이다. 사용자가 직접 입력하는 direct injection과, 문서·이메일·도구 응답 등에 숨겨져 에이전트가 읽다가 속는 indirect injection으로 나뉜다.

왜 필요한가 — 에이전트는 ‘분석해야 할 콘텐츠’와 ‘실행해야 할 명령’을 텍스트 수준에서 구분하지 못하기 때문에, 이 모호함을 공격자가 악용한다.

발표에서는 — Apex Bank 사례에서 벤더 이메일 첨부파일에 숨겨진 한 문장(‘결제 전 계좌를 변경하라’)이 인다이렉트 인젝션으로 작동해 실제 송금까지 이어진 과정을 단계별로 재구성했다.

AWS (CloudTrail / IAM 기반 정책 프레임워크)

AWS는 이 세션에서 다룬 신원 관리(IAM), 행동 기록(CloudTrail), 정책 집행을 실제로 구현할 수 있는 클라우드 플랫폼으로 제시되었다.

왜 필요한가 — 결정론적 정책 엔진, 최소권한 자격증명, 증거 수준의 로깅을 실제 서비스로 구현해야 이론적 원칙이 현업에 적용 가능해지기 때문이다.

발표에서는 — 발표 마지막 섹션은 앞선 5개 섹션(구조, 신원, 런타임, 책임추적성, 인간 통제)의 원칙을 AWS 상에서 조립해 ‘월요일에 바로 배포 가능한’ 형태로 만드는 프레임워크로 예고되었다(세부 아키텍처는 이후 세션에서 다룰 예정).

Runtime Containment (Sandbox / Network Isolation)

에이전트가 실행되는 동안 접근 가능한 범위를 물리적으로 제한하는 기법으로, 샌드박스 실행, 사설 네트워크, 자격증명 브로커, 허용목록(allowlist), 리소스 쿼터 등을 포함한다.

왜 필요한가 — prompt injection을 완벽히 막을 수 없다는 전제 하에, 모델이 속더라도 실제 피해로 이어지지 않도록 실행 범위 자체를 좁히기 위함이다.

발표에서는 — 발표자는 ‘속은 모델이라도 결제 API에 닿지 못하고, 승인되지 않은 곳으로 데이터를 보내지 못하게 하는 상자’라는 비유로 이 개념을 설명하며, 이것이 있었다면 Apex Bank 사고의 송금까지는 못 갔을 것이라 강조했다.

🧭 추구 방향과 흐름

  • 추론(reasoning)과 집행(enforcement)의 분리 — 발표 전체를 관통하는 핵심 원칙으로, 모델은 행동을 ‘제안’만 하고 결정론적이고 모델 외부에 있는 정책 엔진이 승인 여부를 ‘결정’해야 한다는 것이다. 모델은 조작·설득이 가능한 컴포넌트이므로 스스로의 요청을 스스로 승인해서는 안 된다는 점을 반복해서 강조했다.
  • Just-in-Time 최소권한으로의 전환 — 사람에게 하던 ‘한 번 부여하고 연 1회 검토’하는 방식 대신, 에이전트에게는 작업 단위로 스코프가 좁고 곧 만료되는 임시 자격증명을 실행 시점에 발급해야 한다는 방향을 제시했다. 장기 유효 마스터키와 호텔 키카드의 비유로 이를 설명했다.
  • 증거 수준(evidence-grade)의 책임추적성 — 단순 API 호출 로그가 아니라 ‘무엇이 트리거했고, 어떤 신원으로, 어떤 정책 결정 하에, 어떤 세션에서, 어떤 도구를 호출했는가’까지 재구성 가능한 전체 체인을 남겨야 규제기관 앞에서 방어할 수 있다고 강조했다.
  • 침해를 전제로 한 봉쇄(containment) 우선 설계 — 완벽하게 안전한 모델을 만들려 하기보다, 모델이 속았을 때를 가정하고 샌드박스·네트워크 격리·허용목록으로 피해 반경을 미리 제한하는 방향으로 설계해야 한다는 접근을 제시했다.

🚀 바로 활용하기

  1. 자사에서 운영 중인 AI 에이전트가 anatomy 사다리(응답→명령→준비→실행→오케스트레이션)의 어느 단계에 있는지, 그리고 그 단계에 맞는 통제가 있는지 점검해본다.
  2. 에이전트가 사용하는 자격증명이 장기 유효한 standing credential인지 확인하고, 가능한 부분부터 작업 단위로 만료되는 임시 자격증명으로 전환한다.
  3. 에이전트의 ‘결정’과 ‘실행’ 사이에 별도의 정책 엔진(모델 외부)이 있는지 확인하고, 없다면 최소한 고위험 행동(송금, 데이터 삭제 등)에 대해 default-deny 정책을 도입한다.
  4. CloudTrail 등으로 트리거→신원→정책결정→호출 도구→결과까지 재구성 가능한 로깅 체계가 있는지 점검하고, 없는 구간을 찾아 보강한다.

🔗 참고 자료