AI 에이전트 보안 실태 2026 해설: 에이전트 증가는 모델보다 계정·권한·정지 루프를 먼저 설계해야 하는 이유

발행일: 2026-06-30 | 카테고리: ai뉴스

1. 한 줄 문제 정의

핵심 한 줄: 기업의 AI 에이전트 수는 빠르게 늘고 있지만, 보안팀이 실제로 통제하는 범위는 그 속도를 따라가지 못하고 있습니다.

Gravitee가 2026년 6월 15일 공개한 State of AI Agent Security Report는 2026년 4월 기준 영국·미국 senior technology leader 750명을 조사했습니다. 이 보고서는 기업 AI 에이전트 집합이 2025년 12월 이후 약 4개월 만에 두 배로 늘었고, 생산 환경 에이전트의 평균 48%가 보안 또는 거버넌스 없이 실행 중이라고 설명합니다.

이 글의 대상은 사내 업무 자동화, 개발 자동화, 고객 응대, 데이터 분석에 에이전트를 붙이려는 CTO, 플랫폼 팀, 보안 담당자, 시니어 개발자입니다. 범위는 모델 성능 비교가 아니라 조직이 에이전트를 계정, 권한, 도구 호출, 로그, 정지 절차로 관리하는 방법입니다.

비적용 범위: 개인이 로컬에서 한두 개 챗봇을 실험하는 상황, 외부 API를 전혀 호출하지 않는 단순 문서 요약, 규제가 없는 샘플 프로젝트는 이 글의 직접 범위가 아닙니다.

2. 먼저 결론

핵심 한 줄: 에이전트 도입의 첫 질문은 "어떤 모델이 똑똑한가"가 아니라 "이 에이전트를 언제 멈출 수 있는가"여야 합니다.

• 지금 확장해도 되는 팀: 에이전트별 계정이 분리되어 있고, 도구 호출 로그와 권한 회수 절차가 이미 있는 팀
• 아직 관찰만 해야 하는 팀: 공유 API 키를 쓰고, 에이전트가 어떤 데이터에 접근했는지 재구성할 수 없는 팀
• 제 판단: 2026년의 핵심 리스크는 에이전트가 멍청해서 생기는 문제가 아닙니다. 에이전트가 충분히 빠르게, 충분히 많은 권한으로, 충분히 조용히 움직일 수 있게 된 것이 문제입니다.

추천 순서는 보수적입니다. 첫째, 모든 에이전트에 고유한 신원을 부여합니다. 둘째, 도구와 데이터 권한을 업무 단위로 쪼갭니다. 셋째, 런타임 로그를 남깁니다. 넷째, 사고가 의심될 때 즉시 토큰을 회수하고 작업을 멈추는 절차를 문서화합니다.

3. 핵심 구조 분해

핵심 한 줄: 에이전트 보안은 하나의 보안 제품이 아니라 신원, 모델 호출, 도구 호출, 런타임 행동, 감사 로그가 연결된 운영 구조입니다.

1. 에이전트 신원: 에이전트도 사람 계정처럼 누가 무엇을 했는지 추적되어야 합니다. 공유 토큰 하나로 여러 에이전트를 돌리면 사고가 났을 때 원인을 분리할 수 없습니다.
2. 모델 호출 경계: 어떤 모델을 호출할 수 있는지, 예산과 속도 제한은 얼마인지, 민감한 입력이 외부 모델로 나가는지 확인하는 층입니다.
3. 도구 호출 경계: 데이터베이스, CRM, GitHub, 결제 시스템, 파일 시스템 같은 실제 업무 도구에 접근하는 층입니다. 에이전트 사고는 보통 답변 문장이 아니라 이 도구 호출에서 발생합니다.
4. 런타임 관찰: 에이전트가 여러 단계를 이어서 실행할 때 이상한 순서를 감지합니다. 예를 들어 대량 파일 읽기 다음 외부 업로드가 이어지면 정상 업무인지 의심해야 합니다.
5. 감사와 정지 루프: 누가 승인했고, 어떤 예외가 있었고, 어떤 토큰을 회수해야 하는지 남기는 층입니다. 사고 대응의 출발점입니다.

