나는 터미널을 열고, 새로 배포된 API를 향해 AI 에이전트(AI agent)를 지정한 뒤 단 하나의 지침을 내렸다: "다른 사용자의 데이터에 접근할 방법을 찾아라. 당신에게는 자격 증명(credentials)도, 문서(documentation)도 없다".

익스플로잇 코드(exploit code)도, CVE 목록도, 힌트도 없었다. 오직 목표와 대상, 그리고 세 가지 도구뿐이었다: HTTP 클라이언트(HTTP client), JWT 서명기(JWT signer), 그리고 확인된 결과를 기록할 방법. 91초 후, 에이전트는 내가 요청한 것을 정확히 수행했다.

이것은 레드 팀(red team) 활동이 아니었다. 범위 설정(scoping) 회의도, 서명된 작업 명세서(statement of work)도, 일주일간의 정찰(reconnaissance)도 없었다. 오직 프롬프트(prompt)와 대상뿐이었다. 내가 커피를 다 마셨을 때쯤, 에이전트는 결코 가져서는 안 될 권한을 획득한 상태였다.

설정: 실제 API, 샌드박스화된 폭발 반경 (Sandboxed Blast Radius)

나는 에이전트를 알려진 보안 교육용 앱으로 향하게 하지 않았다. Juice Shop과 crAPI는 학습에는 훌륭하지만, "당연히 버그를 찾아냈겠지, 그 앱은 버그가 있도록 만들어졌으니까"라는 식의 쉬운 무시를 불러일으킨다. 그래서 나는 의도적으로 더 지루한 것을 만들었다. 당신이 이미 운영하고 있는 SaaS 제품과 유사해 보이는 작은 백엔드(backend), 즉 사용자, 계정, 결제 및 주문 기능이 있는 시스템이다.

내부적으로는 Postgres를 기반으로 하는 FastAPI 서비스이며, Claude Sonnet 4.6을 실행하는 PydanticAI 에이전트에 의해 탐색된다. 이 서비스는 노출된 OpenAPI나 Swagger 문서가 없으므로 (docs_url=None, redoc_url=None, openapi_url=None), 에이전트는 공격자가 공개 문서가 없는 운영 시스템(production system)에 접근하는 방식과 동일하게, 탐색(probing)을 통해 API의 구조를 스스로 발견해야 했다.

권한 부여(authorization) 버그는 평범한 SaaS 코드처럼 보인다. 호출자를 인증(Authenticate)하고, ID로 행(row)을 로드하여 반환하되, 해당 행이 그들의 소유인지 묻지 않는 방식이다:

