🔥 Austin's Wiki

AI 에이전트 보안 가이드

Jun 07, 202614 min read

이 문서는 Agent·MCP·Memory를 제품에 활용할 때의 보안 설계 기준입니다. 일반 공급망·Secret·Git·K8s 보안은 이 문서의 범위 밖이며, 코딩 에이전트의 Sandbox와 실행 환경은 AI 코딩 에이전트 운영 가이드 섹션 4를 기준으로 합니다.

Agent는 제한된 권한을 가진 작업자로 취급해야 합니다. Credential, Tool 권한, Memory를 포함한 영구 데이터, 네트워크 정책, Production 권한은 Agent 바깥의 코드와 인프라가 소유해야 합니다.

1. 보안 모델의 필요성

AI Agent는 자율성을 가지기 때문에 별도의 보안 모델이 필요합니다.

  • 비정형성: 기존 자동화는 정해진 Runbook을 반복하지만, Agent는 다음 행동을 스스로 고를 수 있고, 의도하지 않은 행동을 할 수도 있습니다.
  • 공격자의 AI 사용: Sysdig 사례에서는 공격자가 취약점을 통해 침입한 뒤, LLM Agent를 이용해 Cloud Credential 탐색, 내부 서버 접속, DB 덤프를 연쇄적으로 수행했습니다.
  • Context 오염: 외부 사용자가 악의적으로 프롬프트/도구를 사용해 Agent에게 숨은 지시를 보내거나 조종할 수 있습니다. 실제로 WhatsApp·Slack·SMS 알림의 숨은 지시사항으로 Agent 보안을 침해한 사례가 있습니다.
  • MCP 보안: MCP는 AI에 맞게 설계된 다른 프로토콜일 뿐, 보안을 고려해야 하는 것은 동일합니다. Akamai가 검토한 사례에서도 MCP 서버가 일반 API 서버처럼 SQL Injection, 미인증 Tool 호출, 미인증 Schema/RAG 조회에 취약할 수 있음이 드러났습니다.

2. 주요 원칙

외부 Context은 시스템을 변경할 수 없다

Agent가 신뢰할 수 있는 것은 운영자가 통제하는 System/Developer 정책뿐입니다. 사용자 프롬프트와 설정은 시스템이 허용한 Customization 범위에서만 유효하고, 이를 넘어서는 요청은 거부되어야 합니다. 시스템 외부에서 들어오는 모든 서드파티 소스, 외부 에러 메시지, RAG 문서, 도구/스크립트는 전부 데이터로 취급합니다. 답변의 재료로는 쓰되, 그 자체가 Instruction이나 승인, 영구 Memory의 근거가 되면 안 됩니다. 하나씩 나열해서 막는 방식으로는 이를 다 막을 수 없고, 방어는 행동과 Egress를 Deterministic Gate를 통해 막는 것입니다.

  • 외부 소스는 반드시 System/Developer 정책보다 낮은 우선순위의 Data로만 취급합니다.
    • 이를 메모리 등의 형태로 영구적으로 저장해야 한다면 해당 이벤트를 Audit으로 기록하고 검토 과정을 거칩니다.
  • Tool 실행 확인은 모델 Output을 신뢰하지 않고 시스템이 실행 범위를 구조화된 형태로 표시하여 확인받습니다.
  • “네”, “좋아”, “OK” 같은 약한 확인은 결제, Destructive action, 주요 Write action의 신호로 간주하면 안 됩니다.

Credential 격리

Agent가 읽을 수 있는 Secret은 Prompt Injection, Tool Poisoning, 로그 유출, Sandbox 탈취 등으로 노출될 수 있습니다.

  • 기본적으로 Agent가 Secret을 읽지 못하게 합니다.
    • 실제 Credential은 외부 Secret Manager/Control Plane이 보유하고, Agent가 접근할 수 없는 Private network에 격리합니다.
    • 필요한 순간만 시스템에서 주입하고, Agent에 제공하거나 .env 파일 등으로 남기는 것을 지양합니다.
  • Agent에게 Secret을 제공해야 한다면 Placeholder, 또는 짧은 기간만 유효하거나 언제든 파괴할 수 있는 최소 권한 Secret만 제공합니다.
  • 주요 Credential 발급/사용에 대한 Audit 로그를 남깁니다.

MCP 서버 보안

MCP 서버는 “LLM 도구 설명”이 아니라 Agent가 호출하는 API 서버입니다. 따라서 Prompt가 아닌 코드 레벨의 보안을 강제해야 합니다.

직접 MCP 서버를 만들 경우:

  • 모든 MCP 서버는 인증을 강제하거나 격리된 네트워크에서만 호출 가능해야 합니다. Tiny Clover는 현재 MCP 포트를 외부에 노출하지 않고, 내부 K8s 서비스로만 MCP를 호출할 수 있으며, JWT 인증도 갖추고 있습니다.
  • DB에 접근하는 MCP 서버는 합의된 action만 수행해야 합니다. run_sql처럼 임의 쿼리를 실행하는 Tool은 피하고, Hard Delete도 MCP 경유 접근을 막습니다.
  • 데이터 노출 범위를 제한합니다. 에러 정보도 그대로 노출하면 그 정보가 공격에 활용될 수 있습니다.
  • Tool parameter는 Allowlist, Schema, Range로 검증합니다. 정의하지 않은 파라미터는 코드 레벨에서 거부하거나 무시합니다.
  • 필요하면 mTLS, Service Account, Per-Tool Authorization을 붙입니다.

