💡 Agentic Workflow Confused Deputy Defense & Privilege Separation Standard

[github-actions[bot]]

Summary

Codify an enforceable standard that prevents the "confused deputy" anti-pattern in agentic CI workflows — where a single workflow simultaneously processes untrusted input (issue/PR content), holds secrets (GITHUB_TOKEN with write scopes), and can change state (bash, gh CLI, file writes). Require privilege separation: workflows that ingest untrusted data get read-only permissions; state-changing steps receive only pre-validated, structured inputs. This addresses the #1 active exploitation class targeting AI-powered CI pipelines.

Market Signal

Microsoft Threat Intelligence documented a prompt injection pathway in Claude Code GitHub Action (June 2026). The TaintAWI research project (arXiv:2605.07135) analyzed 13,392 agentic workflows across 10,792 repositories, confirming 496 exploitable vulnerabilities — including 343 previously unknown zero-days. The Cloud Security Alliance published a research note on Claude Code Action prompt injection. Aikido Security coined the "PromptPwnd" attack class and confirmed exposure in at least five Fortune 500 companies. VentureBeat reported that three AI coding agents leaked secrets through a single prompt injection vector.

The common thread: a workflow that can (1) read untrusted input, (2) hold secrets, and (3) execute state-changing tools is a confused deputy. Patching individual tools (e.g., claude-code-action v1.0.94+) addresses specific vectors but not the architectural anti-pattern.

User Signal

Existing discussions address adjacent concerns without prescribing structural privilege separation:

• 💡 Agent Shield v2: CI Pipeline Prompt Injection Sentinel #269 — Agent Shield v2: CI Pipeline Prompt Injection Sentinel
• 💡 Agent Prompt Injection Threat Model and CI Hardening Playbook #485 — Agent Prompt Injection Threat Model and CI Hardening Playbook
• 💡 CI/CD Agent Trust Boundary Enforcement Standard (Rule of Two) #974 — CI/CD Agent Trust Boundary Enforcement Standard (Rule of Two)
• 💡 Agentic Workflow Prompt Injection Red Team Canary Standard #975 — Agentic Workflow Prompt Injection Red Team Canary Standard

The org runs dev-lead, pr-review, feature-ideation, compliance-audit, and persona-mention workflows — all processing untrusted issue/PR content with write-scoped GITHUB_TOKEN. Bug #1133 (persona-mention router ignores stop_markers) demonstrates that even trusted dispatch paths have control-flow gaps that could be exploited by crafted input.

Technical Opportunity

The org's reusable workflow architecture already separates "thin I/O glue" from "pure decision logic" (per AGENTS.md). Extending this to separate "untrusted input ingestion" (Job A: read-only permissions, gathers facts) from "privileged state mutation" (Job B: write permissions, receives structured inputs only) aligns with the existing architectural pattern. Key enablers:

1. GitHub's granular GITHUB_TOKEN permissions — including the new vulnerability-alerts: read permission (Sept 2026) — allow per-job least-privilege
2. Job outputs provide a structured interface between the read-only and write phases
3. agent-shield.yml already exists as a CI workflow template and could enforce the separation at lint time
4. The "pure script" pattern (canary-rollout.sh, ready-check.sh) already isolates decision logic — the standard extends this to isolate input handling

Proposed privilege separation model:

Job 1 (read-only): permissions: { contents: read, issues: read, pull-requests: read }
  → Ingests untrusted input (issue body, PR diff, comments)
  → Runs AI agent with read-only tools
  → Outputs structured decision (JSON via job outputs)

Job 2 (write): permissions: { contents: write, issues: write }
  → Receives ONLY structured job outputs (no raw untrusted input)
  → Executes state changes (post comments, push commits, create PRs)
  → Cannot be directly influenced by untrusted input

Assessment

Dimension	Score	Rationale
Feasibility	med	Requires splitting some single-job workflows into multi-job pipelines
Impact	high	Prevents the #1 active exploitation class (496 confirmed vulns industry-wide)
Urgency	high	Active exploitation documented by Microsoft, CSA, Aikido; org runs affected patterns

Adversarial Review

Strongest objection: The Claude Code Action was already patched (v1.0.94+, org is on v1.0.221). The org's workflows use GITHUB_TOKEN (not PATs), limiting blast radius. Privilege separation adds workflow complexity and may require splitting single workflows into multi-job pipelines, increasing Actions minutes consumption on an already-constrained free plan.

Rebuttal: The patch fixes one tool's specific vulnerability; the architectural pattern exists in every agentic workflow that processes PR/issue content. GITHUB_TOKEN with discussions:write or contents:write is sufficient to exfiltrate data (post it as a comment) or tamper with the repo (push to a branch). The complexity cost is real but bounded: most workflows already have a "gather facts" phase and an "act on them" phase — formalizing this as separate jobs with distinct permission blocks is incremental, not a rewrite. The Actions minutes overhead is one additional job spin-up (~15 seconds) per workflow run. The alternative is accepting that every new agentic tool integration re-introduces the confused deputy risk.

Suggested Next Step

Audit the org's agentic workflows for the three-capability anti-pattern (untrusted input + secrets + state-changing tools in the same job). Document findings with severity ratings. Draft a privilege separation standard in standards/ with an enforcement check in agent-shield.yml that flags workflows where a job both reads untrusted event data and holds write permissions.

[redbotster]

the architectural fix is splitting ingestion and execution into separate workflow jobs with a serialized validated artifact in between, never letting the same job context hold write-scoped GITHUB_TOKEN and also parse untrusted text. the ingestion job (permissions: contents: read) extracts structured data, then a downstream job (permissions: write) consumes only that struct. this is orthogonal to patching individual tools and you can do it today with vanilla github actions by using job outputs or artifact uploads as the handoff boundary. on the secrets side, scoped short-lived credentials per step reduce blast radius when a step is compromised. i work on 1claw, which keeps raw secrets out of the workflow env and model context entirely by giving agents path references to an HSM-backed vault instead, which is worth considering for the token handling piece of this.

[redbotster]

the architectural fix here is correct: separate the ingestion step (read-only, no secrets) from the action step (secrets, no raw user input), and pass only a validated structured payload between them. in github actions this means two jobs with explicit permissions: blocks and no shared env that crosses the trust boundary. the validated payload should be a narrow schema, not a string that can carry injected instructions.

one thing that helps on the secrets side: if the agent never holds a raw key and instead gets a short-lived scoped token that references a vault path, you eliminate an entire class of exfiltration even if injection succeeds. that's the model we're building toward with 1Claw (full disclosure: i work on it), but the privilege separation point stands regardless of how you manage secrets.