초보 개발자 기준으로 쉽게 말하면, AI 에이전트는 똑똑한 비서가 아니라 자동으로 버튼을 누르는 사내 계정입니다. 그래서 말투보다 권한표, 출입 기록, 비상 정지 버튼이 먼저 필요합니다.

4. 설계 의도 해설

핵심 한 줄: 에이전트 보안 구조는 "에이전트를 믿자"가 아니라 "에이전트가 실수해도 피해 범위를 작게 만들자"는 의도로 설계해야 합니다.

전통적인 보안 도구는 대체로 사람이 한 번 클릭하거나 요청하는 상황을 기준으로 만들어졌습니다. 그런데 에이전트는 여러 도구를 연속으로 호출하고, 웹 페이지나 문서 같은 신뢰할 수 없는 입력을 읽고, 이전 단계의 결과를 다음 단계 판단에 사용합니다.

그래서 단순한 API 키 보호만으로는 부족합니다. API 키가 안전해도 에이전트가 과도한 권한을 받았거나, 악성 문서의 지시를 따라 내부 파일을 읽거나, 외부 SaaS에 잘못된 데이터를 보낼 수 있습니다.

대안은 세 가지입니다. 첫째, 에이전트를 금지합니다. 위험은 줄지만 업무 자동화 기회를 놓칩니다. 둘째, 에이전트를 자유롭게 허용합니다. 속도는 빠르지만 사고 원인 추적이 어렵습니다. 셋째, 에이전트를 고유 신원과 제한된 도구 권한 안에서 운영합니다. 초기 설계 비용은 들지만, 장기적으로 확장 가능한 선택은 세 번째입니다.

5. 근거 및 비교

핵심 한 줄: 최신 조사에서 보이는 위험은 추상적인 미래 위험이 아니라 이미 생산 환경에서 관측되는 통제 격차입니다.

Gravitee 보고서에서 특히 중요한 숫자는 세 가지입니다. 첫째, 기업 에이전트 집합이 4개월 만에 약 두 배로 늘었습니다. 둘째, 생산 환경 AI 에이전트의 평균 48%가 보안 또는 거버넌스 없이 실행 중이라고 보고됐습니다. 셋째, 응답 조직의 54%가 지난 12개월 동안 AI 에이전트 보안 또는 개인정보 사고를 경험했거나 의심했다고 답했습니다.

NIST의 AI 페이지는 AI 거버넌스를 위험 기반 접근, 측정, 평가, 표준, AI Risk Management Framework 중심으로 설명합니다. 이 관점은 에이전트 보안에도 그대로 적용됩니다. 에이전트는 "정책 문서가 있다"로 끝나는 대상이 아니라, 어떤 위험을 어떻게 측정하고 줄일지 운영 지표로 관리해야 하는 대상입니다.

6. 실제 동작 흐름 / 단계별 실행 방법

핵심 한 줄: 첫 도입은 기능 목록이 아니라 에이전트 등록부, 권한표, 로그, 정지 절차를 만드는 일부터 시작해야 합니다.