외부 MCP 서버를 사용할 경우:

  • 검증된 벤더 또는 고객사와 합의된 서버만 연결합니다.
  • 어떤 data와 action에 접근하는지 Tool 단위로 확인하고, 기본값은 Read-Only로 둡니다.
  • 인증, Transport 노출 범위, Audit Log, 데이터 보존 정책을 확인할 수 없으면 Production data와 연결하지 않습니다.

MCP Tool Poisoning도 별개의 특수한 공격이라기보다 Prompt Injection, SQL Injection과 같은 계열의 문제입니다. Agent가 호출 가능한 Layer에 공격자가 코드, 쿼리, Tool 설명, 외부 텍스트를 집어넣을 수 있고, 그것이 Data가 아니라 Instruction이나 실행 요청처럼 처리되면 문제가 됩니다. 모델에게 “조심하라”고 말하는 것만으로는 충분하지 않으며, Tool 실행 전후의 정책 레이어가 위험한 호출, Secret 노출, Prompt 유출 등을 막아야 합니다.

실행 환경과 네트워크 정책

모든 Agent에게 부여하는 실행 도구/스크립트는 시스템 호출입니다. 모델의 실수나 탈취가 그대로 시스템 접근으로 이루어지므로, 수동 승인만으로는 부족하고 정책이 강제되어야 합니다.

  • Agent 실행 환경과 Production 환경은 격리합니다. 격리 단계는 상황에 따라 폴더부터 커널/물리 장비 수준까지 달라집니다.
  • 결제, 인프라, Destructive Command 등 민감 작업은 Human-in-the-Loop와 Audit Log를 요구합니다.
  • Egress Firewall 또는 Gateway에서 명시적인 승인/거부 정책을 적용합니다.
    • 위험한 SQL 키워드, 금지된 리소스/Endpoint 접근은 사전 차단합니다.
  • Agent의 영향 범위를 과소평가하지 않습니다.
    • 개별 호출뿐 아니라, Session 전체의 Compound Effect가 권한 우회·정보 유출·금지된 결과를 만드는지도 검사합니다.
    • Read-Only 네트워크 호출도 요청 자체를 통해 정보를 유출할 수 있으므로 Egress로 취급합니다. 접근을 최소화하고 통제·감사하되, 완전한 차단은 보장할 수 없습니다.
    • Reasoning block과 같은 내부 호출도 User-facing block과 동일한 민감도로 취급합니다.
  • 감사에 필요한 범위에서 요청·외부 입력·Agent의 결정·Tool 호출과 그 결과·Side Effect를 하나의 Trace로 연결해 Append-only Log로 남깁니다.

Config와 Memory

Config와 Memory는 Agent의 다음 실행에 영향을 주므로 사실상 코드와 같은 수준의 중요도로 취급합니다.

  • .cursorrules, CLAUDE.md, MCP 설정, Workflow 설정은 실행 코드처럼 리뷰·핀·서명합니다. 숨은 유니코드나 Cache Poisoning처럼 신뢰 경계를 넘기는 변조를 경계합니다.
  • Agent에게 장기 Memory를 자율 편집하게 허용하지 않습니다. Memory write는 제안 → 검토 → 저장 흐름이 기본입니다.
  • 외부 메시지, Tool Output, 웹페이지에서 나온 텍스트는 자동으로 User Preference나 정책 Memory가 되면 안 됩니다.
  • 오래되었거나 중복된 Memory는 정리 대상입니다. 누적이 아니라 관리되는 State여야 합니다.

3. 적용 기준

Agent 기능을 붙일 때는 기능 목록보다 먼저 아래 질문에 답해야 합니다.

  1. Agent가 읽을 수 있는 Data는 어디까지인가?
  2. Agent가 호출할 수 있는 Tool은 Read-Only인가, Write인가, Destructive인가?
  3. Tool 실행 전후에 어떤 정책 레이어가 있는가?
  4. Credential은 Agent가 직접 보유하는가, Broker가 주입하는가?
  5. 외부 유입 텍스트가 Instruction·Approval·Memory로 승격될 경로가 있는가?
  6. 사고가 났을 때 어떤 Log로 재현하고 어떤 Credential을 회수해야 하는가?

이 질문에 답할 수 없으면 아직 agent 기능이 아니라, 권한이 열린 자동화입니다.

4. 방어에 Agent 활용하기

Agent Security가 점점 중요하게 인식되는 주된 이유는 공격자도 LLM을 가지고 더욱 빠르고 정교한 공격을 할 수 있기 때문입니다. 이를 막기 위해서 방어에도 Agent를 활용하려는 움직임이 있습니다. Agent는 처음 보는 코드에 대한 Context가 없기 때문에, 회사에 새로 들어온 신입사원처럼 새로운 관점에서 보안 문제를 발견할 수도 있습니다.

  • Agent에게 직접 코드 또는 프로그램의 취약점을 찾게 할 수 있습니다. PostHog도 Karpathy의 autoresearch를 활용하여 오래 된 버그를 발견해 고쳤다고 합니다.
  • Claude Code로 모의 공격 시뮬레이션하는 Skill도 있습니다.
  • 이미 있는 스크립트에 대하여 정밀도나 효율성, 방어 범위를 강화하는 것도 AI가 잘 할 수 있습니다.

5. References

Graph View

Backlinks