기계 속도의 Agentic AI: 자율 에이전트가 보안 가정을 무너뜨리는 방식

CoreProse KB-incidents에 최초 게시됨

Agentic AI (에이전트형 AI)는 귀하의 LLM (대규모 언어 모델)을 단순한 채팅 인터페이스에서 민감한 데이터를 읽고, 도구(tools)를 호출하며, 운영 상태(production state)를 변경할 수 있는 기계 속도의 운영자로 변화시킵니다. 이러한 시스템은 단순히 토큰을 예측하는 것에 그치지 않고, API와 워크플로우(workflows) 전반에서 실시간으로 계획을 세우고, 결정하며, 행동합니다. [1]

이러한 변화는 기존의 많은 보안 가정(security assumptions)을 조용히 무효화합니다. 방화벽은 프롬프트 인젝션 (prompt injection)을 분석할 수 없고, 정적인 IAM (ID 및 액세스 관리)은 비결정론적 추론 루프(non-deterministic reasoning loops)를 위해 설계되지 않았으며, SIEM (보안 정보 및 이벤트 관리) 규칙은 에이전트가 왜 도구를 호출했는지 그 _이유_를 거의 이해하지 못합니다. [3][4]

한 중견 SaaS 기업의 경우, Jira, GitHub 및 배포 API에 접근 권한을 가진 “DevOps 코파일럿 (copilot)” 에이전트가 단 하나의 RAG (검색 증강 생성) 런북(runbook)에 의해 오염되었습니다. 이 에이전트는 일상적인 알림 이후 잘못된 마이크로서비스를 롤백하여 40분간의 서비스 중단을 초래했습니다. 모든 API 호출은 기술적으로 권한이 부여된 상태였으나, 실패의 원인은 전송(transport)이 아닌 추론 루프(reasoning loop)에 있었습니다.

이 글은 Agentic AI가 통제되지 않는 슈퍼 유저(super-user)가 아닌 자산이 될 수 있도록, 위협 모델(threat models), 런타임 아키텍처(runtime architecture) 및 모니터링을 재고하는 엔지니어링 중심의 관점을 제시합니다.

챗봇에서 Agentic AI로: 기존 보안 가정이 실패하는 이유

Agentic 시스템은 자율성(autonomy), 도구 사용(tool use), 상태 변경(state changes)이라는 세 가지 축에서 챗봇과 다릅니다. 현대의 에이전트는 다단계 계획을 구성하고, 도구를 호출하며, 목표에 도달할 때까지 반복합니다. [1] 공격 표면(attack surface)은 단순한 프롬프트-완료(prompt-to-completion) 함수가 아니라, 입력, 컨텍스트(context), 행동을 아우르는 _루프(loop)_가 됩니다.

⚡ 핵심 변화: “출력을 필터링한다”는 것은 더 이상 일관된 보안 모델이 아닙니다. 오작동은 단순한 유해 콘텐츠가 아니라 유해한 _행동(actions)_입니다.

챗봇이 주로 텍스트를 생성했던 것과 달리, 기업용 에이전트(enterprise agents)는 이제 다음과 같은 작업을 수행합니다: [10]

민감한 지식 베이스(knowledge bases) 및 RAG 저장소 읽기
CRM/ERP 레코드 및 티켓 수정
코드 및 스크립트 실행
CI/CD, 인사(HR), 또는 재무 시스템의 워크플로(workflows) 트리거

따라서 에이전트의 실수는 UX 오류가 아니라 보안 사고(incident)입니다. [10]

이러한 에이전트들은 개인정보(PII), 재무 데이터, 법적 문서, 백로그 이슈, 프로덕션 로그와 같은 민감한 데이터를 일상적으로 처리합니다. [4] 단 한 번의 손상된 추론 루프(reasoning loop)가 사기 송장 발행부터 대규모 권한 변경에 이르기까지, 단 몇 초 만에 시스템 전반으로 연쇄적인 영향을 미칠 수 있습니다. [1][4]

OWASP LLM Top 10 (2025)은 프롬프트 인젝션(prompt injection), 데이터 유출(data leakage), 모델 오용(model abuse)을 표준 웹 또는 API 위협을 넘어선 별개의 취약점 클래스로 강조합니다. [3] 자율성(Autonomy)은 데이터나 모델 가중치(model weights)뿐만 아니라, _의사결정 루프(decision loop)_라는 새로운 공격 대상을 추가합니다. [3][10]