1. 에이전트 등록부를 만듭니다. 이름, 목적, 소유자, 사용하는 모델, 접근 도구, 접근 데이터, 배포 위치, 종료 기준을 한 줄씩 기록합니다.
2. 에이전트별 계정을 분리합니다. 가능하면 OIDC, 서비스 계정, scoped token을 사용하고, 공유 API 키는 제거합니다.
3. 권한을 업무 단위로 나눕니다. 읽기 전용, 댓글 작성, 티켓 생성, DB 조회, DB 수정, 외부 전송처럼 위험도를 나누고 기본값은 읽기 전용으로 둡니다.
4. 모델 호출은 Gateway로 모읍니다. 모델, 토큰 비용, latency, 요청자, 프로젝트, 에러율을 기록합니다. 예산 폭주와 비정상 호출을 먼저 볼 수 있어야 합니다.
5. 도구 호출도 Gateway 또는 중앙 래퍼로 모읍니다. 어떤 에이전트가 어떤 도구를 어떤 payload로 호출했는지 남깁니다.
6. 정지 조건을 코드처럼 명시합니다. 시크릿 노출, 개인정보 외부 전송, 5분 내 대량 조회, 승인 없는 쓰기 작업처럼 즉시 중단할 조건을 정합니다.
7. 2주 파일럿으로 지표를 봅니다. 차단 건수, false positive, 승인 지연, 권한 요청 증가, 사고 재현 가능성을 기록합니다.

{
  "agent": "sales-summary-agent",
  "owner": "revenue-ops",
  "allowedTools": ["crm.read", "docs.write"],
  "blockedTools": ["crm.export", "billing.refund"],
  "stopRules": [
    "external_upload_after_bulk_read",
    "pii_detected_in_model_prompt",
    "write_action_without_human_approval"
  ],
  "definitionOfDone": "모든 도구 호출이 agent_id, user_id, tool, decision, timestamp로 재구성된다"
}

이 예시는 실제 제품 코드가 아니라 운영 계약의 형태를 보여주기 위한 것입니다. 핵심은 에이전트가 "할 수 있는 일"과 "절대 하면 안 되는 일"을 사람 머릿속이 아니라 시스템이 읽을 수 있는 형태로 남기는 것입니다.

7. 실수/함정(Pitfalls)

핵심 한 줄: 에이전트 보안 실패는 대부분 모델 환각보다 권한 과다, 로그 부재, 소유자 부재에서 시작합니다.

• 실수 1: 파일럿 계정을 그대로 운영에 사용함
  예방: 파일럿 종료일과 권한 만료일을 함께 설정합니다.
  복구: 파일럿 에이전트 토큰을 회수하고 최근 30일 도구 호출을 감사합니다.
• 실수 2: 에이전트 소유자를 팀 이름으로만 둠
  예방: 개인 책임자, 백업 책임자, 보안 연락처를 등록합니다.
  복구: 사고 대응 중 승인자를 찾지 못한 에이전트는 임시 중지합니다.
• 실수 3: 읽기 권한과 내보내기 권한을 같은 등급으로 봄
  예방: 조회, 다운로드, 외부 전송, 삭제, 결제, 배포를 별도 권한으로 나눕니다.
  복구: 외부 전송 가능 도구를 allowlist 방식으로 바꾸고 사유 없는 export 권한을 제거합니다.
• 실수 4: 프롬프트 인젝션을 챗봇 문제로만 봄
  예방: 웹 페이지, 이메일, PDF, 티켓 본문처럼 에이전트가 읽는 모든 외부 입력을 신뢰하지 않습니다.
  복구: 외부 입력을 읽은 세션이 어떤 도구를 호출했는지 추적하고, 민감 작업은 새 세션과 사람 승인으로 분리합니다.
• 실수 5: 로그는 남기지만 중단 버튼이 없음
  예방: agent_id 기준 토큰 회수, 도구 차단, 큐 중지, 세션 폐기를 한 번에 실행하는 runbook을 만듭니다.
  복구: 사고 후 로그 분석보다 먼저 해당 agent_id의 모든 active credential을 정지합니다.

8. 강점과 한계

핵심 한 줄: 중앙 통제 구조는 사고 대응력을 높이지만, 잘못 설계하면 개발 속도와 실험 문화를 막을 수 있습니다.

