🔥 Austin's Wiki

AI 에이전트 보안 가이드

Jun 07, 202612 min read

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

핵심 원칙은 단순합니다. Agent는 신뢰 주체가 아니라, 제한된 권한을 가진 작업자입니다. 모델은 계획하고 제안할 수 있지만 Credential, Tool 승인, 영구 Memory, 네트워크 정책, Production 권한은 Agent 바깥의 코드와 인프라가 소유해야 합니다.

1. 왜 별도 모델이 필요한가

AI Agent 보안은 일반 웹 보안의 대체물이 아니라, 일반 보안 위에 추가되는 신뢰 경계 문제입니다.

  • 속도와 적응성: 기존 자동화는 정해진 Playbook을 반복하지만, Agent는 실행 결과를 읽고 다음 행동을 고를 수 있습니다. Sysdig 사례에서는 공격자가 LLM Agent를 이용해 취약점 악용, Cloud Credential 탐색, 내부 서버 접속, DB 덤프를 연쇄적으로 수행했습니다.
  • Context 오염: Agent가 외부 알림이나 메시지를 읽는 순간, 그 텍스트는 사용자 대화와 같은 Context에 섞입니다. SafeBreach의 Gemini 사례는 WhatsApp·Slack·SMS 알림에 숨은 지시가 Tool 실행과 Long-Term Memory 오염으로 이어질 수 있음을 보여 줍니다.
  • Tool 표준화의 부작용: MCP는 Agent가 외부 시스템을 다루기 쉽게 만들지만, 서버 구현의 인증·권한·입력 검증은 프로토콜이 대신 해결하지 않습니다. Akamai가 검토한 사례에서도 MCP 서버가 일반 API 서버처럼 SQL Injection, 미인증 Tool 호출, 미인증 Schema/RAG 조회에 취약할 수 있음이 드러났습니다.

결론은 하나입니다. Agent가 읽은 텍스트와 Agent가 가진 권한 사이에는 반드시 정책 레이어가 있어야 합니다.

2. 신뢰 경계

2.1 Context는 자료이지 권한이 아니다

메일, 알림, Slack, 캘린더, 웹페이지, RAG 문서, MCP/Tool output은 모두 외부 유입 텍스트입니다. 답변의 재료로 쓸 수는 있지만, 그 자체가 Instruction, 승인, 영구 Memory의 근거가 되면 안 됩니다.

  • 외부 텍스트는 System/Developer/User Instruction보다 낮은 우선순위의 data로만 취급합니다.
  • Tool 실행 확인은 모델이 자유문장으로 만든 설명이 아니라, 시스템이 생성한 구조화된 Action Summary를 기준으로 받습니다.
  • “네”, “좋아”, “OK” 같은 약한 확인은 Production, 결제, Destructive Action, Recurring Action, Memory Write 승인으로 쓰지 않습니다.
  • 외부 유입 텍스트에서 나온 사실을 Memory에 저장해야 한다면 해당 이벤트를 Audit으로 기록하고 검토 과정을 거칩니다.

2.2 Credential은 Agent 밖에 둔다

Agent가 Raw secret을 들고 있으면 Prompt Injection, Tool output 오염, 로그 유출, Sandbox 탈취가 곧 Credential 탈취가 됩니다. 그래서 Agent에게 Credential을 제공하는 것은 최대한 0에 가깝게 제한합니다.

  • Agent에는 Placeholder, 또는 짧은 기간만 유효하거나 언제든 파괴할 수 있는 Secret만 제공합니다.
  • 실제 Credential은 외부 Secret Manager/Control Plane이 보유하고, 필요한 순간만 시스템에서 주입합니다.
  • 실제 Credential을 가진 주체는 Private network에 격리되어야 합니다.
  • Credential은 작업·서비스·시간 단위로 최소한의 권한만 부여하고 Audit 로그를 남깁니다.

2.3 MCP 서버는 API 서버다

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 유출 등을 막아야 합니다.

2.4 실행과 네트워크는 정책으로 막는다

Agent에게 Tool 권한을 주는 순간, 모델의 실수나 탈취는 실제 시스템 호출이 됩니다. 수동 승인만으로는 부족하고, 실행 경계가 필요합니다.

  • Agent 실행 환경과 Production 환경은 분리합니다.
  • Production, 결제, 인프라, Destructive Command는 Human-in-the-Loop와 Audit Log를 요구합니다.
  • Egress Firewall 또는 Gateway에서 SQL verb, K8s resource, HTTP path 같은 데이터를 기반으로 승인/거부 정책을 적용합니다.
  • Sandbox 내부 동작과 Tool 호출은 Append-Only Log로 남깁니다.

2.5 Config와 Memory는 영구 상태다

Agent Config와 Memory는 다음 실행에 영향을 주므로 사실상 코드와 같습니다.

  • .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