💡 아키텍처적 시사점: 에이전트 런타임(agent runtime)을 단순히 “챗봇 프로젝트”의 확장판이 아니라, 자체적인 정체성(identity), 정책(policies), 그리고 가드레일(guardrails)을 가진 새로운 오케스트레이션 계층(orchestration layer)으로 취급해야 합니다. [5][6]

소결론: LLM이 계획을 세우고 행동할 수 있게 되면, 보안은 이를 검열해야 할 텍스트가 아니라 도구, 권한, 그리고 폭발 반경(blast radius)을 가진 운영자(operator)로 취급해야 합니다.

새로운 위협 모델: 기계 속도의 위험과 자율적 공격 표면

에이전트 AI(Agentic AI) 플랫폼은 신뢰할 수 없는 입력(untrusted inputs), 민감한 데이터, 그리고 영향력이 큰 외부 행동을 단일 루프 내에서 밀접하게 결합합니다. [11] 강력한 경계(boundaries)가 없다면, 공격자는 기계 속도로 실행되는 취약점 공격(exploits)을 연쇄적으로 수행할 수 있습니다.

핵심 노출 표면(Core exposure surfaces)

일반적인 노출 지점은 다음과 같습니다: [4]

사용자 프롬프트 및 대화 입력 (음성→텍스트 포함)
업로드된 파일 및 RAG 문서 저장소
내부 지식 베이스 및 벡터 DB
플러그인 및 도구 (CRM, ERP, 결제 API, 셸/코드 실행)
장기 메모리 저장소 및 에이전트 로그

각 표면은 공격 대상인 동시에 신뢰 구역(trust zones) 사이를 잇는 가교 역할을 합니다.

⚠️ 에이전트 AI를 위한 위협 카테고리 (2026년 말 분석): [9]

프롬프트 인젝션 (Prompt injection) 및 지시문 조작 (instruction manipulation)
도구 하이재킹 (Tool hijacking) 및 권한 상승 (privilege escalation)
메모리 포이즈닝 (Memory poisoning) 및 검색 인젝션 (retrieval injection)
다단계 계획 (multi-step plans) 전반의 연쇄적 실패 (Cascading failures)
침해된 모델, 도구 또는 커넥터를 통한 공급망 공격 (Supply-chain attacks)

위험한 패턴 중 하나는 "우발적 슈퍼유저 (accidental super-user)"입니다. 엄격한 범위 제한 (scoping)이 없다면, 에이전트는 다음과 같은 행위를 할 수 있는 개체가 됩니다:

제한된 SharePoint에서 데이터 읽기
요약본 합성
이를 외부로 이메일 전송

...이 모든 과정을 자율적으로 수행하며, 원래 이러한 분리를 정당화했던 인간의 확인 절차를 우회합니다. [10][1]

현재의 가이드라인은 AI 특화 자산 (assets) 및 신뢰 경계 (trust boundaries)를 조기에 매핑할 것을 강조합니다. 즉, 어떤 데이터, 어떤 비즈니스 작업, 그리고 어떤 ID(identities)와 비밀 정보(secrets)가 연관되어 있는지를 파악해야 합니다. [10][4] 주요 고가치 타겟은 대개 에이전트가 접근할 수 있는 다운스트림 시스템 (downstream systems)과 데이터입니다.

💼 예시: SOC 환경

보안 운영 센터 (Security operations centers, SOC)는 이미 경보 분류 (triage), 인시던트 보강 (enrich), 그리고 대응 트리거 (trigger containment)를 위해 에이전트를 사용하고 있습니다. [2] 이는 방어자의 레버리지를 높여주지만 위험 부담도 높입니다. 만약 공격자가 플레이북 (playbooks)이나 컨텍스트 (context)를 조작한다면, 동일한 자동화 기능이 제어 장치를 무력화하거나(disable controls) 중요한 경보를 잘못 분류할 수 있기 때문입니다. [2][8]

