개발자가 귀사의 SaaS 기업을 떠날 때, 여러분은 그들의 Okta 액세스 권한을 취소하고, GitHub 계정을 비활성화하며, API 키를 교체합니다. 하지만 그들이 지난달에 구축한, 여전히 귀사의 프로덕션 고객 데이터베이스에 상시 액세스 권한을 가진 AI 에이전트에는 어떤 일이 일어날까요?

우리는 지난 6개월 동안 유럽의 B2B SaaS 기업들을 대상으로 AI 구현 사례를 테스트해 왔으며, 모든 기술 창업자(technical founder)가 우려해야 할 일정한 패턴을 계속해서 목격하고 있습니다. 바로 고아 AI 에이전트(orphaned AI agents)가 전통적인 보안 감사(security audits)에서 놓치는 지속적인 액세스 경로를 생성한다는 점입니다. 이는 이론적인 이야기가 아닙니다. 우리는 생성자가 4~6개월 전에 회사를 떠났음에도 불구하고 데이터베이스에 대한 전체 액세스 권한을 가진 프로덕션 에이전트들을 발견했습니다.

이러한 시스템을 보호하는 것은 전통적인 소프트웨어를 보호하는 것과는 다른 접근 방식이 필요합니다. AI 에이전트는 단순히 코드만 실행하는 것이 아닙니다. 그들은 어떤 데이터에 언제 액세스할지에 대해 자율적인 결정(autonomous decisions)을 내립니다.

ID 문제: AI 에이전트는 IAM 감사에 나타나지 않습니다
여러분의 ID 및 액세스 관리(IAM, Identity and Access Management) 시스템은 인간 사용자(human users)와 서비스 계정(service accounts)에 대해서는 알고 있습니다. 하지만 백엔드 엔지니어가 고객 지원 티켓 분류를 자동화하기 위해 생성한 LangChain 에이전트에 대해서도 알고 있습니까?

AI 레드팀(red teaming) 활동 중에 우리는 동일한 세 가지 격차를 계속해서 발견하고 있습니다:

• 에이전트가 전용 서비스 계정 (service accounts)이 아닌 개발자의 자격 증명 (credentials)을 사용하여 인증합니다. 에이전트는 alice@startup.com에 연결된 API 키를 사용하지만, Alice는 3개월 전에 퇴사했습니다. 그녀의 Slack은 비활성화되었고 노트북은 초기화되었지만, 아무도 문서화하지 않은 에이전트 설정 파일에 API 키가 내장되어 있어 여전히 활성 상태로 남아 있습니다.
• 에이전트가 기본적으로 광범위한 권한을 부여받습니다. AI 기능을 구축하는 개발자들은 빠르게 움직여야 합니다. 그들은 기능을 프로토타이핑하기 위해 데이터베이스 읽기 권한을 부여한 뒤, 이를 축소 (scope down)하지 않습니다. 고객 지원 티켓을 요약하기로 되어 있던 에이전트가 Postgres 인스턴스의 모든 고객 기록을 읽을 수 있게 됩니다.
• 에이전트의 활동이 일반적인 애플리케이션 동작처럼 보입니다. 귀하의 SIEM (보안 정보 및 이벤트 관리) 시스템은 알려진 서비스로부터의 API 호출을 확인합니다. 누군가 프롬프트 (prompt)나 도구 설정을 수정하여 에이전트가 이전에는 건드리지 않았던 고객 데이터를 쿼리(query)하기 시작했음에도 불구하고, SIEM은 패턴이 변경되었다는 사실을 감지하지 못합니다. 우리는 이를 체계적으로 테스트합니다. 우리는 팀들에게 운영 중인 모든 AI 에이전트에 대한 문서화를 보여달라고 요청하지만, 대부분은 이를 제시하지 못합니다. 그런 다음 코드베이스에서 LLM API 호출을 검색하고 이를 인증 소스로 추적합니다. 팀이 인지하고 있는 에이전트와 실제로 실행 중인 에이전트 사이의 격차는 Series A 단계 기업에서 평균 40%에 달합니다.

도구 접근은 측면 이동 (lateral movement) 경로를 생성합니다
데이터 접근은 리스크의 절반일 뿐입니다. 나머지 절반은 AI 에이전트가 그 접근 권한을 가지고 무엇을 할 수 있느냐 하는 것입니다.

