💡 CI/CD Agent Trust Boundary Enforcement Standard (Rule of Two)

[github-actions[bot]]

Summary

Implement automated enforcement of the "Rule of Two" security principle for all agentic CI workflows: no single workflow step may simultaneously process untrusted input, access secrets, and execute arbitrary code. This transforms the defensive principle documented by Microsoft (June 2026) and validated by the GitInject research (June 2026) into a statically-verifiable architectural constraint enforced via CI.

Market Signal

Microsoft's security blog (June 5, 2026) formally defined the "Agents Rule of Two" for CI/CD: an AI-powered workflow must never hold all three capabilities simultaneously — processing untrusted input, accessing secrets, and executing code. The GitInject paper (June 2026) confirmed all tested AI coding agents are susceptible to prompt injection in their default CI configuration. Real-world incidents include the Clinejection npm supply chain compromise (Feb 2026), the Claude Code Action credential exfiltration (June 2026), and the "Comment and Control" attack class (April 2026) that demonstrated single malicious PR comments exfiltrating ANTHROPIC_API_KEY, GITHUB_TOKEN, and GEMINI_API_KEY to attacker-visible Actions logs.

User Signal

The org runs multiple AI agents in CI: Claude Code (claude-code-reusable.yml), Copilot coding agent, agent-shield, dev-lead, and feature-ideation. Existing Discussion #485 covers prompt injection threat modeling as documentation, and Discussion #269 covers runtime detection via Agent Shield. The gap is static verification of workflow architecture before deployment — catching trust boundary violations at PR review time, not at exploitation time. The org's pattern of pure-logic decision scripts (scripts/lib/) with CI-gated bats tests makes this a natural fit.

Technical Opportunity

Workflow YAML files are structured data amenable to static analysis. A script in scripts/lib/ could parse workflow files and flag steps that simultaneously: (a) read untrusted inputs (github.event.issue.body, github.event.comment.body, github.event.pull_request.title via ${{ }} expressions), (b) access secrets (secrets.*, env vars sourced from secrets), and (c) run shell commands or invoke actions that execute code. This aligns with the org's "Decision-Making Reusables" pattern — pure logic in a tested script, workflow as thin glue. The existing zizmor integration (Discussion #764) could complement this with its own YAML security analysis.

Assessment

Dimension	Score	Rationale
Feasibility	med	Requires custom YAML parsing logic; false-positive tuning via allowlists
Impact	high	Addresses the #1 attack vector against agentic CI (confirmed by GitInject)
Urgency	high	Active exploitation confirmed in 2026; every agentic workflow is a target

Adversarial Review

Strongest objection: Static analysis of YAML can't capture all trust boundary violations — secrets can be passed through environment variables, actions can internally access credentials, and the analysis will produce false positives for legitimate patterns (like agent-shield, which intentionally processes untrusted input to detect attacks).

Rebuttal: Perfect detection isn't the goal — raising the bar is. A static checker that catches the 80% obvious violations (secrets.GITHUB_TOKEN in a step that reads github.event.issue.body) pays for itself with the first prevented incident. False positives are manageable via allowlist annotations (similar to the NOSONAR markers the org already uses for SonarCloud). Agent-shield's intentional trust boundary crossing would be explicitly allowlisted with documented justification, making the exception visible and auditable rather than invisible and assumed.

Suggested Next Step

Prototype scripts/lib/trust-boundary-check.sh that parses workflow YAML and flags steps combining untrusted-input access + secrets + code execution. Add bats tests covering known-good (properly isolated) and known-bad (combined trust boundary) patterns. Wire into CI as an informational check initially, promoting to blocking after one clean audit cycle.