GitHub, Agentic Workflows 보안 아키텍처 공개

GitHub는 2026-03-09 게시글에서 GitHub Actions 위에서 Agentic Workflows를 어떻게 보호하는지 자세히 설명했다. 이 글의 출발점은 agent를 “편한 자동화 도구”가 아니라, untrusted input을 읽고 저장소 상태를 해석하며 실행 중 위험한 판단을 내릴 수 있는 비결정적 구성요소로 본다는 점이다.

보안 모델을 먼저 둔 설계

GitHub의 문제 정의는 분명하다. 기존 CI/CD에서는 하나의 trust domain 안에서 넓은 권한을 공유하는 것이 주로 편의 기능이었다. 하지만 agent가 들어오면 같은 구조가 곧 blast radius 확대가 될 수 있다. prompt injection이나 버그가 있는 agent가 secrets를 읽거나 MCP server를 건드리거나 임의의 host로 네트워크 요청을 보낼 수 있기 때문이다. 그래서 GitHub는 Agentic Workflows가 기본적으로 strict mode로 동작하며, defense in depth, don’t trust agents with secrets, stage and vet all writes, log everything이라는 네 가지 원칙을 따른다고 설명한다.

세 개의 방어 계층

아키텍처는 substrate, configuration, planning의 세 계층으로 설명된다. substrate layer는 GitHub Actions runner VM과 trusted container를 사용해 구성요소를 분리하고 privileged operation을 중재한다. configuration layer는 어떤 구성요소가 존재하고 어떻게 연결되며 어떤 token이 어느 container에 실리는지 결정한다. planning layer는 단계별 workflow와 data exchange를 명시적으로 나눠 상위 orchestration이 하위 통제를 우회하지 못하게 만든다.

가장 중요한 설계 중 하나는 “zero-secret agents”다. GitHub는 model auth token이나 MCP credential을 agent container에 직접 넣지 않고, LLM 트래픽은 isolated API proxy를 통해 보내고 MCP 접근은 trusted MCP gateway로 제한한다고 설명한다. 네트워크 접근은 firewall로 좁히고, agent는 chroot jail 안에서 동작한다. 즉 코딩에 필요한 로컬 문맥은 유지하되, agent가 발견하거나 덮어쓸 수 있는 범위는 최대한 줄이겠다는 접근이다.

왜 의미가 큰가

GitHub가 실제로 주장하는 것은 agent runtime 보안을 부가 기능이 아니라 CI/CD 계약의 일부로 다뤄야 한다는 점이다. 기업 도입의 핵심 장애물은 agent가 코드를 쓸 수 있느냐보다, token과 저장소 상태, production workflow 근처에서 얼마나 예측 가능하게 통제되느냐다. isolated execution, constrained outputs, staged writes를 전면에 둔 이번 설명은 agentic automation을 실험적 prompt 조합이 아니라 governed infrastructure로 보이게 만들려는 시도로 읽힌다.