소결론: 모델 에이전트를 신뢰할 수 없는 입력값에 노출된 교차 도메인 오케스트레이터 (cross-domain orchestrators)로 간주하십시오. 먼저 자산, 경계, 그리고 작업을 열거한 다음, 공격자가 어떻게 루프 (loop)를 조종할 수 있을지 추론하십시오.

에이전트 AI가 전통적인 제어, 컴플라이언스 및 거버넌스를 무너뜨리는 방식

전통적인 보안 제어 장치들은 자연어 지시문이나 확률적 동작 (probabilistic behavior)을 해석하도록 설계되지 않았습니다. 방화벽 (Firewalls), 안티바이러스 (antivirus), 그리고 클래식 SIEM 규칙들은 프롬프트 인젝션 (prompt injection), 검색 포이즈닝 (retrieval poisoning), 또는 미묘한 모델 오용 (model abuse)을 탐지하지 못합니다. [3][4]

레거시 제어 장치가 눈먼 이유

방화벽은 HTTP를 볼 뿐, PDF 내에 숨겨진 적대적 지시문 (adversarial instructions)은 보지 못합니다.
AV 도구는 바이너리 (binaries)를 스캔할 뿐, 비밀 정보를 유출하는 LLM 도구 호출 (tool calls)은 스캔하지 않습니다.
SIEM 규칙은 IP와 포트를 추적할 뿐, "에이전트가 민감한 요약본을 외부로 이메일 전송함"과 같은 상황은 추적하지 못합니다. [4]

이러한 불일치는 OWASP LLM Top 10의 등장으로 이어졌습니다. 기존 프레임워크로는 LLM과 에이전트의 의미론적(semantic) 및 행동적 공격 표면(attack surface)을 표현할 수 없었기 때문입니다. [3][4]

그럼에도 불구하고 대부분의 조직은 여전히 AI 전용 보안 정책이 부족합니다. 대략 4분의 3이 전담 거버넌스(governance) 없이 AI를 운영하고 있습니다. [3] 규제가 강화됨에 따라 이러한 상황은 더 이상 유지될 수 없습니다.

규제 압박의 심화

EU AI Act는 고위험 AI 시스템에 대해 지속적인 리스크 관리, 문서화 및 모니터링을 요구합니다. [3][5] GDPR은 개인 데이터가 영향을 받을 경우 투명성, 설명 가능성(explainability) 및 72시간 이내의 침해 통지를 의무화합니다. [3][7]

개인 데이터를 처리하는 워크플로우(DSR, KYC, HR 자동화 등)에 참여하는 에이전트는 직접적인 컴플라이언스(compliance, 규제 준수) 의무 대상이 됩니다. [7] 설정 오류(misconfiguration)는 엔지니어링 측면의 실패이자 규제 측면의 실패이기도 합니다.

⚠️ 거버넌스의 반전: 도구(tools)와 상태 변화(state changes)가 개입되는 순간, "전통적인 AI 리스크"(환각(hallucination), 편향(bias), 컨텍스트 과잉 공유)는 사이버 리스크로 변모합니다. [5] 예를 들어:

편향된 에이전트가 티켓을 잘못 라우팅하는 것은 무결성(integrity)/가용성(availability) 사고가 됩니다.
내부 첨부 파일이 포함된 환각된 이메일은 데이터 유출이 됩니다.

에이전트 기반 RAG 및 자율 워크플로우가 프로덕션 환경으로 이동함에 따라, 거버넌스 지침은 인간의 감독(human supervision)과 오케스트레이션(orchestration)을 강조합니다. 즉, 어떤 단계에 인간 참여(human-in-the-loop)가 반드시 필요한지, 어떤 단계를 자동화할 수 있는지 명시적으로 정의해야 합니다. [6] 레거시 시스템에 대한 검증되지 않은 자율성은 기존의 보안 통제 기능을 조용히 침식시킵니다.

💡 긍정적인 패턴: 일부 조직은 GDPR 프로세스에 에이전트를 사용하되, 각 결정에 대해 엄격한 로깅(logging), 설명 가능성 및 감사 추적(audit trails)을 요구함으로써 컴플라이언스를 구조화된 텔레메트리(telemetry)로 전환하고 있습니다. [7]

