@vigolium/piolium 0.0.1

package/skills/agentic-actions-auditor/references/action-profiles.md

@@ -0,0 +1,186 @@
+# Action Security Profiles
+
+Security-relevant configuration fields, default behaviors, dangerous configuration patterns, and remediation guidance for each supported AI action. Referenced by SKILL.md Step 5 for action-specific remediation.
+
+## Claude Code Action
+
+### Default Security Posture
+
+- Bash tool disabled by default; commands must be explicitly allowed via `--allowedTools` in `claude_args`
+- Only users with repository write access can trigger (default when `allowed_non_write_users` is omitted)
+- GitHub Apps and bots blocked by default (when `allowed_bots` is omitted)
+- Commits to new branch, does NOT auto-create PRs (requires human review)
+- Built-in prompt sanitization strips HTML comments, invisible characters, markdown image alt text, hidden HTML attributes, HTML entities
+- `show_full_output: false` by default (prevents secret leakage in workflow logs)
+
+### Dangerous Configurations
+
+| Configuration | Risk |
+|--------------|------|
+| `claude_args: "--allowedTools Bash(*)"` | Unrestricted shell access; any prompt injection achieves full RCE |
+| `allowed_non_write_users: "*"` | Any GitHub user can trigger the action, including external contributors and attackers |
+| `allowed_bots: "*"` | Any bot can trigger, enables automated attack chains via bot-to-bot escalation |
+| `show_full_output: true` (in public repos) | Exposes full conversation including potential secrets in workflow logs |
+| `prompt` containing `${{ github.event.* }}` | Direct expression injection of attacker-controlled content into AI prompt |
+
+### Remediation Patterns
+
+**Restrict shell access:** Replace `Bash(*)` with specific tool patterns:
+
+```yaml
+claude_args: '--allowedTools "Bash(npm test:*) Bash(git diff:*)"'
+```
+
+**Restrict user access:** Remove wildcard allowlists or replace with explicit user lists:
+
+```yaml
+allowed_non_write_users: "trusted-user1,trusted-user2"
+```
+
+**Restrict bot access:** Remove `allowed_bots: "*"` or list specific trusted bots:
+
+```yaml
+allowed_bots: "dependabot[bot],renovate[bot]"
+```
+
+**Prevent prompt injection:** Never pass attacker-controlled event data (issue body, PR title, comment body) to the `prompt` field via env vars or direct `${{ }}` expressions. Validate and sanitize input in a prior step.
+
+**Protect log output:** Keep `show_full_output: false` (default) in public repositories.
+
+## OpenAI Codex
+
+### Default Security Posture
+
+- Sandbox defaults to `workspace-write` (read/edit in workspace, run commands locally, no network)
+- Safety strategy defaults to `drop-sudo` (removes sudo privileges before running Codex)
+- Empty `allow-users` permits only write-access repository members (default)
+- `allow-bots: false` by default
+- Network off by default (must be explicitly enabled)
+- Protected paths: `.git`, `.vig-agent/`, `.codex/` directories are read-only even in writable sandbox
+
+### Dangerous Configurations
+
+| Configuration | Risk |
+|--------------|------|
+| `sandbox: danger-full-access` | No sandbox, no approvals, unrestricted filesystem and network access |
+| `safety-strategy: unsafe` | Disables all safety enforcement including sudo restrictions |
+| `allow-users: "*"` | Any GitHub user can trigger the action |
+| `allow-bots: true` | Any bot can trigger, enables automated attack chains |
+| `danger-full-access` + `unsafe` combined | Maximum exposure: no sandbox, no safety, full system access |
+
+### Remediation Patterns
+
+**Restrict sandbox:** Use the default or a more restrictive mode:
+
+```yaml
+sandbox: workspace-write    # default: workspace access only, no network
+sandbox: read-only          # for analysis-only tasks
+```
+
+**Restrict safety strategy:** Use the default or a stricter option:
+
+```yaml
+safety-strategy: drop-sudo          # default: removes sudo privileges
+safety-strategy: unprivileged-user  # stronger: runs as unprivileged user
+```
+
+**Restrict user access:** Remove wildcard or replace with explicit user list:
+
+```yaml
+allow-users: "maintainer1,maintainer2"
+```
+
+**Restrict bot access:** Keep `allow-bots: false` (default) unless specific trusted bots need access.
+
+**Organization-level enforcement:** Use `requirements.toml` to block `danger-full-access` at the organization level, preventing individual repos from weakening sandbox policy.
+
+## Gemini CLI
+
+### Default Security Posture
+
+- Sandbox off by default for the GitHub Action (no `--sandbox` flag set)
+- When sandbox is enabled, default profile is `permissive-open` (restricts writes outside project directory)
+- Default approval mode requires confirmation for tool calls
+- When `--yolo` is used, sandbox is enabled automatically (safety measure)
+- Tool restriction via `tools.core` allowlist in settings JSON (e.g., `["run_shell_command(echo)"]`)
+- No built-in user allowlist field -- access controlled by workflow trigger permissions only
+
+### Dangerous Configurations
+
+| Configuration | Risk |
+|--------------|------|
+| `settings: '{"sandbox": false}'` | Explicitly disables sandbox (note: JSON inside YAML string) |
+| `--yolo` or `--approval-mode=yolo` in CLI args | Disables approval prompts for all tool calls |
+| `tools.core` containing `run_shell_command(echo)` | Enables subshell expansion bypass -- confirmed RCE vector (Vector F) |
+| `tools.allowed: ["*"]` | Bypasses confirmation for all tools |
+
+### Remediation Patterns
+
+**Enable sandbox:** Add sandbox configuration to the settings JSON:
+
+```yaml
+settings: '{"sandbox": true}'
+```
+
+Or pass the `--sandbox` flag in CLI arguments.
+
+**Remove dangerous approval modes:** Remove `--yolo` and `--approval-mode=yolo` from CLI args. Use the default approval mode that requires confirmation for tool calls.
+
+**Restrict tool lists:** Remove `run_shell_command(echo)` and other expandable commands from `tools.core`. Use specific non-shell tools only:
+
+```json
+{
+  "tools": {
+    "core": ["read_file", "write_file", "list_directory"]
+  }
+}
+```
+
+**Container-based sandboxing:** If shell access is required, use container-based sandboxing to limit blast radius rather than relying on the built-in sandbox profile alone.
+
+## GitHub AI Inference
+
+### Default Security Posture
+
+- Inference-only API call -- no shell access, no filesystem access, no sandbox to configure
+- Access controlled by GitHub token scope
+- Primary risks: prompt injection via untrusted event data (Vector B), and AI output flowing to `eval` in subsequent workflow steps (Vector G)
+
+### Dangerous Configurations
+
+| Configuration | Risk |
+|--------------|------|
+| `prompt` containing `${{ github.event.* }}` | Attacker-controlled event contexts injected directly into AI prompt (Vector B) |
+| Overly scoped `token` parameter | Grants more permissions than needed, expanding blast radius of any exploitation |
+| AI output consumed by `eval`/`exec` in subsequent steps | Converts inference-only action into code execution vector (Vector G) |
+
+### Remediation Patterns
+
+**Sanitize prompt inputs:** Validate and sanitize event data before including in prompts. Do not pass raw `${{ github.event.issue.body }}` or similar attacker-controlled fields.
+
+**Minimize token scope:** Use minimum-scope tokens following the principle of least privilege. Only grant permissions the inference call actually needs.
+
+**Protect AI output consumption:** Never pass AI output through `eval`, `exec`, or unquoted `$()` in subsequent workflow steps:
+
+```yaml
+# DANGEROUS: AI output executed as code
+- run: eval "${{ steps.inference.outputs.result }}"
+
+# SAFE: AI output stored and validated before use
+- run: |
+    RESULT='${{ steps.inference.outputs.result }}'
+    echo "$RESULT"  # display only, no execution
+```
+
+**Validate structured output:** If structured output (JSON) is needed from the AI, validate against a schema before using in shell commands.
+
+## Per-Action Remediation Quick Reference
+
+| Remediation Need | Claude Code Action | OpenAI Codex | Gemini CLI | GitHub AI Inference |
+|-----------------|-------------------|--------------|------------|-------------------|
+| Restrict shell access | `--allowedTools "Bash(specific:*)"` | `sandbox: workspace-write` | Remove expandable commands from `tools.core` | N/A (no shell) |
+| Restrict user access | `allowed_non_write_users: "user1,user2"` | `allow-users: "user1,user2"` | Control via workflow trigger permissions | Control via token scope |
+| Disable dangerous mode | Remove `Bash(*)` from `claude_args` | Remove `danger-full-access` from `sandbox` | Remove `--yolo` from CLI args | N/A |
+| Sandbox enforcement | N/A (tool-level restriction) | `sandbox: read-only` | `"sandbox": true` in settings JSON | N/A (no execution) |
+| Block bot triggers | Remove `allowed_bots: "*"` | Set `allow-bots: false` | Control via workflow trigger conditions | Control via token scope |
+| Protect output/logs | Keep `show_full_output: false` | N/A | N/A | Never `eval` AI output |