현대적인 AI 에이전트는 질문에 답하는 것 이상의 일을 수행합니다. 이들은 함수 (functions)를 실행합니다. 데이터베이스를 쿼리하고, 내부 API를 호출하며, 레코드를 수정하고, 워크플로 (workflows)를 트리거합니다. 에이전트가 호출할 수 있는 모든 도구는 잠재적인 권한 상승 (privilege escalation) 경로가 됩니다.

최근 수행한 프로젝트의 한 사례입니다. 저희는 주문 상태를 조회할 수 있는 고객용 AI 어시스턴트 (AI assistant)를 테스트했습니다. 해당 에이전트에는 내부 API를 호출하는 도구 (tool)가 있었고, 그 API는 주문 ID (order ID) 파라미터를 수락했습니다. 하지만 해당 API는 인증된 사용자가 해당 주문의 소유자인지 전혀 확인하지 않았습니다. 이는 전형적인 IDOR (Insecure Direct Object Reference, 부적절한 직접 객체 참조) 취약점으로, API 문서에 노출되는 대신 AI 에이전트의 도구 설정 뒤에 숨겨져 있었습니다.

에이전트의 제작자는 이미 퇴사한 상태였습니다. 에이전트가 호출하는 API는 두 차례나 리팩토링 (refactored)되었습니다. 저희가 프롬프트 인젝션 (prompt injection)을 통해 테넌트 경계 (tenant boundaries)를 넘어 권한 없는 주문 접근으로 체이닝 (chaining)하기 전까지는 아무도 이 에이전트의 존재를 알지 못했습니다.

또 다른 패턴은 코드 실행 환경 (code execution environments)에 접근할 수 있는 에이전트입니다. 저희는 프로덕션 시크릿 매니저 (production secrets managers)에 접근하여 Python 스크립트를 작성하고 실행할 수 있는 AI 코딩 어시스턴트들을 발견했습니다. 원래의 사용 사례는 개발자가 프로덕션 문제를 더 빠르게 디버깅 (debug)하도록 돕는 것이었습니다. 하지만 실제 리스크는 프롬프트 인젝션이나 환경 파일 (environment file)에 유출된 API 키를 통해 에이전트를 탈취한 공격자가 귀사의 프로덕션 VPC 내에서 임의의 코드를 실행할 수 있다는 점입니다.

상시 권한 (Standing privileges): "만약을 대비한" 문제
개발자들은 시간 압박 속에서 AI 기능을 구축합니다. 그들은 LLM (Large Language Model)이 어떤 데이터 소스를 필요로 할지 확신할 수 없기 때문에, 에이전트에게 5개의 데이터 소스에 대한 접근 권한을 부여합니다. 결국 에이전트는 2개만 사용하게 되지만, 나머지 3개의 권한은 무기한 활성 상태로 남습니다.

저희는 이를 상시 권한 (standing privileges)이라고 부릅니다. 즉, 실제로 필요해진 지 한참이 지난 후에도 만약을 대비해 부여된 상태로 유지되는 접근 권한을 의미합니다.

AI 레드 티밍 (red teaming) 과정에서, 저희는 에이전트가 최소 권한 원칙 (least privilege)을 준수하는지 테스트합니다:

• 에이전트가 문서화된 목적 이외의 데이터에 접근할 수 있는가?
• 30일 이상 사용하지 않은 리소스에 대한 접근 권한을 계속 보유하고 있는가?
• 프롬프트 (prompt)를 조작하여 에이전트가 사용해서는 안 될 도구 (tool)를 사용하게 만들 수 있는가? 한 테스트 사례에서, RAG (Retrieval-Augmented Generation) 기반의 문서 어시스턴트는 보안 아키텍처, API 인증 흐름, 내부 서비스 다이어그램이 포함된 회사 위키 (wiki) 전체에 대한 읽기 권한을 가지고 있었습니다. 해당 에이전트의 역할은 신입 사원들의 제품 관련 질문에 답변하는 것이었습니다. 보안 문서는 에이전트에게 필요하지 않았습니다. 하지만 구현 과정에서 "그냥 Confluence에 연결하고 LLM이 무엇이 관련 있는지 알아서 판단하게 하라"는 식으로 처리되었기 때문에, 아무도 권한 범위를 제한 (scope down)하지 않았습니다.

프롬프트 인젝션 (prompt injection)이나 탈취된 API 엔드포인트 (endpoint)를 통해 해당 에이전트에 접근한 공격자는, 정교하게 설계된 질문을 통해 귀사의 전체 내부 보안 태세 (security posture)를 추출해낼 수 있습니다.

