Agentic AI를 목표로 많은 조직이 AI 에이전트를 구현해 배포하는 실험을 하고 있습니다. 개념 검증(PoC) 프로젝트에서 만족할 결과를 얻어도 막상 프로덕션 환경에 배포하려 할 때 잠시 주저하는 경우가 많습니다. 가장 큰 이유는 보안 때문입니다. 아무래도 기존 보안 도구와 보안 운영 방식으로는 AI 에이전트를 노리는 위협을 탐지하고 대응할 수 있는 확신을 갖기 쉽지 않습니다. 하지만 어떤 과제도 하나하나 풀어 나가면 길이 보이게 마련이죠. AI 에이전트도 다를 바 없습니다. 관련해 이번 포스팅에서는 AI 에이전트 개발 중 간과할 수 있는 보안 이슈가 무엇인지 알아보고 이 문제를 어떻게 해결할 지 소개하겠습니다.
하드코딩된 API 키가 위험한 이유
AI 에이전트를 구현해 배포할 때 가장 빈번하게 발생할 수 있는 잠재적 보안 이슈는 무엇일까요? 바로 개발 단계에서 외부 도구를 빠르게 연결하려고 하드코딩 방식으로 API 키를 소스 코드 안에 직접 입력하는 것입니다. 개발자들은 로컬 환경에서 프로토타입을 제작할 때 이 방식이 편리하다고 느낍니다. 그러나 이런 식으로 개발한 AI 에이전트를 프로덕션 환경에 배포하는 순간 위험에 노출될 수 있습니다.
하드코딩한 정보가 공격자의 손에 넘어가면? 기업의 IT 환경에 언제든 몰래 숨어들어 내부 네트워크 환경에서 권한 상승을 거듭하며 데이터 유출 같은 악의적인 행위를 할 위험성이 매우 높아지게 됩니다. 가령 개발자가 실수로 API 키가 포함된 코드를 저장소에 올리거나 설정 파일에 남겨두면 공격자는 해당 AI 에이전트의 권한을 탈취하여 수개월 동안 고객 데이터와 재무 기록, 소스 코드 등에 접근할 수 있습니다.
이 밖에도 AI 에이전트가 외부 입력을 처리하는 것 자체가 공격 표면(Attack Surface)이 될 수 있습니다. 공격자가 악의적인 지시를 입력값에 심어두는 프롬프트 인젝셕(Prompt Injection) 공격이 대표적입니다. 만약 AI 에이전트가 충분히 격리되지 않았거나 과도한 권한을 보유하고 있다면 공격자는 AI 에이전트를 조종하여 파괴적인 행위를 저지를 수 있습니다.
Agent Identity가 제시하는 AI 에이전트 보안 강화 방안
AI 에이전트 개발과 운영 단계에서 발생할 수 있는 잠재적인 보안 이슈 해결을 위해 구글 클라우드는 다양한 도구와 기능을 제공하고 있습니다. 이 중 하드코딩된 API 관련 보안 위험을 해소하기 위한 Agent Identity입니다. 이는 각 AI 에이전트 리소스에 독립적이고 고유한 정체성을 부여하여 보안 경계를 명확하게 구축하기 위해 사용하는 AI 에이전트를 위한 IAM이라고 할 수 있습니다.
현재 프리뷰로 공개된 Agent Identity는 클라우드 네이티브 환경에서 서비스 간 신뢰를 구축하기 위한 개방형 표준을 기반으로 설계되었습니다. 사용자가 AI 에이전트를 배포하는 즉시 시스템이 자동으로 고유한 식별자를 생성하며, 이는 AI 에이전트의 수명 주기와 통합됩니다. 따라서 관리자가 일일이 서비스 계정을 생성하거나 폐기할 필요가 없습니다.
한편, Agent Identity는 위조가 불가능합니다. 이 시스템은 구글이 관리하는 컨텍스트 인식 접근 정책과 상호 TLS(mTLS) 바인딩을 적용하여 보안을 유지합니다. 자격 증명이 인증서 기반 토큰 형태로 존재해 공격자가 이를 탈취하더라도 지정된 런타임 환경 밖에서는 절대로 사용할 수 없습니다.
Secret Manager와 Agent Identity의 결합
Agent Identity와 Secret Manager가 짝을 이루면 더 강력한 보안 통제를 수행할 수 있는 환경을 마련할 수 있습니다. 두 서비스를 결합하면 AI 에이전트의 특성을 반영한 자격 증명 관리 기반을 다질 수 있습니다.
Secret Manager는 API 키, 비밀번호, 인증서와 같은 민감한 데이터를 저장하고 관리하는 중앙 집중식 저장소입니다. AI 에이전트 코드는 실제 키 값을 포함하지 않고 오직 비밀 리소스의 이름만을 참조합니다. 이러한 구조 덕분에 소스 코드가 유출되더라도 실제 API 키는 안전하게 보호할 수 있습니다.
Agent Identity와 Secret Manager의 결합은 실제 프로덕션 환경에서 빛을 발합니다. AI 에이전트가 실제 실행 환경에서 초기화되는 시점에 Secret Manager로부터 자격 증명을 가져와 내부 속성으로 저장하도록 설계하면 매번 API를 호출할 필요가 없어 성능을 높이면서도 보안을 유지할 수 있습니다. 또한, 관리자는 특정 Agent Identity에 대해서만 특정 비밀 정보에 접근할 수 있는 최소 권한 원칙을 명시적으로 부여할 수 있습니다. 예를 들어 지도를 다루는 AI 에이전트에게는 오직 지도 API 키만 허용하고 인사 시스템의 비밀번호에는 접근하지 못하도록 완벽하게 격리하는 식입니다.
투명한 감사 체계와 신속한 위협 대응
Agent Identity와 Secret Manager의 결합은 단순히 공격을 막는 수준을 넘어 보안의 가시성과 추적성 확보에도 도움이 됩니다. 기존의 공유 서비스 계정 모델에서는 로그를 확인하더라도 어떤 AI 에이전트가 어떤 작업을 수행했는지 명확히 파악하기 어려웠습니다.
하지만 Agent Identity를 사용하면 구글 클라우드 로깅에 기록되는 모든 활동에 해당 AI 에이전트의 고유 식별자가 남습니다. AI 에이전트가 자율적으로 행동할 때는 물론이고 사용자를 대신하여 작업할 때도 그 인과관계를 명확히 추적할 수 있습니다. 관리자는 로그 조회를 통해 어떤 AI 에이전트가 언제 어떤 비밀 정보에 접근했는지 상세히 파악할 수 있습니다. 이는 보안 사고 발생 시 정밀한 분석을 위한 근거가 됩니다.
이러한 활동 로그는 통합 보안 플랫폼인 Security Command Center와 실시간으로 연동됩니다. AI 모델이 AI 에이전트의 동작 패턴을 분석하여 평소와 다를 경우 이를 위협으로 규정하고 보안팀에 알립니다. 관리자는 로그에 기록된 고유 ID를 바탕으로 침해당한 AI 에이전트를 식별하여 삭제할 수 있으며,이때 연동된 모든 권한도 함께 무효화하므로 추가 피해도 막을 수 있습니다.
AI 에이전트의 특성에 맞는 IAM 전략이 필요
Agent Identity와 Secret Manager는 사용자가 아니라 AI 에이전트를 위한 명확한 IAM 체계를 제시합니다. Agent Identity와 Secret Manager를 기반으로 관리자는 다음과 같은 IAM 전략을 AI 에이전트 환경에 적용할 수 있습니다.
- AI 에이전트 ID 설정: 공유 서비스 계정은 관리가 편해 보일 수 있으나 보안 사고 시 기업 전체를 위협하는 시한폭탄이 될 수 있습니다. 이러한 위험을 해소하려면 모든 AI 에이전트의 ID 설정을 의무화해야 합니다.
- 최소 권한 원칙: 프로덕션 환경에 배포하는 모든 AI 에이전트는 최소 권한의 원칙을 따라야 합니다. 이를 위해 모든 민감한 자격 증명은 Secret Manager에서만 관리하고 AI 에이전트의 고유 ID에 대해서만 최소 권한을 부여하는 것을 표준 개발 프로세스로 정착시켜야 합니다.
- 가시성: AI 관련 각종 규제와 가이드라인을 충족하는 것은 앞으로 매우 중요한 과제가 될 전망입니다. 로깅과 모니터링 체계를 적극적으로 활용하면 AI 에이전트의 모든 행동에 대한 가시성을 확보할 수 있습니다.
정리하자면 새술은 새부대에 담는 다는 시각으로 AI 에이전트의 IAM을 바라보는 것이 필요합니다. 많은 조직이 일반 사용자에게는 IAM을 적용하고 시스템 관리자 같이 민감한 자격 증명 관리는 PAM(Privileged Access Management)을 사용하듯이 AI 에이전트에도 같은 기준과 원칙 보안 체계를 적용해야 합니다. Agent Identity와 Secret Manager가 제시하고 있는 AI 에이전트를 위한 권한 관리와 접근 제어에 대한 명확한 기준과 원칙을 따른다면? 멀티 AI 에이전트 시대로 나아가기 위한 보안의 기초를 탄탄히 다질 수 있을 것입니다.
설계 단계부터 보안을 강화하고 싶다면 메가존소프트 문의포탈을 통해 궁금한 부분을 남겨주세요.
