아마존 베드로크 에이전트코어 게이트웨이에서 정책과 람다 인터셉터를 사용한 AI 에이전트 보안

Amazon Bedrock AgentCore의 게이트웨이는 AI 에이전트가 외부 도구(MCP 서버, Lambda 함수, API 등)에 접근할 때 그 경로를 중앙에서 통제하는 관문 역할을 한다. 이번에 소개된 두 가지 인터셉터는 그 관문에서 요청을 가로채 검증하는 메커니즘이다. **Policy 인터셉터**는 IAM이나 Cedar 정책처럼 미리 정의된 규칙으로 "누가 어떤 리소스에 접근 가능한가"를 정적이고 결정론적(deterministic)으로 판단한다. 즉 동일한 입력에는 항상 동일한 허용/거부 결과가 나온다. 반면 **Lambda 인터셉터**는 요청 시점에 Lambda 함수를 실행해 동적(dynamic)으로 검증한다. 요청 파라미터의 실제 값, 호출 컨텍스트, 외부 상태 등을 런타임에 평가할 수 있어 정적 정책만으로는 표현하기 어려운 조건부 로직을 처리한다. 글에서 예로 든 레이크하우스 데이터 에이전트는 이 두 계층을 결합해, 먼저 Policy로 "데이터 접근 권한 자체가 있는가"를 거른 뒤 Lambda로 "이 요청이 지리적 제약 조건을 위반하지 않는가"를 검증하는 지역 기반 접근 제어(geography-based access control)를 구현한다.

기술적으로 핵심은 이 두 방식의 **역할 분리와 조합**이다. 결정론적 정책은 감사(audit)와 추론이 쉽고 성능 오버헤드가 거의 없지만 표현력이 제한적이다. 동적 Lambda 검증은 유연하지만 매 요청마다 함수 실행 비용과 지연(latency)이 발생하고, 로직이 복잡해질수록 검증 자체가 버그의 온상이 될 수 있다. AgentCore는 둘을 파이프라인으로 엮어 "정적 게이트로 대부분을 거른 뒤, 통과한 요청에만 비싼 동적 검증을 적용"하는 방어 심층화(defense-in-depth) 패턴을 제공한다. 지역 기반 접근 제어가 좋은 사례인 이유는, "EU 사용자 데이터는 EU 리전에서만"처럼 정적 권한 확인과 런타임 데이터 분류가 모두 필요한 규제 요건을 한 흐름 안에서 처리할 수 있기 때문이다.

엔지니어에게 이것이 갖는 실질적 의미는, AI 에이전트의 보안이 이제 "프롬프트로 잘 타이르기"에서 "인프라 레벨의 강제(enforcement)"로 넘어가고 있다는 점이다. LLM 기반 에이전트는 비결정적이라 프롬프트만으로는 권한 경계를 보장할 수 없다. 인터셉터는 에이전트의 추론 결과와 무관하게 게이트웨이 차원에서 도구 호출을 차단하므로, 프롬프트 인젝션이나 에이전트의 오작동으로 인한 무단 데이터 접근을 구조적으로 막아준다. 특히 GDPR·데이터 주권(data sovereignty) 같은 규제를 받는 금융·의료·공공 도메인에서 에이전트를 운영하려는 팀이라면, 접근 제어를 애플리케이션 코드가 아닌 게이트웨이 정책으로 외부화함으로써 감사 추적성과 변경 용이성을 크게 높일 수 있다.

개발자가 실제로 챙겨야 할 점은 다음과 같다. 첫째, **정적 규칙으로 표현 가능한 것은 최대한 Policy로 밀어내고**, 런타임 값에 의존하는 검증만 Lambda 인터셉터에 남겨야 한다 — 모든 검증을 Lambda에 몰면 지연과 비용, 검증 코드의 복잡도가 동시에 커진다. 둘째, Lambda 인터셉터는 그 자체가 보안 경계이므로 입력 검증·예외 처리·실패 시 기본 거부(fail-closed) 원칙을 엄격히 적용하고, 콜드 스타트로 인한 지연을 고려해야 한다. 셋째, AgentCore는 현재 AWS 종속적 기능이므로, 멀티 클라우드나 자체 호스팅 환경을 쓰는 팀은 동일한 "정적 정책 + 동적 검증" 패턴을 OPA(Open Policy Agent)나 자체 MCP 게이트웨이로 이식할 수 있는지 검토해 보는 것이 좋다. 핵심 교훈은 도구 자체보다 그 설계 철학 — 에이전트 보안은 모델을 신뢰하지 말고 호출 경로에서 강제하라는 것 — 에 있다.