피드로 돌아가기
Under the hood: Security architecture of GitHub Agentic Workflows
GitHub BlogGitHub Blog
Security

Under the hood: Security architecture of GitHub Agentic Workflows

GitHub가 Agentic Workflows를 GitHub Actions 위에 구축해 신뢰할 수 없는 AI 에이전트의 접근을 계층적 격리와 권한 제한으로 제어

Landon Cox2026년 3월 9일10intermediate

Context

GitHub Actions는 단일 신뢰 영역(shared trust domain) 모델로 설계되어 모든 프로세스가 같은 권한 수준에서 실행된다. AI 에이전트는 프롬프트 주입 공격에 취약하고 비결정론적 동작을 하기 때문에, 저장소 접근 권한, 인증 토큰, 외부 네트워크 통신 등이 악의적으로 악용될 위험이 있다.

Technical Solution

  • 기판 계층(Substrate Layer) 격리: GitHub Actions 러너 VM 위에서 신뢰할 수 있는 컨테이너를 실행해 에이전트가 접근할 수 있는 리소스를 격리하고 커널 수준의 통신 경계를 강제
  • 구성 계층(Configuration Layer) 제어: 에이전트 API 키, GitHub 접근 토큰 등 외부 토큰을 환경 변수가 아닌 선언적 구성 아티팩트로 관리해 특정 컨테이너에만 로드
  • 계획 계층(Planning Layer) 단계화: 안전한 출력 서브시스템(safe outputs subsystem)으로 워크플로우를 단계별로 구성해 에이전트와 MCP 서버 간 명시적 데이터 교환만 허용
  • MCP 게이트웨이와 API 프록시 중재: 에이전트의 모든 도구 호출과 API 요청을 중앙에서 검증하고 기록하는 중간 계층 도입
  • 포괄적 감시 로깅: 네트워크 계층, API 프록시, MCP 게이트웨이, 에이전트 컨테이너 내부에서 신뢰 경계(trust boundary)마다 모든 활동을 로깅해 사후 분석 가능하도록 설계

Impact

아티클에서 정량적 수치가 명시되지 않음.

Key Takeaway

비결정론적 시스템을 기존 CI/CD 파이프라인에 통합할 때는 단일 신뢰 영역을 유지하지 말고, 격리(isolation), 중재(mediation), 로깅(logging)의 계층적 방어와 권한 제한을 아키텍처 단계에서부터 설계해야 한다.


AI 에이전트나 사용자 제공 코드를 CI/CD에 통합하는 팀은 프롬프트 주입이나 악의적 동작에 대비하기 위해 (1) 컨테이너/VM 수준의 리소스 격리, (2) 중앙화된 API 게이트웨이를 통한 모든 외부 호출 중재, (3) 신뢰 경계마다의 완전한 로깅을 조합해 구현하면 보안 사고의 파급 범위를 제한할 수 있다.

원문 읽기