소결론: 에이전트형 AI(Agentic AI)는 전통적인 통제 및 규제와 충돌합니다. 에이전트를 규제 대상이며 감사가 가능한 시스템으로 취급하는 AI 전용 정책, 관측성(observability) 및 거버넌스가 필요합니다.

안전한 에이전트 런타임 설계: 가드레일, 권한, 그리고 2인 원칙(Rule of Two)

에이전트형 AI (Agentic AI)를 보안하는 것은 콘텐츠 필터링의 문제가 아니라 아키텍처의 문제입니다. 현대의 가이드라인은 실행 시간 (Runtime) 동안 매 동작마다 적용되는 **신원 (Identity), 데이터 (Data), 도구 (Tools), 자율성 (Autonomy), 행동 (Behavior), 그리고 관찰 가능성 (Observability)**에 대한 가드레일 (Guardrails)로 수렴하고 있습니다. [1]

에이전트 보안을 위한 4가지 핵심 기둥

정제된 핵심 기둥은 다음과 같습니다: [10]

최소 권한 (Minimal permissions) – 데이터 및 도구에 대한 엄격한 최소 권한 원칙 (Least privilege) 적용
지시문/데이터 분리 (Instruction/data separation) – 제어 프롬프트 (Control prompts)를 사용자 입력 또는 문서와 분리하여 유지
완전한 추적 가능성 (Full traceability) – 프롬프트, 컨텍스트 (Context), 도구 호출 (Tool calls), 출력값 (Outputs)을 모두 기록
민감한 작업에 대한 검증 (Validation on sensitive actions) – 영향력이 큰 단계 이전에 인간 또는 자동화된 체크 수행

이러한 요소가 없다면, 에이전트는 불투명한 슈퍼 유저 (Super-user)로 변질될 가능성이 높습니다. [10]

에이전트를 위한 "2인 원칙 (Rule of Two)"

Databricks는 Meta의 "에이전트를 위한 2인 원칙 (Rule of Two for Agents)"을 채택하고 있습니다. 다음 중 두 가지 이상이 해당될 경우, 추가적인 계층적 제어를 추가해야 합니다: [11]

신뢰할 수 없는 입력 (Untrusted input)
민감한 데이터 (Sensitive data)
영향력이 큰 작업 (High-impact actions)

예시: [11]

신뢰할 수 없는 문서 + 민감한 데이터 → 더 엄격한 입력 검증 및 더 강력한 출력 규칙 적용
신뢰할 수 없는 입력 + 영향력이 큰 작업 → 승인 절차, 속도 제한 (Rate limits), 그리고 더 강력한 정책 적용

런타임 설계 패턴 (Runtime design pattern)

최소한의 보안 에이전트 런타임 예시:

def guarded_agent_step(event, agent_ctx):
    # 1) 입력 분류 및 정화 (Sanitize)
    threat = classify_prompt(event.user_input, event.context_docs)
...

권한은 **도구 경계 (Tool boundary)**에서 강제되며, 정책 엔진 (Policy engine)이 에이전트가 수행할 수 있는 작업을 결정합니다. [4][10]

가드레일 프레임워크는 에이전트를 기존의 IAM (Identity and Access Management)과 통합할 것을 권장합니다. 즉, 각 에이전트는 마이크로서비스 (Microservice)와 같이 고유한 신원, 역할, 그리고 데이터 및 도구에 대한 제한된 접근 권한을 가집니다. [1][5] 비밀 값 (Secrets)과 API 키는 프롬프트나 코드에 내장하는 것이 아니라, 해당 역할에 바인딩되어야 합니다. [10]

💼 SOC 예시: SOC (Security Operations Center) 시나리오에서 가이드라인은 명시적인 자율성 수준("제안만 수행", "저위험 플레이북 자동 실행")과 더불어, 신뢰도, 데이터 품질 또는 정책이 불확실할 때를 대비한 폴백 경로 (Fallback paths)를 강조합니다. [2]

소결론 (Mini-conclusion): 에이전트가 IAM(Identity and Access Management), 정책 또는 검증 과정을 우회할 수 없는 런타임 (Runtimes)을 구축하십시오. 최소 권한 원칙 (Least privilege), 2인 승인 원칙 (Rule of Two), 그리고 액션 수준의 가드레일 (Action-level guardrails)이 핵심 기본 요소 (Primitives)입니다.