package/skills/agentic-actions-auditor/references/cross-file-resolution.md

@@ -0,0 +1,209 @@
+# Cross-File Resolution: Composite Actions and Reusable Workflows
+
+AI agents can be hidden inside composite actions and reusable workflows, invisible when analyzing only the caller workflow file. This reference documents how to classify `uses:` references, resolve the referenced files, trace input mappings across file boundaries, and report unresolved references.
+
+Resolution is limited to one level deep (fixed). If a resolved file contains its own cross-file references, log them as unresolved -- do not follow.
+
+## uses: Reference Classification
+
+Parse each `uses:` value to determine its type and resolution strategy.
+
+| `uses:` Pattern | Reference Type | Resolution | In Scope? |
+|----------------|---------------|------------|-----------|
+| `./path/to/action` | Local composite action | Read `{path}/action.yml` from filesystem | YES |
+| `./.github/workflows/called.yml` | Local reusable workflow | Read file from filesystem | YES |
+| `owner/repo/.github/workflows/file.yml@ref` | Remote reusable workflow | Fetch via `gh api` Contents API | YES |
+| `docker://image:tag` | Docker image | N/A -- no steps to analyze | NO (skip) |
+| `owner/repo@ref` (without `.github/workflows/`) | Remote action | Would require remote action.yml fetch | NO (skip silently) |
+
+**Classification algorithm:**
+
+```
+Given a uses: value:
+1. Starts with "./" AND path contains ".github/workflows/" -> LOCAL REUSABLE WORKFLOW
+2. Starts with "./" -> LOCAL COMPOSITE ACTION
+3. Contains ".github/workflows/" AND contains "@" -> REMOTE REUSABLE WORKFLOW
+4. Starts with "docker://" -> DOCKER IMAGE (skip)
+5. Else -> REMOTE ACTION (out of scope, skip silently)
+```
+
+Order matters: check step 1 before step 2, because local reusable workflows also start with `./`.
+
+**Context distinction:** Step-level `uses:` (inside `steps:` array) references actions. Job-level `uses:` (at the same level as `runs-on:`) references reusable workflows. Local reusable workflows use job-level `uses:` with a `./` prefix.
+
+## Local Composite Action Resolution
+
+**Given:** `uses: ./path/to/action` at the step level.
+
+**Local analysis mode:**
+1. Read `{path}/action.yml` from the filesystem using the Read tool
+2. If not found, try `{path}/action.yaml` (GitHub supports both, prefers `.yml`)
+3. If neither exists, log as unresolved with reason "File not found"
+
+**Remote analysis mode:**
+1. Fetch via Contents API: `gh api repos/{owner}/{repo}/contents/{path}/action.yml?ref={ref} --jq '.content | @base64d'`
+2. On 404, try `action.yaml`: `gh api repos/{owner}/{repo}/contents/{path}/action.yaml?ref={ref} --jq '.content | @base64d'`
+3. If both 404, log as unresolved with reason "File not found"
+
+**Type discrimination -- check `runs.using`:**
+
+| `runs.using` Value | Action Type | Analyze? |
+|-------------------|-------------|----------|
+| `composite` | Composite action | YES -- scan `runs.steps[]` |
+| `node12`, `node16`, `node20`, `node24` | JavaScript action | NO -- skip silently |
+| `docker` | Docker action | NO -- skip silently |
+
+Only composite actions have `runs.steps[]` containing workflow-style steps. If `runs.using` is not `composite`, skip silently -- do NOT log as unresolved.
+
+**Analysis of composite action steps:**
+1. For each step in `runs.steps[]`, check `uses:` against the known AI action references (SKILL.md Step 2)
+2. If an AI action is found, capture its `with:` fields for security context (SKILL.md Step 3)
+3. Run the same attack vector detection (SKILL.md Step 4) on each AI action step found
+4. Any `uses:` cross-file references found inside the resolved file are logged as unresolved (depth limit) -- do NOT follow them
+
+## Local Reusable Workflow Resolution
+
+**Given:** Job-level `uses: ./.github/workflows/called.yml`.
+
+**Local analysis mode:**
+1. Read the file from the filesystem using the Read tool
+
+**Remote analysis mode:**
+1. Fetch via Contents API using the same repo context: `gh api repos/{owner}/{repo}/contents/.github/workflows/{filename}?ref={ref} --jq '.content | @base64d'`
+
+The resolved file is a complete workflow YAML with `on: workflow_call`. Analyze it through the existing Steps 2-4 detection pipeline -- identify AI action steps, capture security context, and detect attack vectors.
+
+**Input mapping:** The caller passes values via job-level `with:`, and the called workflow accesses them via `${{ inputs.* }}` (defined under `on: workflow_call: inputs:`).
+
+## Remote Reusable Workflow Resolution
+
+**Given:** Job-level `uses: owner/repo/.github/workflows/file.yml@ref`.
+
+**Parse the reference:**
+- Extract: `owner`, `repo`, file path (everything after `repo/` and before `@`), and `ref` (everything after `@`)
+- Example: `org/shared/.github/workflows/review.yml@main` -> owner=`org`, repo=`shared`, path=`.github/workflows/review.yml`, ref=`main`
+
+**Fetch:**
+```
+gh api repos/{owner}/{repo}/contents/.github/workflows/{filename}?ref={ref} --jq '.content | @base64d'
+```
+
+This is the same Contents API pattern established in Step 0 (Phase 5).
+
+**Error handling:**
+- 404: Log as unresolved with reason "404 Not Found (repository may be private)"
+- Auth error (401/403): Log as unresolved with reason "Authentication required"
+
+Analyze the resolved workflow YAML through existing Steps 2-4. Cross-file findings mix into the main findings list sorted by severity -- they just have a longer file-chain trace.
+
+## Input Mapping Traces
+
+When an AI action is found inside a resolved file, trace the data flow from the caller's `with:` values through `inputs.*` to the AI prompt field. This extends the existing data flow trace pattern from foundations.md.
+
+### Composite Action Input Trace
+
+```
+Caller workflow (.github/workflows/review.yml):
+  steps:
+    - uses: ./actions/issue-triage
+      with:
+        issue_body: ${{ github.event.issue.body }}    # attacker-controlled
+
+Composite action (actions/issue-triage/action.yml):
+  inputs:
+    issue_body:
+      description: "The issue body text"
+  runs:
+    using: composite
+    steps:
+      - uses: anthropics/claude-code-action@v1
+        with:
+          prompt: "Triage this issue: ${{ inputs.issue_body }}"
+```
+
+**Data flow trace:**
+```
+1. Attacker creates issue with malicious content in body
+2. Caller: with.issue_body = ${{ github.event.issue.body }}
+   -> .github/workflows/review.yml, jobs.triage.steps[1]
+3. Composite action receives: inputs.issue_body = attacker content
+   -> actions/issue-triage/action.yml, inputs.issue_body
+4. AI action: prompt contains ${{ inputs.issue_body }}
+   -> actions/issue-triage/action.yml, runs.steps[0]
+5. Claude executes with tainted prompt -- attacker achieves prompt injection
+```
+
+### Reusable Workflow Input Trace
+
+```
+Caller workflow (.github/workflows/ci.yml):
+  jobs:
+    ai-review:
+      uses: org/shared/.github/workflows/ai-review.yml@main
+      with:
+        pr_body: ${{ github.event.pull_request.body }}
+
+Called workflow (org/shared/.github/workflows/ai-review.yml):
+  on:
+    workflow_call:
+      inputs:
+        pr_body:
+          type: string
+  jobs:
+    review:
+      runs-on: ubuntu-latest
+      steps:
+        - uses: anthropics/claude-code-action@v1
+          with:
+            prompt: "Review this PR: ${{ inputs.pr_body }}"
+```
+
+**Data flow trace:**
+```
+1. Attacker opens PR with malicious content in body
+2. Caller: with.pr_body = ${{ github.event.pull_request.body }}
+   -> .github/workflows/ci.yml, jobs.ai-review
+3. Reusable workflow receives: inputs.pr_body = attacker content
+   -> org/shared/.github/workflows/ai-review.yml, on.workflow_call.inputs
+4. AI action: prompt contains ${{ inputs.pr_body }}
+   -> org/shared/.github/workflows/ai-review.yml, jobs.review.steps[0]
+5. Claude executes with tainted prompt via pull_request_target (has secrets access)
+```
+
+The trace format follows the same stacked multi-line style as other data flow traces in this skill. Each hop shows the relevant YAML location. Cross-file findings have a longer trace because they span multiple files, but are otherwise identical to direct findings.
+
+## Depth Limit and Unresolved References
+
+**Depth limit:** Fixed at 1 level. The top-level workflow is depth 0. Resolved files (composite actions and reusable workflows) are depth 1. Any cross-file references found at depth 1 are logged as unresolved with reason "Depth limit exceeded (max 1 level)" -- do NOT follow them.
+
+This covers the overwhelming majority of real-world patterns. Deeper nesting is rare and may indicate intentional obfuscation, which is worth noting in findings.
+
+**Unresolved reference reporting:**
+
+When any references could not be resolved, add an "Unresolved References" section at the end of the report:
+
+```markdown
+## Unresolved References
+
+| Reference | Source | Reason |
+|-----------|--------|--------|
+| `org/private/.github/workflows/scan.yml@v2` | `.github/workflows/ci.yml` jobs.scan | 404 Not Found (repository may be private) |
+| `./actions/deep-nested` | `actions/wrapper/action.yml` runs.steps[2] | Depth limit exceeded (max 1 level) |
+```
+
+- Omit this section entirely when all references resolve successfully
+- The summary counts total findings only -- it does not count resolved or unresolved references
+
+## Edge Cases
+
+**action.yml vs action.yaml:** Try `.yml` first, fall back to `.yaml`. GitHub supports both filenames and prefers `.yml`. This applies to both filesystem reads and API fetches.
+
+**Non-composite actions at local paths:** When `./path/to/action` resolves to a JavaScript or Docker action (`runs.using` is `node*` or `docker`), skip silently. Do NOT log as unresolved -- these are valid actions that simply have no analyzable workflow-style steps.
+
+**Local paths in remote analysis mode:** Fetch via Contents API using the same repo context. The `./` prefix is relative to the repository root, and the Contents API can retrieve any path: `gh api repos/{owner}/{repo}/contents/{path}/action.yml?ref={ref}`.
+
+**Missing files:** Log as unresolved with the specific reason (404, file not found, etc.). Do not treat missing files as errors that halt analysis -- continue with remaining references.
+
+**Circular references:** The depth-1 limit prevents infinite resolution. Even if Action A references Action B and Action B references Action A, the skill only follows one level. References found at depth 1 are logged as unresolved, not followed.
+
+**Job-level vs step-level `uses:`:** Job-level `uses:` (same indent level as `runs-on:`) indicates a reusable workflow call. Step-level `uses:` (inside a `steps:` array) indicates an action reference. The classification algorithm handles this distinction: reusable workflows are resolved as complete workflow files; composite actions are resolved via `action.yml`.