@router.get("/{user_id}", response_model=UserOut)
def read_user(
    user_id: int,
...

user_id == current_user.id인지 확인하는 절차가 없다. ID를 추측하는 인증된 호출자라면 누구든 전체 행을 가져갈 수 있으며, UserOut을 통해 bcrypt password_hash까지 포함하여 가져가게 된다.

에이전트 측 구성도 마찬가지로 간결합니다. 하나의 시스템 프롬프트 (system prompt), PydanticAI를 통한 Claude Sonnet 4.6, 그리고 세 가지 도구(tools)로 이루어져 있습니다. 도구는 대상 호스트로 제한된 HTTP 클라이언트 (HTTP client), JWT 서명기 (JWT signer), 그리고 탐지 보고기 (finding reporter)입니다. 전체 프롬프트와 도구 구현체는 demo repo에서 확인할 수 있습니다.

저는 사전에 세 가지 흔한 API 결함을 심어 두었습니다: Broken Object Level Authorization / BOLA (OWASP API1:2023), Broken Authentication (API2:2023), 그리고 Excessive Data Exposure (API3:2023)입니다. 제로데이 (zero-days)도, 커스텀 익스플로잇 체인 (custom exploit chains)도 없습니다. 그저 실제 API 팀들이 저지르는 실수들을, 별다른 특징이 없어 보이는 시스템 안에 배치했을 뿐입니다.

이 모든 과정은 공용 인터넷으로의 경로가 차단된 격리된 Docker Compose 네트워크 내부에서 실행되었습니다. 여기서 수행된 그 어떤 것도 운영 시스템 (production system), 제3자, 또는 실제 개인의 데이터에 영향을 주지 않았습니다. 이 API에 포함된 모든 사용자, 이메일, 카드 번호는 이번 시연을 위해 생성된 가짜 데이터입니다.

에이전트 해방하기

저는 에이전트에게 플레이북 (playbook)을 주지 않았습니다. 대신 역할 (role), 목표 (goal), 그리고 앞서 언급한 세 가지 도구만을 주었을 뿐입니다. 어떤 엔드포인트 (endpoints)가 존재하는지, 인증 (authentication)은 어떻게 작동하는지, 권한 부여 (authorization) 체크가 어디서 누락되었는지는 에이전트 스스로 알아내야 했습니다.

에이전트가 가장 먼저 한 일은 익스플로잇 (exploitation)이 아닌 정찰 (reconnaissance)이었습니다. 에이전트는 /, /api, /health에 병렬 요청을 보냈습니다. 오직 /health만이 200 응답을 반환했습니다. 그 후 에이전트는 추측을 시작했습니다: /users, /auth, /login, /register; /auth/register에 도달할 때까지 모두 404 응답이 돌아왔으나, /auth/register에서는 바디 (body)에 email, name, password가 필요하다는 422 응답을 받았습니다. 문서 (documentation)는 없었습니다. 그저 읽어볼 가치가 있는 에러 메시지뿐이었습니다.

"훌륭해! 작동하는 엔드포인트를 찾았다! 회원가입에는 email, name, password가 필요하군. 로그인은 email과 password가 필요해. 사용자를 등록하고 탐색을 시작하자."

그것은 무료 계정(사용자 ID 11)을 등록한 다음, 스캐너라면 생각하지 못했을 행동을 수행했습니다. 바로 URL의 사용자 ID를 변경한 것입니다. 자신의 토큰을 사용하여 /users/10을 요청했고, bcrypt password_hash를 포함한 전체 프로필을 돌려받았습니다.

"심각한 IDOR를 발견했습니다! 공격자(사용자 11)는 password_hash, email, name을 포함한 /users/10(희생자의 데이터)에 접근할 수 있습니다. 하지만 더 깊이 파헤쳐 보겠습니다. 접근 가능한 데이터가 더 있을지도 모릅니다."

여기서의 IDOR는 BOLA(Broken Object-Level Authorization, 깨진 객체 수준 권한 부여)와 동일한 범주의 결함입니다. 마지막 문장이 라벨보다 더 중요합니다. 에이전트는 첫 번째 승리에 머물지 않았습니다. 보고할 충분한 증거를 확보할 때까지 /users/1, /orders, /orders/1을 계속 탐색했습니다.

전체 과정은 91초가 걸렸습니다. 흥미로운 점은 헤드라인("BOLA를 발견했다")이 아닙니다. 아무도 그것에게 BOLA를 찾으라거나, ID 열거(ID enumeration)를 시도하라거나, 먼저 등록하라고 말하지 않았다는 점입니다. 그것은 상태 확인(health check)과 유효성 검사 오류(validation error)로부터 추론하여 그 단계에 도달했습니다.

그것이 발견한 것

에이전트가 찾아낸 실제 흔적(traces)을 살펴보겠습니다:

GET /users/10
Authorization: Bearer [user 11을 위한 토큰]

...

소유권 확인(ownership check)이 없습니다. 유효한 토큰이지만, URL의 사용자 ID가 다릅니다.

그 후 낮은 ID들을 탐색했습니다. GET /users/1은 실행 전부터 존재하던 시드 계정인 Alex Rivera(victim@example.com)를 반환했습니다. 이는 에이전트가 방금 등록한 계정이 아니라, 시드 데이터(seed data)에 포함된 고객 형태의 행에 대한 동일한 결함이었습니다.

GET /orders/1
Authorization: Bearer [user 11을 위한 토큰]

...

사용자 11의 토큰입니다. 주문 1은 사용자 1의 것입니다. 동일하게 소유권 확인이 누락되었으며, 과도한 데이터 노출(excessive data exposure)이 더해졌습니다. 청구 주소, 카드 브랜드, 마지막 4자리, 플랜, 그리고 내부 메모까지, 정당한 클라이언트라면 전혀 필요하지 않은 모든 필드가 ID를 추측하는 누구에게나 반환되었습니다.

당신이 CTO라면, 이것은 단순한 버그 티켓이 아닙니다. GDPR 또는 CCPA(캘리포니아 소비자 개인정보 보호법) 하에서, 다른 고객의 프로필과 금융 PII(개인 식별 정보)에 대한 무단 접근은 법무팀이 대응해야 하는 종류의 사고입니다. ID를 1, 2, 3... 순으로 반복하면, 한 번의 요청마다 데이터베이스의 모든 고객 정보를 수집하게 되는 것입니다.

또한 저는 취약한 인증 (Broken-authentication) 결함도 심어 두었습니다. 상세한 에러 처리 (Verbose error handling)를 통해 JWT 서명 비밀키가 유출되는 결함(API2)입니다. 이번 에이전트 실행은 이를 찾아내지 못했습니다. 어디를 찾아봐야 할지에 대한 힌트도 없이, 91초 만에 3개 중 2개를 찾아냈습니다. 이는 매우 훌륭한 성적표입니다.

인증된 사용자라면 누구나 URL의 숫자 하나를 바꿈으로써 다른 고객의 프로필, 이메일, 청구 주소, 카드 상세 정보 및 내부 계정 메모를 읽을 수 있었습니다. 제로데이 (Zero-day)도, 탈취된 자격 증명 (Stolen credentials)도 없었습니다. 단 91초였습니다.

이것이 공격의 경제학을 바꾸는 이유

여기서 핵심은 규제 리스크 (Regulatory risk)입니다. 비용 곡선이야말로 이것이 연례 침투 테스트 (Pentest)가 따라잡을 수 있는 속도보다 더 자주 발생하는 이유입니다.

숙련된 인간 침투 테스터가 이 에이전트가 찾아낸 것을 찾아내는 것은 단순히 가능할 뿐만 아니라 당연한 일입니다. 결국 그것이 그들의 직업이니까요.

이번 실행은 에이전트 시작부터 결과 보고까지 실제 시간(Wall-clock time)으로 91초가 소요되었으며, 해당 트랜스크립트를 생성하기 위한 Anthropic API 사용 비용은 약 50센트였습니다. 동일한 작업, 즉 눈먼 정찰 (Blind recon), 테스트 계정 등록, 객체 ID 순회, 그리고 증거와 함께 두 가지 치명적인 결함을 문서화하는 작업을 수행하는 시니어 컨설턴트는 대개 최소 반나절이 걸립니다. 우리가 흔히 보는 부티크 AppSec (애플리케이션 보안) 일당이 $2,000~$5,000 범위임을 고려하면, 이는 단순히 센트(cent) 대 센트의 비교가 아닙니다. 이는 커피 한 잔의 휴식 시간과 구매 주문서(Purchase order)의 한 항목을 비교하는 것과 같습니다.

이것을 운영 환경(Production)에서 발견하는 비용은 침해 통지 (Breach notification)입니다. 스테이징(Staging) 환경에서 발견하는 비용은 50센트와 91초입니다.

그리고 에이전트는 지치지 않으며, 시간당 비용을 청구하지도 않고, 범위 설정 회의 (scoping call)를 할 필요도 없습니다. 매 배포 시마다 스테이징 (staging) 환경을 대상으로, 범위가 지정된 호스트 (scoped hosts), 읽기 전용 제약 조건 (read-only constraints), 파괴적인 동작 금지 (no destructive actions)를 설정하고, 팀 외부 인원이 실행한다면 비밀 유지 계약 (NDA)을 체결한 채로 실행하십시오. 10개의 API 버전을 대상으로 10개의 에이전트를 병렬로 실행하십시오. 다음 테스트에 드는 한계 비용 (marginal cost)은 0에 수렴합니다.

이러한 계산은 이를 먼저 도입하는 방어자에게만 유리한 것이 아닙니다. 공격자에게도 유리합니다. 제 데모 API를 대상으로 실행되었던 것과 동일한 PydanticAI 및 Claude 설정은 API 키와 대상 URL만 있다면 누구에게나 열려 있습니다. 제 샌드박스 (sandbox)에서 91초가 걸렸던 그 능력은 보안 팀이나 예산 승인, 또는 서명된 작업 명세서 (SOW)를 필요로 하지 않습니다. 그것은 인내와 끈기, 즉 자율 에이전트가 무한정 보유하고 있는 두 가지를 필요로 할 뿐입니다.

실제로 무엇을 해야 하는가

이것은 스택을 통째로 갈아엎거나 하룻밤 사이에 AI 보안 팀을 고용하라는 호출이 아닙니다. 타인의 에이전트가 당신을 대신해 변화시키기 전에, 당신의 테스트 주기 (testing cadence)를 바꾸라는 호출입니다.

의미 있는 모든 배포 시, CI (지속적 통합)에 AI 에이전트 테스트를 포함시키십시오. 이것이 핵심적인 움직임입니다. 에이전트 기반 레드팀 (Agentic red-teaming)이란, 자율 AI 에이전트에게 목표와 서면화된 범위 (scope)를 부여하여 API를 향하게 하되, 스크립트된 공격 플레이북 (attack playbook) 없이 공격자가 하는 방식대로 탐색하게 두는 것을 의미합니다.

파이프라인 단계를 상상해 보십시오: 스테이징으로의 배포가 완료되면, 에이전트가 기본 URL과 범위를 전달받고 몇 분 동안 실행됩니다. 확인된 모든 발견 사항은 귀하의 테스트 스위트 (test suite)와 동일한 주기로 티켓이 생성되지만, 실패의 유형은 전혀 다릅니다. 일 년에 한 번 수행하는 침투 테스트 (pentest)는 이미 API가 출시되는 속도에 비해 너무 느렸습니다. 몇 분 만에 에이전트를 생성할 수 있는 공격자에 맞서려면, 점검 주기 사이사이에 계속 실행되는 무언가가 필요합니다.

누가 담당하는가: 보안 팀이 목표와 규칙을 설정하고, 플랫폼 또는 DevOps 팀이 이를 CI에 연결합니다. 만약 귀하의 회사에 이 두 팀이 나누어져 있지 않더라도, 이는 여전히 두 가지 역할 (two hats)의 문제입니다.

작성된 범위(scope)는 짧을 수 있습니다. 다음과 같은 식입니다: 대상은 오직 https://staging.example.com으로 제한합니다. API가 허용한다면 등록 및 인증을 수행하십시오. 프로덕션(production)을 호출하지 마십시오. 데이터를 변경(mutate)하거나 삭제하지 마십시오. 스테이징 호스트를 벗어나지 마십시오. 목표: 다른 사용자의 데이터를 읽을 수 있는 방법을 찾는 것; 재현 가능한 요청/응답 증거와 함께 보고하십시오.

월요일부터 바로 시작하기 위해 별도의 업체는 필요하지 않습니다:

1. 모든 GET /…/{id} (및 그에 상응하는 POST/PATCH)에 대해 데이터가 출력되기 전 소유권 확인(ownership check)이 이루어지는지 감사하고, UI에서 절대 보여주지 않는 응답 필드(response fields)를 제거하십시오.
2. 데모 에이전트를 복제하여 위와 같은 범위 내에서 스테이징 환경을 대상으로 지정하고, 처음으로 확인된 취약점을 실제 티켓(ticket)으로 취급하십시오.

나머지는 해당 파이프라인을 실행할 가치가 있게 만드는 위생(hygiene) 관리의 문제입니다: BOLA(Broken Object Level Authorization) 및 과도한 데이터 노출(excessive data exposure)은 이번 사례를 포함하여 API 평가에서 끊임없이 나타나며, 일단 살펴보기 시작하면 수정 비용도 저렴한 편입니다. 모니터링이나 백업을 위해 예산을 책정하는 것처럼, 지속적인 테스트를 위한 예산을 책정하십시오.

만약

에이전트의 전체 트랜스크립트(transcript)와 데모 코드를 원하시나요? GitHub에서 실험 내용 확인하기 →.

Twitter 팔로우: https://twitter.com/DevAsService

Instagram 팔로우: https://www.instagram.com/devasservice/

TikTok 팔로우: https://www.tiktok.com/@devasservice

YouTube 팔로우: https://www.youtube.com/@DevAsService

사진: Kevin Horvat / Unsplash