Securing AI agent identity with X.509 PKI on AWS

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS와 Keyfactor EJBCA의 참조 아키텍처는 X.509 PKI, 서명된 요청, 사용자 위임, 대상 제한 토큰, 실시간 OCSP 검증을 결합해 AI 에이전트의 신원과 도구 접근 권한을 확인한다.

📌 핵심 요약

• 원문은 공유 API 키나 에이전트 체인을 통한 OAuth 토큰 전달만으로는 기업의 제로 트러스트 요구를 충족하기 어렵다고 지적하고, 자체 인증 표준이 없는 MCP 환경에 암호학적 신원 확인을 적용하는 방안을 제시한다.
• AWS와 Keyfactor가 공동 개발한 참조 아키텍처는 Keyfactor EJBCA를 인증서 발급·폐기 확인에 사용하고, Amazon Bedrock과 AWS Strands Agents SDK로 LLM 추론을 수행한다. 보호 자원은 Amazon RDS for MySQL이며, 같은 인증 패턴을 다른 MCP 호환 도구 서버에도 적용할 수 있다고 설명한다.
• 로그인 과정에서는 RFC 8693 토큰 교환으로 MCP 서버에만 유효한 토큰을 만들고, 로컬에서 생성한 RSA 2048비트 이상 키와 CSR로 X.509 인증서를 발급받는다. 사용자는 세 에이전트 인증서의 SHA-256 지문을 담은 위임 문서에 서명하며, 에이전트에는 사용자 개인 키나 전체 세션 OAuth 토큰을 공유하지 않는다.
• 에이전트 간 요청은 RSA-PSS-SHA256으로 서명된 봉투에 도구 이름, 인수, 타임스탬프, 무작위 nonce를 포함한다. 수신자는 서명, 기본 60초의 시간 유효성, nonce 중복 여부, CA 신뢰 체인, 역할, OCSP 폐기 상태를 검증하고, 재전송에도 새로운 nonce를 요구한다.
• MCP 서버인 FastMCP는 도구 호출마다 네 가지 검증을 수행한다고 소개된다. 제공된 본문에는 토큰 활성 상태·audience 확인과 서명 봉투 검증이 설명되어 있지만, 사용자 위임 검증 설명 도중에 끊겨 있어 세 번째 검증의 전체 내용과 네 번째 검증의 세부 사항은 확인할 수 없다.

🧩 주요 포인트

1. 사용자→시스템, 에이전트→에이전트, 에이전트→도구 서버의 세 신뢰 경계를 구분함으로써 사용자 인증, 요청 발신자 증명, 최종 도구 접근 권한을 단계별로 확인하는 구조다.
2. MCP 서버 대상 토큰과 특정 에이전트 인증서에 대한 사용자 서명 위임을 결합해 자격 증명 공유를 줄이고 토큰 노출의 영향을 제한한다. 표준 RFC 8693 토큰 교환에는 Keycloak 26.2 이상이 필요하며 이전 버전의 레거시 교환은 호환되지 않는다는 제약이 있다.
3. X.509 인증서 제시만으로 요청을 신뢰하지 않고 요청별 서명, 시간 제한, nonce, 역할, 실시간 OCSP를 함께 확인한다. 다만 제공된 본문이 MCP 서버 검증 설명 중간에서 끝나므로 최종 권한 검증 전체를 평가할 근거는 제한적이다.

🧠 상세 정리

1. AI 에이전트의 신원과 MCP 인증 공백

원문은 AI 에이전트가 데이터베이스, API, 민감한 업무 작업에 접근할 때 어떤 에이전트가 요청했는지 암호학적으로 입증하는 일이 핵심 요구라고 설명한다. 여기에는 에이전트 간 사칭을 막고 각 에이전트가 권한 있는 사용자를 대신해서만 행동하는지 확인하는 문제도 포함된다. 구성 요소끼리 API 키를 공유하거나 에이전트 체인을 따라 OAuth 토큰을 전달하는 전통적 방식은 기업 배포에 필요한 제로 트러스트 요구를 충족하기 어렵다는 것이 글의 문제의식이다. MCP는 LLM 기반 에이전트가 데이터베이스 질의나 이메일 작업 같은 외부 도구를 호출하는 방식을 정의하지만, 원문에 따르면 전송 방식에 독립적이며 자체 인증 표준은 갖추지 않는다. 따라서 별도 신원 확인 장치가 없으면 구성 요소가 에이전트를 사칭하거나 가로챈 자격 증명을 재사용하고 권한 없이 도구를 호출할 수 있다는 위험을 제시한다.

2. Keyfactor EJBCA와 AWS의 역할