package/skills/agentic-actions-auditor/references/foundations.md

@@ -0,0 +1,94 @@
+# Shared Foundations: Attacker-Controlled Input Model
+
+This reference documents cross-cutting concepts that all 9 attack vector detection heuristics depend on. Read this before analyzing individual vectors.
+
+## Attacker-Controlled GitHub Context Expressions
+
+These `github.event.*` expressions resolve to content an external attacker can influence. Dangerous contexts typically end with: `body`, `default_branch`, `email`, `head_ref`, `label`, `message`, `name`, `page_name`, `ref`, `title`.
+
+**High-frequency (seen across PoC workflows):**
+
+- `github.event.issue.body` -- issue body text
+- `github.event.issue.title` -- issue title
+- `github.event.comment.body` -- comment text on issues or PRs
+- `github.event.pull_request.body` -- PR description
+- `github.event.pull_request.title` -- PR title
+- `github.event.pull_request.head.ref` -- PR source branch name
+- `github.event.pull_request.head.sha` -- PR commit SHA (used in checkout)
+
+**Lower-frequency but still dangerous:**
+
+- `github.event.review.body` -- review comment text
+- `github.event.discussion.body`, `github.event.discussion.title`
+- `github.event.pages.*.page_name` -- wiki page name
+- `github.event.commits.*.message`, `github.event.commits.*.author.email`, `github.event.commits.*.author.name`
+- `github.event.head_commit.message`, `github.event.head_commit.author.email`, `github.event.head_commit.author.name`
+- `github.head_ref` -- branch name (attacker-controlled in fork PRs)
+
+Any `${{ }}` expression referencing these contexts carries attacker-controlled content into whatever consumes the resolved value.
+
+## How env: Blocks Work in GitHub Actions
+
+Environment variables can be set at three scopes:
+
+1. **Workflow-level** `env:` (top of file) -- inherited by all jobs and steps
+2. **Job-level** `env:` (under `jobs.<id>:`) -- inherited by all steps in that job
+3. **Step-level** `env:` (under a step) -- available only to that step
+
+Narrower scopes override broader ones. Critically, `${{ }}` expressions in `env:` values are evaluated BEFORE the step runs. The step only sees the resolved string value, never the expression. This is the mechanism behind Vector A: the AI agent receives attacker content through an env var without any `${{ }}` expression appearing in the prompt field itself.
+
+```
+env:
+  ISSUE_BODY: ${{ github.event.issue.body }}   # evaluated at workflow parse time
+# By the time the step runs, ISSUE_BODY contains the raw attacker text
+```
+
+## Security-Relevant Trigger Events
+
+These `on:` events expose workflows to external attacker-controlled input:
+
+| Trigger | Attacker-Controlled Data | Risk Level |
+|---------|-------------------------|------------|
+| `issues` (opened, edited) | Issue title, body | External users can create issues |
+| `issue_comment` (created) | Comment body | External users can comment |
+| `pull_request_target` | PR title, body, head ref, head SHA | Runs in base branch context WITH secrets |
+| `pull_request` | Head ref, head SHA | Typically no secrets from forks, but ref is controlled |
+| `discussion` / `discussion_comment` | Discussion title, body, comment body | External users can create discussions |
+| `workflow_dispatch` | Input values | Triggering user controls all inputs |
+
+Note: `push` events from the default branch and `pull_request` events that do not grant secrets to forks are generally lower risk for prompt injection because the attacker cannot influence the content that reaches the AI agent without already having write access.
+
+## Data Flow Model
+
+Attacker input reaches AI agents through three distinct paths:
+
+**Path 1 -- Direct expression interpolation:**
+```
+github.event.*.body  ->  ${{ }} in prompt field  ->  AI processes attacker text
+```
+
+**Path 2 -- Env var intermediary:**
+```
+github.event.*.body  ->  env: VAR: ${{ }}  ->  prompt reads $VAR  ->  AI processes attacker text
+```
+
+**Path 3 -- Runtime fetch:**
+```
+github.event.*.number  ->  gh issue view N  ->  API returns attacker body  ->  AI processes attacker text
+```
+
+Path 2 requires extra attention because the prompt field contains zero `${{ }}` expressions, making the injection invisible in the prompt itself. Path 3 is missed because the attacker content is not present in the workflow YAML at all -- it is fetched at runtime.
+
+## AI Action Prompt Field Names
+
+Where each supported action receives prompt content that could carry attacker input:
+
+| Action | Prompt Fields | Notes |
+|--------|--------------|-------|
+| `anthropics/claude-code-action` | `with.prompt` | Also check `with.claude_args` for embedded instructions |
+| `google-github-actions/run-gemini-cli` | `with.prompt` | Shell-style env var interpolation in prompt text |
+| `google-gemini/gemini-cli-action` | `with.prompt` | Legacy/archived Gemini action reference |
+| `openai/codex-action` | `with.prompt`, `with.prompt-file` | `prompt-file` may point to attacker-controlled file |
+| `actions/ai-inference` | `with.prompt`, `with.system-prompt`, `with.system-prompt-file` | System prompt is also an injection surface |
+
+When checking for attacker-controlled content in prompts, examine ALL fields listed for the relevant action, not just the primary `prompt` field.

