GitHub Agentic Workflows run on top of GitHub Actions, and that architecture creates a serious security problem: a shared trust domain means a compromised or prompt-injected agent can read secrets, hit arbitrary network endpoints, and write noise to every open issue in your repository. GitHub's answer is a three-layer defense model, substrate, configuration, and planning, each enforcing distinct security properties independent of the layers above it. The substrate layer uses runner VMs and Docker containers with kernel-enforced boundaries. The configuration layer controls which tokens load into which containers. The planning layer stages writes and filters outputs before anything reaches your repository.
The threat model here is explicit and worth reading in full: GitHub assumes agents will attempt to read and write state they should not, abuse legitimate channels, and communicate over unintended paths. That assumption drives four design principles: defense in depth, zero agent access to secrets, staged and vetted writes, and full logging. Secrets never land in agent-accessible environment variables. Instead, an MCP gateway container holds authentication material exclusively, and all LLM API calls route through a dedicated proxy. A firewall enforces an allowlist for egress, not a blocklist.
The detail that makes this article worth reading past the summary is how the planning layer handles prompt injection specifically: output sanitization strips secrets and applies moderation before writes, and call filtering caps both the availability and volume of tool calls the agent can make at runtime. GitHub is treating agent execution as a constrained extension of CI/CD, not a separate runtime with its own rules. The architecture is already compiled into GitHub Actions with explicit permissions and auditable logs, which means the guardrails are not bolted on after the fact.
[READ ORIGINAL →]