Keyfactor는 자사 설명을 기준으로 전 세계 1,500곳 이상의 기업 고객이 사용하는 머신 신원 관리 플랫폼을 제공하며, 금융·의료·제조·정부 조직을 고객 범위로 소개한다. EJBCA Enterprise는 고가용성 배포와 REST API 자동화를 지원하는 CA 및 PKI 플랫폼으로, X.509 인증서 발급, OCSP 검증, 인증서 폐기 목록인 CRL 배포, 인증서 수명주기 관리를 제공한다. 웹 콘솔과 REST API로 관리할 수 있고 온프레미스, 컨테이너, Amazon EC2에 배포할 수 있다고 설명한다. AWS와 Keyfactor의 공동 참조 아키텍처에서 AWS는 컴퓨팅·스토리지·AI 추론 계층을 맡고, Keyfactor는 에이전트를 검증 가능하고 폐기 가능한 단기 자격 증명에 연결하는 암호학적 신원 계층을 맡는다. 글은 이 결합을 인증서 수명주기 관리, 자동 등록, 실시간 폐기를 다중 에이전트 환경에 통합하는 사례로 제시한다.

3. 세 인증 계층과 네 보안 메커니즘

아키텍처는 사용자와 시스템, 에이전트와 에이전트, 에이전트와 MCP 도구 서버 사이를 각각 별도의 신뢰 경계로 구분한다. 첫 번째 사용자 인증 계층은 OAuth, X.509 인증서, 위임 발급을 이용해 사용자 신원과 자격 증명의 연결을 확인하고, 두 번째 계층은 서명 봉투의 소유 증명·nonce·타임스탬프로 호출자 신원과 요청의 최신성을 검증한다. 세 번째 MCP 인증 계층은 범위가 제한된 토큰, 서명 봉투, 위임을 결합해 관련 신원과 권한 연결 관계 및 OCSP 상태를 확인하는 구조다. 이 세 계층 전반에 요청별 서명 봉투, 사용자 서명 위임, RFC 8693 기반 대상 제한 토큰, 실시간 OCSP라는 네 메커니즘이 함께 적용된다. 원문은 사용자 자격 증명은 로그인 흐름에 유지하고 에이전트 자격 증명은 에이전트별로 제한하며, 둘 사이의 권한 관계는 위임 체인으로 연결한다고 설명한다.

4. AWS 구성 요소와 실행 전제

참조 구현은 Amazon Bedrock을 AWS Strands Agents SDK를 통한 LLM 추론에 사용하고, Amazon RDS for MySQL을 MCP 도구가 접근하는 애플리케이션 데이터베이스로 사용한다. Amazon SES는 Email Agent의 이메일 발송을 담당하며, AWS Secrets Manager는 PKCS12 묶음·토큰·메타데이터를 보관하고, Amazon EC2는 Keycloak IDP와 EJBCA PKI 서버를 호스팅한다. 실행 전제로는 해당 AWS 서비스에 접근할 수 있는 활성 계정과 Python 3.9 이상 개발 환경이 제시된다. 표준 RFC 8693 토큰 교환에는 Keycloak 26.2 이상이 필요하고 이전 버전의 레거시 교환은 호환되지 않으며, EJBCA Enterprise에는 REST API V1과 OCSP 응답기가 구성되어 있어야 한다. REST API 인증용 api-admin.p12 관리자 인증서와 함께 X.509, OCSP, OAuth 2.0, RSA 서명, PKCS#12 키 저장소에 대한 이해도 요구된다.

5. 사용자 로그인과 대상 제한 토큰

첫 단계에서 애플리케이션은 OAuth 2.0 password grant로 Keycloak에 사용자를 인증하고 전체 세션 접근 토큰과 갱신 토큰을 받는다. 이어서 RFC 8693 토큰 교환을 수행해 audience가 MCP 서버로 제한된 토큰을 만들며, 에이전트에는 이 제한된 토큰만 전달한다. 코드 예시는 audience를 mysql-mcp-server로, scope를 database:write로 지정하므로 접근 대상과 요청 범위를 구체적으로 드러낸다. 원문은 이 토큰이 노출되더라도 조직의 다른 서비스에는 접근할 수 없도록 노출 영향을 제한하는 것이 목적이라고 설명한다. 로그인 흐름 전체의 핵심은 사용자 인증과 에이전트 권한 부여를 분리하여, 에이전트가 사용자의 개인 키나 전체 세션 OAuth 토큰을 보유하지 않고도 위임된 작업을 수행하도록 만드는 데 있다.

6. CSR 기반 인증서 발급과 사용자 서명 위임

