-
Notifications
You must be signed in to change notification settings - Fork 371
docs: expand security architecture section on homepage for non-security audiences #24026
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -57,13 +57,43 @@ Developed by GitHub Next and Microsoft Research, workflows run with added guardr | |||||
|
|
||||||
| ## Guardrails Built-In | ||||||
|
|
||||||
| Workflows run with read-only permissions by default. Write operations require explicit approval through sanitized [safe outputs](/gh-aw/reference/glossary/#safe-outputs) (pre-approved GitHub operations), with sandboxed execution, tool allowlisting, and network isolation ensuring AI agents operate within controlled boundaries. | ||||||
| AI agents can be manipulated into taking unintended actions—through malicious repository content, compromised tools, or prompt injection. GitHub Agentic Workflows addresses this with five security layers that work together to contain the impact of a confused or compromised agent. | ||||||
|
|
||||||
| Every workflow runs through a three-stage security pipeline before any write operation can occur: | ||||||
| ### Read-only tokens | ||||||
|
|
||||||
| The AI agent receives a GitHub token scoped to read-only permissions. Even if the agent attempts to create a pull request, push code, or delete a file, the underlying token simply doesn't allow it. The agent can observe your repository; it cannot change it. | ||||||
|
|
||||||
| ### Zero secrets in the agent | ||||||
|
|
||||||
| The agent process never receives write tokens, API keys, or other sensitive credentials. Those secrets exist only in separate, isolated jobs that run _after_ the agent has finished and its output has passed review. A compromised agent has nothing to steal and no credentials to misuse. | ||||||
|
|
||||||
| ### Containerized with a network firewall | ||||||
|
|
||||||
| The agent runs inside an isolated container. A built-in network firewall—the [Agent Workflow Firewall](/gh-aw/introduction/architecture/#agent-workflow-firewall-awf)—routes all outbound traffic through a Squid proxy enforcing an explicit domain allowlist. Traffic to any other destination is dropped at the kernel level, so a compromised agent cannot exfiltrate data or call out to unexpected servers. | ||||||
|
||||||
| The agent runs inside an isolated container. A built-in network firewall—the [Agent Workflow Firewall](/gh-aw/introduction/architecture/#agent-workflow-firewall-awf)—routes all outbound traffic through a Squid proxy enforcing an explicit domain allowlist. Traffic to any other destination is dropped at the kernel level, so a compromised agent cannot exfiltrate data or call out to unexpected servers. | |
| The agent runs inside an isolated container. A built-in network firewall—the [Agent Workflow Firewall](/gh-aw/introduction/architecture/#agent-workflow-firewall-awf)—uses iptables to redirect HTTP and HTTPS traffic through a Squid proxy with an explicit domain allowlist, and to drop non-allowed egress at the kernel level. This prevents a compromised agent from exfiltrating data or calling out to unexpected servers. |
Copilot
AI
Apr 2, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Threat detection can be explicitly disabled in workflows (e.g., threat-detection: false). To keep the homepage accurate, consider qualifying this with "by default" / "when enabled" or "when safe outputs are configured" rather than stating it always runs before any output is applied.
| Before any output is applied, a dedicated [threat detection job](/gh-aw/reference/threat-detection/) runs an AI-powered scan of the agent's proposed changes. It checks for prompt injection attacks, leaked credentials, and malicious code patterns. If anything looks suspicious, the workflow fails immediately and nothing is written to your repository. | |
| When threat detection is enabled, before any output is applied, a dedicated [threat detection job](/gh-aw/reference/threat-detection/) runs an AI-powered scan of the agent's proposed changes. It checks for prompt injection attacks, leaked credentials, and malicious code patterns. If anything looks suspicious, the workflow fails immediately and nothing is written to your repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"passed review" is ambiguous here and reads like a human review step, but the security model described is automated gating (safe-outputs validation + optional threat detection) before any secrets/write-token job runs. Consider rephrasing to something like "after the agent completes and its output passes validation/threat-detection gates" to avoid implying manual review.