package/skills/agentic-actions-auditor/references/vector-a-env-var-intermediary.md

@@ -0,0 +1,77 @@
+# Vector A: Env Var Intermediary
+
+Attacker data flows from GitHub event context into `env:` blocks, and the AI prompt references those env var names -- the AI agent reads the attacker content from environment variables at runtime. The prompt field contains zero `${{ }}` expressions, making this pattern invisible to tools that only scan for direct expression injection.
+
+## Applicable Actions
+
+| Action | Applicable | Notes |
+|--------|-----------|-------|
+| Claude Code Action | Yes | Prompt instructs AI to read env vars via `echo "$VAR"` |
+| Gemini CLI | Yes | Shell-style `"${VAR}"` interpolation in prompt text |
+| OpenAI Codex | Yes | Similar env var reference pattern in prompt instructions |
+| GitHub AI Inference | Yes | Prompt text can reference env var names for the runner to resolve |
+
+## Trigger Events
+
+Any event where attacker-controlled body, title, or comment fields are exposed: `issues` (opened, edited), `issue_comment` (created), `pull_request_target`, `discussion`, `discussion_comment`. See [foundations.md](foundations.md) for the complete list of attacker-controlled contexts.
+
+## Data Flow
+
+```
+github.event.issue.body
+  -> env: ISSUE_BODY: ${{ github.event.issue.body }}   (evaluated BEFORE step runs)
+  -> prompt instruction references "ISSUE_BODY"
+  -> AI agent reads env var at runtime
+  -> attacker content in AI context
+```
+
+The `${{ }}` expression is in the `env:` block, not the prompt. By the time the step executes, the env var contains the raw attacker text. The AI agent reads it as a normal environment variable.
+
+## What to Look For
+
+This is a TWO-PART match. Both conditions must be true:
+
+1. **Part A -- Env var with attacker-controlled value:** Find `env:` keys (at workflow, job, or step scope) whose values contain `${{ github.event.* }}` expressions referencing attacker-controlled contexts (see [foundations.md](foundations.md) for the complete list)
+2. **Part B -- Prompt references that env var name:** Check if the AI action step's `with.prompt` (or `with.prompt-file`) references those env var names -- by exact name string, `"${VAR}"` shell expansion, `echo "$VAR"` instruction, or text mentioning the variable name
+
+Both parts must be present. An env var with attacker content that is never referenced in the prompt is not this vector. A prompt referencing env vars that contain only safe values is not this vector.
+
+## Where to Look
+
+- `env:` blocks at all three scopes: workflow-level (top of file), job-level (under `jobs.<id>:`), and step-level (on the AI action step itself)
+- The `with.prompt` field of the AI action step
+- Prior steps in the same job that set env vars via `echo "NAME=value" >> $GITHUB_ENV`
+
+## Why It Matters
+
+This pattern is invisible to naive grep-based tools that only scan for `${{ }}` in prompt fields. GitHub's own security documentation recommends using env vars as an intermediary to prevent script injection in `run:` blocks -- but this recommendation does not account for AI agents that read env vars by name. An attacker's issue body, PR description, or comment text flows into the AI prompt without any visible expression injection.
+
+## Example: Vulnerable Pattern
+
+```yaml
+on:
+  issues:
+    types: [opened]
+
+jobs:
+  triage:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: google-github-actions/run-gemini-cli@v0
+        env:
+          ISSUE_TITLE: '${{ github.event.issue.title }}'   # attacker-controlled
+          ISSUE_BODY: '${{ github.event.issue.body }}'      # attacker-controlled
+        with:
+          prompt: |
+            Review the issue title and body provided in the environment
+            variables: "${ISSUE_TITLE}" and "${ISSUE_BODY}".
+            # No ${{ }} here -- but attacker data still reaches the AI
+```
+
+**Data flow:** `github.event.issue.body` -> `env: ISSUE_BODY` -> prompt instruction `"${ISSUE_BODY}"` -> Gemini reads env var -> attacker content in AI context.
+
+## False Positives
+
+- **Safe context values:** Env vars containing non-attacker-controlled values like `${{ github.repository }}`, `${{ github.run_id }}`, or `${{ secrets.* }}` -- these are NOT attacker-controlled
+- **Unreferenced env vars:** Env vars with attacker-controlled values that are NOT referenced in any AI prompt (e.g., used only in non-AI steps like shell scripts or build tools)
+- **Explicit untrusted handling:** Env vars where the prompt explicitly treats the content as untrusted with effective input validation (rare in practice -- most workflows pass the content directly)

