Treat GitHub Issues as Agent Input

A GitHub issue is not just a ticket once an AI coding agent reads it.

It is input to a tool-bearing system.

Short answer

Treat every GitHub issue body, pull request description, review comment, repository file, agent rule, editor task, and hidden markdown comment as untrusted input before an AI coding agent sees it. If the agent can read secrets, edit files, create pull requests, run commands, call MCP tools, or communicate externally, those abilities need a separate approval gate. The safe pattern is input quarantine, secret isolation, tool allowlists, repo-config review, high-risk action approval, and audit logs.

Why GitHub became an agent boundary

The old model was simple enough.

GitHub issues were tickets. Pull requests were code review. Repository files were project context. CI jobs were deterministic automation.

AI coding agents blur those lines.

When an agent reads a GitHub issue, that issue may influence what the agent searches, what file it reads, what patch it writes, what pull request it opens, and what comment it posts back to the world.

That means the issue is no longer passive project context. It is input to a system with tools.

Microsoft's June 2026 writeup on securing CI/CD in an agentic world makes the boundary concrete. Microsoft Threat Intelligence reported that an AI workflow could expose CI/CD workflow secrets when it processed untrusted GitHub content, including issue bodies, pull request descriptions, and comments. The key detail was not only that untrusted content reached the model. It was that the agent also had access to tools and runner context.

Microsoft also reported a boundary mismatch. The workflow had environment scrubbing for subprocess execution paths such as Bash, but the Read tool was not subject to the same sandboxing model. Before mitigation, that path could reach sensitive /proc files in the runner environment.

The lesson is plain: do not secure only the shell path. Secure every path the agent can use after untrusted input reaches it.

Repository files can be instructions too

This is not only about issue text.

A repository can carry files that change how an AI coding tool behaves. StepSecurity's June 2026 Miasma incident report described a supply-chain pattern where tool configuration files and editor startup behavior became part of the attack path.

The specific report should be treated as StepSecurity's claim set, not as something VibeSec Advisory independently verified. Still, the control lesson is useful.

Review these paths before starting an agent in a new or changed repo:

.claude/
.gemini/
.cursor/
.vscode/
.github/workflows/
.github/actions/
setup scripts
postinstall hooks
agent rules
editor tasks

A repo-level agent rule can look like documentation. An editor task can look like local convenience. A workflow change can look like maintenance. To an agent or an IDE, those files may shape behavior.

That makes them part of the input boundary.

The failure pattern

The risk pattern has four parts:

1. Untrusted GitHub content reaches the agent.
2. The agent treats that content as relevant context.
3. The agent has tools that can read, write, run, send, deploy, or call another system.
4. The workflow does not require a separate approval step before high-risk actions.

That is enough to turn a comment, issue, markdown file, or repo config file into a security problem.

This fits the broader agentic AI risk model. Microsoft's updated taxonomy of failure modes in agentic AI systems includes agentic supply chain compromise across plugin registries, MCP servers, prompt templates, and third-party tool integrations. The important shift is that a supply-chain payload does not have to be a binary. It can be natural-language instructions that change agent behavior.

That is why repository text deserves dependency-style review when an agent will act on it.

Rule scans help, but they are not the boundary

Detection still matters.

Agent Threat Rules is one attempt to create a rule format for AI agent threats. Help Net Security's coverage of ATR says rules can inspect fields such as LLM input, tool-call arguments, and SKILL.md content.

That is useful. It gives teams a way to triage known patterns in prompts, tool calls, and agent instructions.

But the same report also describes recall gaps. Pattern systems are weaker against paraphrased and semantic attacks. A scanner may catch a known phrase and miss the same intent written another way.

So do not make detection carry the whole control.

The boundary is not, "Did a scanner flag this issue?"

The boundary is, "What can the agent touch after it reads this issue?"

The GitHub agent input boundary record

Before you let an AI coding agent process GitHub content with tool access, write down the boundary.

Agent or workflow:
Repository:
Input sources:
  - issues
  - pull request descriptions
  - review comments
  - repo files
  - agent rules
  - workflow files
  - editor tasks
Who can create each input:
Can public users influence the input:
Can forks influence the input:
Can hidden markdown or generated files reach the agent:
Secrets available to the runtime:
File-read tools available:
Write tools available:
Command tools available:
MCP tools available:
External communication tools available:
Actions that require approval:
Blocked paths and file classes:
Log location:
Reviewer:
Review date:
Default decision if unclear:

If you cannot fill this out, the workflow is not ready for broad tool access.

Safer workflow pattern

Start with a narrow workflow.

1. Quarantine untrusted GitHub text before the agent sees it.
2. Run first-pass triage without secrets.
3. Give read access before write access.
4. Keep repository config changes visible to a human reviewer.
5. Require approval before the agent creates a pull request, changes a workflow, edits dependencies, calls an MCP tool, or posts externally.
6. Log tool calls with the input source that influenced them.
7. Test the workflow with a safe hostile-input canary that asks for a forbidden action.

The test does not need to be dramatic. Use a harmless canary that asks the agent to do something it should never do, such as bypass review, read blocked files, or post outside the approved channel. The expected result is refusal, escalation, or no tool call.

If the agent follows the canary, the boundary failed.

Red flags to review before agent execution

Pause before running the agent when you see:

• Hidden markdown comments in issues or pull requests
• Agent rule changes in .claude/, .gemini/, or .cursor/
• Editor task changes in .vscode/
• Workflow changes under .github/
• Configuration-only commits that claim to be source changes
• [skip ci] on commits that touch automation or agent configuration
• Large generated setup scripts
• New dependencies added by an agent
• PRs that combine documentation changes with automation changes
• Tool calls that read environment, credential, SSH, cloud, package-manager, or CI files
• Any path where the agent can both read untrusted input and communicate externally

The last one is the real problem.

A read-only summarizer is one risk. An agent that reads public input, sees CI context, edits files, opens PRs, and comments externally is a different system.

Where MCP fits

MCP makes this review more important, not less.

If GitHub content can steer an agent that has MCP tools, the tool boundary needs the same review as the GitHub input boundary. A hostile issue should not be able to make the agent call a file tool, browser tool, database tool, email tool, or deployment tool without a separate approval gate.

This is the same shape as the lethal trifecta agent permission review: access to private data, exposure to untrusted content, and a way to communicate out. GitHub issues can supply the untrusted content. Coding-agent tools can supply the action path. External comments, pull requests, webhooks, or MCP tools can supply the exit path.

That combination needs more than a prompt that says "be careful."

Evidence versus opinion

Evidence from the sources:

• Microsoft reported a real CI/CD agent workflow risk involving untrusted GitHub content, file-read tooling, and secrets in the runner environment.
• Microsoft reported that Anthropic mitigated the specific issue by blocking access to sensitive /proc files in Claude Code version 2.1.128.
• StepSecurity reported a repository-level supply-chain pattern involving AI coding tool configuration and editor startup behavior.
• Microsoft's agentic AI taxonomy update frames prompt templates, MCP servers, plugin registries, and third-party tools as supply-chain ingestion points.
• Help Net Security's ATR report supports rule-based detection as useful but incomplete.

VibeSec Advisory's opinion:

Every AI coding agent workflow that reads GitHub content should have an input boundary record before it gets secrets, write tools, MCP tools, or external communication. Treat the GitHub surface as untrusted until the workflow proves otherwise.

Free next step

Pick one AI coding agent workflow and fill out the GitHub agent input boundary record above. If the workflow cannot show input sources, tool permissions, approval gates, blocked paths, and logs, keep it read-only until it can.

Then browse the VibeSec Advisory Skill Library for more practical agent security checks.