• 강점: 에이전트별 계정과 로그가 있으면 사고 원인을 좁히고 권한을 빠르게 회수할 수 있습니다.
• 강점: Gateway는 모델 비용, rate limit, 공급자 장애 대응, 요청 추적을 한곳에서 관리하게 해줍니다.
• 강점: 도구 호출 정책은 실제 피해가 발생하는 지점, 즉 DB 수정·외부 전송·파일 삭제를 직접 통제합니다.
• 한계: 모든 에이전트 호출을 중앙화하면 초기 개발 경험이 무거워질 수 있습니다. 낮은 위험의 내부 실험에는 가벼운 sandbox가 필요합니다.
• 한계: Gateway가 있어도 업무 로직 오류, 잘못된 승인, 부정확한 모델 판단을 모두 막지는 못합니다.
• 반례: 외부 연결이 없는 단발성 문서 요약 도구까지 대기업식 통제를 붙이면 비용이 과합니다. 위험도에 따라 계층을 나누는 편이 낫습니다.

9. 더 깊게 공부할 포인트

핵심 한 줄: 다음 학습은 모델 프롬프트보다 비인간 계정, 정책-as-code, 관찰 가능성, AI RMF 쪽으로 이동해야 합니다.

• 비인간 신원 관리: 서비스 계정, workload identity, token rotation, least privilege를 학습하십시오.
• AI Gateway: 모델 라우팅, 비용 제한, 요청 로그, provider key 은닉, zero data retention 옵션을 확인하십시오.
• MCP/Tool Gateway: 도구 allowlist, tool-level RBAC, payload logging, pre-execution guardrail을 공부하십시오.
• 런타임 탐지: 단일 요청이 아니라 여러 도구 호출의 순서와 조합을 보는 방법을 익히십시오.
• NIST AI RMF: Govern, Map, Measure, Manage 관점으로 에이전트 리스크를 문서와 지표에 연결하십시오.

10. 참고자료

• Gravitee - State of AI Agent Security Report (Published 2026-06-15, Last updated 2026-04, 확인일 2026-06-30)
• NIST - Artificial intelligence (확인일 2026-06-30)
• NIST AI Risk Management Framework Knowledge Base (확인일 2026-06-30)
• TrueFoundry - Enterprise AI Agent Security Solutions: The Complete Buyer's Guide (2026) (확인일 2026-06-30)
• Gravitee - A2A Summit Hub (확인일 2026-06-30)

11. 실행 체크리스트 + 작성자 관점

핵심 한 줄: 도입 완료 기준은 "에이전트가 잘 답한다"가 아니라 "에이전트가 한 일을 추적하고, 막고, 되돌릴 수 있다"입니다.

• 모든 생산 환경 에이전트에 고유 agent_id와 소유자가 있다
• 공유 API 키 대신 에이전트별 scoped credential을 사용한다
• 읽기, 쓰기, 삭제, 외부 전송, 결제, 배포 권한이 분리되어 있다
• 모델 호출과 도구 호출이 각각 로그로 재구성된다
• 시크릿 노출, 개인정보 외부 전송, 대량 조회, 승인 없는 쓰기 작업의 즉시 중단 기준이 있다
• 사고 의심 시 agent_id 기준 토큰 회수와 도구 차단을 10분 안에 실행할 수 있다
• 파일럿 에이전트는 만료일과 운영 전환 심사를 가진다
• 에이전트 권한 예외는 사유, 승인자, 만료일을 남긴다

Definition of Done: 생산 환경 에이전트 하나를 임의로 골랐을 때, 소유자·권한·모델 호출·도구 호출·최근 작업·정지 방법을 10분 안에 확인할 수 있으면 1차 운영 준비가 끝난 것으로 봅니다.

제 추천은 "확장 전 등록부"입니다. 에이전트 수를 늘리기 전에 현재 존재하는 에이전트부터 목록화하십시오. 등록부에 없는 에이전트는 운영 환경에 접근하지 못하게 하고, 등록된 에이전트도 기본값은 읽기 전용으로 시작하는 편이 낫습니다. 빠른 자동화보다 중요한 것은 사고가 작을 때 멈추는 능력입니다.