SaaS 팀이 지금 당장 해야 할 일
시작하기 위해 거대한 엔터프라이즈 ID 거버넌스 (identity governance) 플랫폼이 필요한 것은 아닙니다. 다음 다섯 단계만으로도 대부분의 리스크를 커버할 수 있습니다.

지금 즉시 AI 에이전트 목록을 작성하세요.
코드베이스에서 OpenAI, Anthropic, Cohere API 호출을 검색한 다음, 각 호출이 어떤 인증 방식 (authentication method)을 사용하는지 추적하세요. 누가 에이전트를 생성했는지, 어떤 데이터에 접근하는지, 어떤 도구를 호출할 수 있는지 문서화하십시오. 만약 하루 만에 이 목록을 만들어낼 수 없다면, 귀사에는 고아 에이전트 (orphaned agents)가 존재하는 것입니다.

AI 에이전트에게 전용 서비스 계정을 부여하세요.
개발자의 개인 API 키 사용을 중단하고, 팀원이 퇴사할 때는 자격 증명 (credentials)을 교체(rotate)하세요. 당연한 소리처럼 들리겠지만, 저희가 진행한 프로젝트의 60% 이상에서 운영 중인 AI 에이전트 내에 개인 자격 증명이 남아 있는 것을 발견했습니다.

매월 도구 권한을 감사(audit)하세요.
각 에이전트가 무엇을 해야 하는지가 아니라, 실제로 무엇을 할 수 있는지 검토하십시오. 에이전트를 조작하여 범위를 벗어난 도구를 사용하게 만들 수 있는지 테스트하고, 30일 동안 사용되지 않은 상시 권한 (standing privileges)은 제거하십시오.

보안 모니터링에 에이전트 활동을 추가하십시오.
모든 도구 호출 (tool invocation) 및 데이터 액세스를 기록하십시오. 에이전트가 갑자기 10배 더 많은 레코드를 조회하거나 이전에 한 번도 접근하지 않은 데이터 소스를 읽는 것과 같은 비정상적인 패턴이 발견되면 경고를 발생시키십시오. AI 에이전트의 활동을 일상적인 애플리케이션 트래픽이 아닌, 고위험 인증 (high-risk authentication)으로 취급하십시오.

도구 사용이 가능한 모든 에이전트에 대해 프롬프트 인젝션 (prompt injection)을 테스트하십시오.
에이전트가 함수를 실행할 수 있다면, 공격자가 이를 악의적으로 호출하도록 조작하려 할 것이라고 가정하십시오. 당사가 테스트한 도구 사용 가능 에이전트의 약 70%에서 취약한 프롬프트 인젝션이 발견되었습니다.

이것이 귀하의 팀에 의미하는 바

• AI 에이전트는 기존의 보안 통제 (security controls)를 상속받지 않습니다. 이들에게는 명시적인 ID 관리 (identity management) 및 액세스 정책이 필요합니다.
• 고아 에이전트 (Orphaned agents)는 인벤토리를 작성하고 폐기하는 프로세스가 없다면 제작자보다 더 오래 생존합니다.
• 도구 사용 가능 에이전트는 전통적인 침투 테스트 (penetration testing)로는 찾아낼 수 없는 권한 상승 (privilege escalation) 경로를 생성합니다.
• 상시 권한 (standing privileges)은 누적됩니다. 에이전트의 권한 범위를 적극적으로 축소하지 않으면, 필요하지 않은 액세스 권한이 계속 쌓이게 됩니다.
• 에이전트 활동에는 전용 모니터링이 필요합니다. 기존의 SIEM 규칙으로는 AI 특유의 남용 사례를 포착할 수 없습니다. SaaS AI 에이전트 보안은 애플리케이션 보안에 덧붙이는 것이 아니라 그 자체로 하나의 전문 분야입니다. 이는 대부분의 팀이 아직 구축하지 못한 자율적 행동, 도구 남용, 그리고 ID 생명주기 관리 (identity lifecycle management)에 대한 테스트를 요구합니다.

Faultline Security는 귀하의 AI 공격 표면 (attack surface)을 매핑하고, 고아 에이전트를 식별하며, 에이전트가 최소 권한 (least privilege) 원칙을 준수하는지 확인하는 AI 레드팀 (AI red teaming) 활동을 통해 이러한 리스크를 테스트합니다. 프로덕션 환경에서 AI 기능을 실행 중임에도 에이전트 보안 리스크를 테스트하지 않았다면, 문의해 주십시오.