애플리케이션은 로컬에서 RSA 2048비트 이상 키 쌍을 생성하고, 인증서 서명 요청인 CSR을 EJBCA의 pkcs10enroll REST API로 제출한다. EJBCA는 CSR에 서명해 인증서를 반환하며, 애플리케이션은 인증서와 개인 키를 PKCS12 컨테이너로 묶어 AWS Secrets Manager에 저장한다. 원문은 개인 키를 EJBCA로 보내거나 에이전트와 공유하거나 파일시스템에 저장하지 않는다고 설명하고, 세 에이전트 역할에도 같은 CSR 기반 절차로 각각 인증서를 발급한다. 이후 사용자의 개인 키로 세 에이전트 인증서의 SHA-256 지문, 사용자 주체 이름, 발급 시각, 만료 시각을 담은 JSON 위임 문서에 서명한다. 이 위임은 사용자가 특정 인증서를 가진 에이전트들의 대리 행동을 승인했음을 증명하며, 에이전트가 사용자 자격 증명을 직접 전달받는 대신 승인 증거를 운반하도록 한다.

7. 에이전트 간 서명 봉투와 재전송 방어

오케스트레이터가 MySQL 또는 Email 하위 에이전트에 요청을 전달할 때는 인증서만 제시하지 않고 도구 이름, 인수, 타임스탬프, 암호학적으로 무작위인 nonce를 포함한 전체 요청을 RSA-PSS-SHA256으로 서명한다. 이 서명 봉투는 호출자가 제시한 인증서에 대응하는 개인 키를 실제로 보유한다는 소유 증명을 제공한다. 수신자는 서명 정확성, ENVELOPE_MAX_AGE_SECONDS의 기본값인 60초 이내의 시간 유효성, ReplayCache에 의한 nonce 중복 여부를 확인한다. 여기에 UserCA.pem으로 이어지는 CA 신뢰 체인, 인증서 CN의 역할 접미사가 ALLOWED_CALLER_ROLES에 포함되는지, EJBCA의 실시간 OCSP 조회에서 폐기되지 않았는지를 추가로 검증해 총 여섯 항목을 점검한다. 일시적 실패 뒤 같은 프롬프트를 다시 보내는 정상 호출자도 새로운 nonce로 봉투를 생성해야 하며, 기존 봉투는 재사용할 수 없다는 제약이 있다.

8. MCP 서버의 최종 검증과 본문 범위

FastMCP 기반 MCP 서버는 데이터베이스 작업 실행 직전의 최종 신뢰 경계이며, 원문은 각 도구 호출에 네 가지 검증을 적용하는 다층 방어를 소개한다. 첫 번째로 Keycloak의 /token/introspect에 POST 요청을 보내 토큰이 활성 상태이고 audience에 mcp-server가 포함되는지 확인하며, 올바른 audience가 없는 전체 세션 토큰은 거부한다고 설명한다. 두 번째로 에이전트 서명 봉투의 서명, 시간 유효성, nonce 중복 여부, CA 신뢰 체인, mysql-agent 역할 일치, OCSP 비폐기 상태를 검증한다. 세 번째인 사용자 위임 검증은 위임 문서를 검증하고 서명이 사용자 키 보유자의 행위를 증명한다는 설명을 시작하지만, 제공된 source_body는 해당 문장 중간에서 끝난다. 따라서 세 번째 검증의 전체 절차와 네 번째 검증의 내용, 이후 세션 정리의 구체적 동작은 이 본문만으로 확인할 수 없으며, outline에만 등장하는 후속 설명을 확정된 구현 사실로 포함할 근거는 없다.

🧾 핵심 주장 / 시사점

• 이 설계에서 신원 확인의 단위는 인증서 자체뿐 아니라 개별 요청이다. 서명과 nonce, 시간 제한을 결합함으로써 인증서 보유 여부와 요청 재사용 문제를 함께 다룬다.
• 사용자 서명 위임은 사용자와 에이전트의 권한 관계를 연결하고, 대상 제한 토큰은 접근 가능한 서비스를 제한한다. 두 메커니즘은 서로 다른 권한 문제를 보완한다.
• 실시간 OCSP는 에이전트 간 통신과 최종 MCP 도구 호출 모두에 적용된다. 다만 제공된 본문의 중단으로 최종 검증 및 후속 처리 전체의 완결성까지 판단하기는 어렵다.

✅ 액션 아이템

• Keycloak 26.2 이상과 표준 RFC 8693 토큰 교환의 호환성 확인.
• 에이전트 간 서명 봉투에 대한 기본 60초 시간 제한, nonce 중복 방지, 역할 및 OCSP 검증 적용 여부 점검.
• FastMCP의 사용자 위임 검증 전체 내용과 네 번째 검증에 대한 추가 근거 확인.

❓ 열린 질문

• Keycloak 26.2 이상의 RFC 8693 토큰 교환에서 MCP 서버 대상 제한은 어떻게 보장되는가?
• 기본 60초의 시간 유효성과 새로운 nonce 요구는 에이전트 요청 재전송 시 어떻게 함께 충족되는가?
• 제공된 본문에서 중단된 FastMCP의 사용자 위임 검증 전체 절차와 네 번째 검증은 무엇인가?