속을 수밖에 없는 에이전트에 열쇠를 맡겼다
프롬프트 인젝션은 공격자가 문서, 웹페이지, 데이터베이스 레코드 같은 입력에 지시문을 숨겨 AI 에이전트의 행동을 바꾸는 공격이다. 언어모델은 자연어로 된 지시와 데이터를 구조적으로 확실히 구분하지 못한다.
이 취약점은 추가 학습이나 검색증강생성으로도 사라지지 않았다. 영국 국가사이버보안센터는 2025년 12월 완전히 해결되지 않을 수도 있다고 경고했고, OWASP는 이를 언어모델 애플리케이션 취약점 1위로 분류한다. 보안 설계는 에이전트가 속은 뒤까지 감당해야 한다.
그런데 에이전트에 넓은 권한을 주고 사용자별 접근 허용 여부를 에이전트 코드가 판단하게 하면 해당 코드 하나의 실패로 보호 장치 전체가 무효가 된다. 공격자가 판단 로직을 우회하는 순간 에이전트의 자격증명으로 접근 가능한 데이터가 노출될 수 있다.
그렇다면 현장 관행은 어떨까? API 관리 기업 Gravitee는 2026년 2월 실무자와 경영진 900여 명을 조사했다.
- 에이전트를 독립된 신원으로 관리하는 조직은 21.9%였고, 45.6%는 여러 에이전트의 인증에 공유 API 키를 썼다.
- 27.2%는 인가 규칙을 코드에 직접 넣었으며 88%는 지난 1년간 관련 사고를 확인했거나 의심했다.
에이전트의 권한을 애플리케이션 내부에서 관리하는 관행이 여전히 널리 쓰인다는 말이다.
에이전트 손이 닿지 않는 곳에 자물쇠를 걸어라
권한 판정을 에이전트 밖으로 빼면 어떻게 될까? AWS가 2026년 8월 공개한 설계는 에이전트를 도구 호출과 추론을 조율하는 구성요소로만 둔다. 데이터 접근 권한은 인프라와 외부 서비스가 판정한다.
사용자가 로그인하면 인증 서비스가 부서 정보와 함께 로그인 사용자를 증명하는 신원 토큰을 발급한다. 에이전트는 데이터베이스에 접속할 때 자체 자격증명 대신 이 토큰을 권한 발급 서비스에 제출한다.
발급 서비스는 부서 정보가 표시된 임시 자격증명을 내준다. 데이터베이스 정책은 해당 정보와 일치하는 영역만 읽도록 제한한다. 자물쇠가 에이전트 손이 닿지 않는 층에 걸린 구조다.
가령 영업부 사용자의 에이전트가 숨은 지시문에 속아 재무부 데이터를 요청해도 자격증명에는 영업부 정보만 들어 있다. 질의가 실제로 실행돼도 데이터베이스의 권한 정책이 거부한다. 에이전트 코드가 조작된 상황에서도 부서 간 접근은 차단된다.
외부 고객관리 시스템으로 넘어가도 원리는 같다. 사용자의 신원 토큰을 해당 서비스용 사용자 토큰으로 교환해 전달한다. 조회문에 부서 조건을 넣지 않아도 고객관리 시스템의 공유 규칙이 사용자에게 허용된 레코드만 반환한다. 접근 통제가 에이전트의 올바른 판단에 의존하지 않는다.
에이전트가 아니라 데이터가 흐르는 길을 점검하라
그런데 모든 데이터 경로가 같은 수준으로 보호되지는 않는다. 사내 문서를 찾는 지식베이스에서는 에이전트가 사용자의 부서 정보를 읽고 검색 요청에 메타데이터 필터, 곧 문서 분류 조건을 직접 붙인다.
AWS도 이 방식을 인프라가 아닌 애플리케이션 계층의 통제로 분류한다. 더 엄격한 격리에는 부서별 지식베이스와 개별 권한 정책을 제안했다.
그러나 기본 경로에는 구멍이 남는다. 에이전트가 필터를 누락하거나 바꾸면 요청을 거부할 인프라 계층의 통제가 없다. 같은 시스템에서도 데이터베이스와 외부 고객관리 시스템은 잘못된 요청을 차단하지만 지식베이스는 에이전트 코드의 올바른 동작에 의존한다.
따라서 검토 단위는 에이전트 전체가 아니라 사용자 요청이 각 저장소에 닿는 경로다. 권한, 감사, 규제 대응도 프롬프트를 다듬는 작업만으로 해결되지 않는다. 사용자 신원을 저장소까지 전달할 수 있는지, 최종 접근 허용을 어느 계층이 판단하는지에 따라 통제 수준이 달라진다.
실제 운영 설계는 에이전트가 언젠가 조작될 가능성을 전제로 삼는다. 각 경로의 안전성은 조작된 에이전트가 보낸 요청을 저장소나 외부 서비스의 권한 정책이 거부할 수 있는지로 결정된다. 거부하지 못하는 경로에서는, 그 보호도 함께 사라진다.