Information-Flow Control(IFC, 정보 흐름 제어)은 AI 에이전트가 읽고 생성하는 데이터에 보안 라벨을 붙이고, 도구 호출 직전에 정책 엔진이 해당 데이터가 어디로 흘러갈 수 있는지 검사하는 보안 모델이다. Microsoft는 IFC를 자율 에이전트 보안의 결정론적 안전장치로 제안한다.
왜 필요한가
에이전트는 이메일 발송, 문서 공유, PR 생성, 데이터 조회처럼 고위험 행동을 할 수 있다. 문제는 같은 행동이 정상 사용자 요청뿐 아니라 모델 실수나 프롬프트 인젝션으로도 발생할 수 있다는 점이다. 사람이 매번 승인하는 방식은 확장성이 낮고, 자율성을 크게 떨어뜨린다.
IFC는 확률적 모델 판단에만 의존하지 않고, 데이터 흐름 자체를 추적한다.
- 데이터 라벨링: 입력 데이터에 무결성(trusted/untrusted)과 기밀성(public/confidential/reader list)을 붙인다.
- 라벨 전파: 에이전트가 생성한 중간 결과와 최종 결과에 원천 데이터 라벨을 보수적으로 전파한다.
- 행동 전 검사: 도구 호출 전 정책 엔진이 라벨과 목적지를 비교해 허용, 차단, 사람 검토 중 하나를 결정한다.
프롬프트 인젝션 방어
대표 예시는 GitHub MCP 서버를 쓰는 코딩 에이전트다. 공개 이슈에 악성 지시가 포함돼 있고, 에이전트가 동시에 비공개 저장소에 접근할 수 있다면 비공개 코드가 공개 이슈 댓글로 유출될 수 있다. IFC에서는 공개 이슈 내용이 untrusted, 비공개 저장소 내용이 private 라벨을 갖는다. 정책은 untrusted + private 컨텍스트가 공개 채널에 쓰이는 것을 차단한다.
이 방식은 mcp 도구 사용 에이전트에서 특히 중요하다. MCP는 도구 접근을 표준화하지만, 도구 호출 사이의 데이터 흐름과 권한 전파까지 자동으로 해결하지는 않는다.
MCP와의 통합
Microsoft의 제안은 MCP의 _meta 필드를 활용한다. 도구 호출 요청과 결과에 라벨을 포함하고, 도구 정의에는 정책을 붙인다. 정책 언어로는 OPA Rego 같은 규칙 엔진을 사용할 수 있다.
중요한 점은 라벨과 정책 판단이 모델의 자연어 추론 바깥에서 동작한다는 것이다. 공격자가 프롬프트로 “이 데이터는 공개 정보다”라고 주장해도, 라벨은 정책 엔진이 별도로 관리한다.
한계와 설계 포인트
- 모든 데이터 소스와 도구가 라벨 전파를 이해해야 효과가 커진다.
- 기밀성 라벨이 너무 보수적이면 에이전트 자율성이 낮아진다.
- 라벨 해제(declassification)는 사람이 검토하거나 명시 정책으로 제한해야 한다.
- 로컬 파일, 원격 MCP, 브라우저, 이메일, 캐시까지 같은 흐름 모델로 묶어야 한다.
관련 문서
- zero-trust-ai-agents — 자율 AI 에이전트를 위한 Zero Trust 보안 아키텍처
- agent-vault — 에이전트 자격증명 분리 프록시
- crabtrap — 에이전트 아웃바운드 HTTP 정책 통제
- mcp — Model Context Protocol
- ms-agent-framework — Microsoft Agent Framework
참고 자료
- Towards secure, autonomous agents with information-flow control (IFC) — Microsoft Command Line (2026-06-16)