package/skills/agentic-actions-auditor/references/vector-b-direct-expression-injection.md

@@ -0,0 +1,83 @@
+# Vector B: Direct Expression Injection
+
+Direct `${{ github.event.* }}` expressions embedded in AI prompt fields. The YAML engine evaluates the expression at workflow runtime, embedding the attacker's raw text directly into the prompt string before the AI processes it. This pattern is visually obvious in the YAML -- the `${{ }}` expressions are right there in the prompt field -- but still commonly deployed because workflow authors assume the AI will handle untrusted input responsibly.
+
+## Applicable Actions
+
+| Action | Applicable | Notes |
+|--------|-----------|-------|
+| Claude Code Action | Yes | Check `with.prompt` and `with.claude_args` for embedded expressions |
+| Gemini CLI | Yes | Check `with.prompt` for direct expressions |
+| OpenAI Codex | Yes | Check `with.prompt`, `with.prompt-file` (if resolving to attacker-controlled path), `with.codex-args` |
+| GitHub AI Inference | Yes | Check `with.prompt`, `with.system-prompt`, `with.system-prompt-file` |
+
+Check ALL `with:` fields that accept text content, not just `prompt:`. Each action has multiple fields that are injection surfaces.
+
+## Trigger Events
+
+Any event exposing attacker-controlled contexts: `issues` (opened, edited), `issue_comment` (created), `pull_request_target`, `discussion`, `discussion_comment`. See [foundations.md](foundations.md) for the complete list of attacker-controlled contexts.
+
+## Data Flow
+
+```
+github.event.issue.body
+  -> ${{ github.event.issue.body }} evaluated at YAML parse time
+  -> raw attacker text becomes part of the prompt string literal
+  -> AI processes the prompt containing attacker content
+```
+
+The expression is resolved before any step code executes. The AI action receives a prompt string that already contains the attacker's text as if the workflow author had typed it.
+
+## What to Look For
+
+`${{ github.event.* }}` expressions inside any text-accepting field of an AI action step:
+
+- `with.prompt` -- the primary prompt field (all actions)
+- `with.system-prompt` -- system prompt (GitHub AI Inference)
+- `with.prompt-file` -- if it resolves to an attacker-controlled path (Codex, AI Inference)
+- `with.claude_args` -- may embed expressions as inline instructions (Claude Code Action)
+- `with.codex-args` -- may embed expressions (OpenAI Codex)
+
+The expression must reference an attacker-controlled context. See [foundations.md](foundations.md) for the complete list.
+
+Also check multiline `prompt: |` blocks -- expressions can appear on any line within the block scalar.
+
+## Where to Look
+
+The `with:` block of AI action steps. Focus on all fields listed above, not just `prompt:`. Expressions in `env:` blocks are Vector A, not Vector B.
+
+## Why It Matters
+
+While visually obvious, this vector remains common because developers treat AI prompts like natural language rather than code. The `${{ }}` evaluation happens at the YAML level before the AI agent runs, so the attacker's content is indistinguishable from the workflow author's intended prompt text. The AI has no way to tell which parts of its prompt are trusted instructions and which are attacker-injected content.
+
+## Example: Vulnerable Pattern
+
+```yaml
+on:
+  issues:
+    types: [opened]
+
+jobs:
+  gather-labels:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: openai/codex-action@main
+        with:
+          allow-users: "*"
+          prompt: |
+            Issue title:
+            ${{ github.event.issue.title }}
+            Issue body:
+            ${{ github.event.issue.body }}
+            Analyze this issue and suggest appropriate labels.
+            # Attacker content is embedded directly in the prompt at YAML eval time
+```
+
+**Data flow:** `github.event.issue.body` -> `${{ }}` evaluation -> prompt string literal -> Codex processes attacker-controlled prompt content.
+
+## False Positives
+
+- **Integer/enum contexts:** `${{ github.event.issue.number }}` -- integers, not attacker-controlled text. `${{ github.event.action }}` -- limited set of values (opened, edited, etc.), not free text
+- **Safe contexts:** `${{ github.repository }}`, `${{ github.run_id }}`, `${{ github.actor }}` -- not attacker-controlled free text (though `github.actor` is the username, which has limited character set)
+- **Expressions in env: blocks:** Those are Vector A, not Vector B. Vector B is specifically about expressions directly in prompt or other `with:` fields
+- **Expressions in non-AI steps:** `${{ }}` expressions in `run:` blocks or non-AI action `with:` blocks are standard GitHub Actions script injection concerns, not specific to this skill's scope