Review what a CI agent will read before its job gets secrets. A pull request can contain instructions that ask the agent to reveal the credentials it needs to work.
OpenCode received two such pull requests on 2026-10-20. Both authors tried to start its agent with an /oc comment. Both requests were refused because the authors lacked write access. The public record shows two blocked attempts. (First request, second request.)
The OpenCode example, step by step
- A comment could start an agent. OpenCode's repository had a GitHub Actions workflow that responded to
/ocor/opencode. The agent could read issue and pull request text, including contributions from outside the team. Workflow source. - The job had credentials.
OPENCODE_API_KEYgave it model access. It could also exchange its GitHub job identity for anopencode-agentinstallation token. That token had broader repository permissions than the job's normalGITHUB_TOKEN. OpenCode's explanation. - The pull requests carried instructions for the agent. One asked it to include Git credentials and environment values in its review. The other told it to read /proc/self/environ. That Linux file contains environment variables from when a process starts. It then asked for credential values in a public comment. The instructions were in Markdown files, presented as security and environment checks. (First diff, second diff.)
- The authors tried to trigger the workflow themselves. Each posted an
/occomment asking for a review of the documentation. That request was meant to make the agent read the instructions they had just added. (First comment, second request.) - The permission check stopped both requests. Each author received a reply saying they lacked write access. The action checks that permission before creating the requested agent session. (Action source, replies.)
- A maintainer could still have started the risky review. OpenCode's maintainers described this remaining path: an authorized user could run
/ocon a malicious pull request. The agent would then read that input with credentials available. If it followed the planted instructions, it could disclose them. On 2026-10-21, the team removed its own /oc workflow and /review workflow.
The attack tried to turn repository text into instructions for the agent. That's prompt injection. The permission check controlled who could start the job. A maintainer could still ask that job to read an attacker's text.
What this means when you run Shannon
Shannon, Keygraph's open-source AI pentester, reads source code and runs tools against a test deployment. When configured with an API key, its worker receives that key, and the agent's shell inherits the worker environment. (Credential handling, shell environment.)
A Pi subscription login also makes credentials available inside the scan container. Shannon mounts the Pi authentication file, ~/.pi/agent/auth.json, read-write into the container. A malicious repository could try to prompt the agent into reading and disclosing either the API key or the login credentials. This is an observed credential-access path, not a reported Shannon incident.
So check the commit and the text the agent will read before making model credentials available to a scan. Include source comments, documentation, test fixtures, scan configuration, and workflow changes.
Keep repository permissions narrow. Give the scan a dedicated model key. And check any separate GitHub App token: the job's GITHUB_TOKEN settings don't describe every credential it can obtain.
Approval reduces which inputs reach the credentials. It doesn't make those credentials unreadable once the worker has them.