Agentic AI를 위한 기계 속도의 모니터링, 탐지 및 대응

에이전트가 기계의 속도로 행동하기 시작하면, 모니터링과 대응 또한 그 속도에 맞춰야 합니다. 설정이 잘못된 Slack 채널로 민감한 요약 정보를 지속적으로 유출하는 에이전트에게 주기적인 감사 (Periodic audits)는 너무 느립니다.

텔레메트리 (Telemetry): 전체 루프 관찰

가이드라인에서는 다음과 같은 항목 전반에 걸쳐 텔레메트리 (Telemetry)를 캡처할 것을 강조합니다: [4][10]

원시 프롬프트 (Raw prompts) 및 중간 메시지
검색된 컨텍스트 (문서, 인덱스, 필드)
도구 호출 (Tool calls) 및 파라미터
최종 출력 및 그에 따른 부수 효과 (Side effects)

이 데이터는 이상 탐지 (Anomaly detection)를 지원합니다: 이상한 데이터 소스, 비정상적인 도구 체인, 또는 일반적인 동작에서 벗어난 행동 등이 이에 해당합니다. [4]

SIEM (Security Information and Event Management) 및 UEBA (User and Entity Behavior Analytics) 플랫폼은 모델의 동작을 사용자 및 인프라 신호와 상관 분석하기 위해 AI 기반 분석을 점점 더 많이 사용하고 있습니다. [8] 예를 들어, "에이전트가 도구 X를 통해 급여 DB에 접근함"과 "비정상적인 IP로부터의 새로운 토큰 발생"을 상관 분석하면 은밀한 권한 오용을 나타낼 수 있습니다.

⚠️ 자율 대응 위험 (Autonomous response risk): SOC (Security Operations Center) 배포 환경에서 에이전트는 봉쇄 및 복구를 조율하지만, 잘못 분류된 이벤트나 조작된 컨텍스트는 비용이 많이 드는 오탐 (False positives, 예: 잘못된 호스트 격리)을 일으키거나 공격을 놓칠 수 있습니다. [2][9]

에이전트 인지 탐지 및 대응

2026년 말의 분석들은 에이전트 위협에 맞춤화된 방어책을 제안합니다: [9]

프롬프트 인젝션 (Prompt injection) 또는 탈옥 (Jailbreak) 시도의 급증 탐지
비정상적인 도구 사용 모니터링 (새로운 도구, 희귀한 인자, 비정상적인 대상)
장기 메모리 (Long-term memory) 또는 이례적인 문서 클러스터에 대한 예기치 않은 접근 추적
데이터 유출 패턴 플래그 표시 (대규모 외부 요약 전송, 민감한 엔티티의 반복적인 내보내기)

에이전트 보안 프레임워크 또한 에이전트 전용 사고 대응 플레이북 (Incident-response playbooks)을 강조합니다: [4][5]

특정 에이전트 또는 기능을 비활성화하거나 "일시 중지"할 수 있는 능력
사고 발생 시간대(incident window) 내의 프롬프트(prompts), 컨텍스트(context), 도구 호출(tool calls)에 대한 포렌식 검토 (Forensic review)
영향을 받은 시스템에 대한 롤백(Rollback) 또는 보상적 변경 (compensating changes)
재발 방지를 위한 가드레일 (guardrails), 정책 또는 데이터 업데이트

런타임 정책 엔진 (Runtime policy engine)은 최후의 방어선이 될 수 있으며, 에이전트의 내부 추론 (internal reasoning)이 해당 동작을 유효하다고 판단하더라도 비정상적인 고영향 (high-impact) 동작을 차단하거나 승인을 요구할 수 있습니다. [1][11]

소결론 (Mini-conclusion): 에이전트를 SIEM, UEBA 및 IR에서 일급 객체 (first-class entities)로 취급하십시오. 에이전트의 프롬프트와 도구 호출을 볼 수 없다면, 이를 보안할 수 없습니다.

구현 청사진 (Implementation Blueprint): 프로덕션 환경에서의 안전한 에이전트형 AI (Secure Agentic AI)

이를 종합하여, 강력하면서도 제어 가능한 에이전트를 구축하기 위한 압축된 청사진을 다음과 같이 제시합니다.