Back to Intelligence

GitHub Agentic Workflows Data Leak: Hardening and Detection Guide

SA
Security Arsenal Team
July 7, 2026
7 min read

As we progress through 2026, the integration of Generative AI and Agentic Workflows into the SDLC has shifted from a competitive advantage to an operational standard. However, this automation introduces a novel attack surface: the trust boundary between the AI agent and the organization's private data.

Recent research from Noma Security has unveiled a critical vector where public GitHub issues can be weaponized to trick Agentic Workflows into leaking proprietary code and secrets. Unlike traditional supply-chain attacks requiring compromised credentials or malicious pull requests, this attack leverages the agent's own functionality—specifically its ability to read and synthesize context across repositories—against the organization.

For SOC analysts and DevSecOps engineers, this is not a theoretical risk. If your organization utilizes GitHub Copilot Workspace or custom Actions integrated with LLMs, and those agents possess read permissions across private repositories, you are currently exposed to data exfiltration via a simple support request filed on a public repo.

Technical Analysis

Affected Platforms & Products

  • GitHub Actions & Agentic Workflows: Specifically workflows utilizing github-script or LLM-integrated actions (e.g., custom agents interacting with the GitHub API).
  • GitHub Copilot Workspace: Instances where the agent is auto-triggered on issue events.

The Vulnerability: Indirect Prompt Injection via Context Retrieval

  • Mechanism: The attacker creates a standard issue on a public repository. The issue contains a crafted prompt designed to manipulate the Agentic Workflow. When the agent analyzes the issue to generate a response or code suggestion, it performs a "context retrieval" operation.
  • The Failure Mode: If the workflow's token (GITHUB_TOKEN) is scoped with broad read access (e.g., default contents: read at the org level or read:org), the agent may pull sensitive files from private repositories within the same organization to inform its answer.
  • Exfiltration: The agent then incorporates this private data into its comment or response on the public issue, effectively leaking secrets, proprietary logic, or internal configuration details to the attacker.

Exploitation Requirements

  1. Public Exposure: The organization must have at least one public repository.
  2. Agent Integration: A workflow or agent must be configured to act on issues: [opened, edited] events.
  3. Over-Privileged Token: The GITHUB_TOKEN or the OIDC token used by the agent must have read access to private repositories.

Exploitation Status Currently identified as a proof-of-concept by Noma Security. While no specific CVE (2025/2026) has been assigned to this logic flaw, the technique is actively exploitable in environments where least privilege has not been applied to workflow tokens.

Detection & Response

Detecting this requires monitoring GitHub Audit Logs for anomalous agent behavior. Since the attacker uses legitimate features (issues) and the agent uses legitimate permissions (read access), we must hunt for the outcome: private data appearing in public contexts, or agents accessing private repos immediately following public triggers.

SIGMA Rules

YAML
---
title: Potential Data Leak via Agentic Workflow on Public Issue
id: 8a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects when a known Agentic Workflow (e.g., Copilot) comments on a public issue. The comment body should be inspected for potential leakage of private internal paths or secrets.
references:
  - https://thehackernews.com/2026/07/public-github-issue-could-trick-github.html
author: Security Arsenal
date: 2026/07/10
tags:
  - attack.exfiltration
  - attack.t1567.001
logsource:
  product: github
  service: audit
detection:
  selection_event:
    action:
      - issue_comment.created
      - issue_comment.edited
  selection_public:
    repository_public: true
  selection_actor:
    actor|contains:
      - 'github-actions[bot]'
      - 'copilot'
      - 'agent'
  # Keyword heuristics to identify potential private data in the output
  selection_keywords:
    comment_body|contains:
      - 'API_KEY'
      - 'PRIVATE_KEY'
      - 'internal'
      - '.env'
      - 'config/production'
condition: selection_event and selection_public and selection_actor and selection_keywords
falsepositives:
  - Legitimate support bot addressing a public bug report referencing internal docs.
level: high
---
title: Agentic Workflow Read Access to Private Repo Post Public Trigger
did: 9d3c4e5f-6a7b-8b9c-0d1e-2f3a4b5c6d7e
status: experimental
description: Detects a workflow run or heavy read access on a private repository immediately following an issue creation on a public repository by a low-reputation user.
references:
  - https://thehackernews.com/2026/07/public-github-issue-could-trick-github.html
author: Security Arsenal
date: 2026/07/10
tags:
  - attack.collection
  - attack.t1005
logsource:
  product: github
  service: audit
detection:
  selection_issue:
    action: issue.created
    repository_public: true
  selection_read:
    action|contains:
      - 'git.clone'
      - 'repository.read'
    repository_public: false
  filter_benign:
    actor_login|endswith: '[bot]' # We focus on bot accounts doing the reading
  timeframe: 5m
condition: selection_issue and selection_read and filter_benign | timeframe()
falsepositives:
  - Automation updating documentation across public/private repos.
level: medium

KQL (Microsoft Sentinel / Defender)

KQL — Microsoft Sentinel / Defender
// Hunt for Agentic Workflows commenting on public issues with indicators of private data
GitHubAuditLog
| where Action == "issue_comment.created"
| extend IsPublic = todynamic(Repository)["public"]
| where IsPublic == true
| extend Actor = ActorLogin
| where Actor contains "bot" or Actor contains "agent" or Actor contains "copilot"
| extend CommentBody = coalesce(todynamic(tostring(Comment))["body"], tostring(CommentBody))
| where CommentBody matches regex @"(private|secret|password|token|api_key|internal_config)"
| project TimeGenerated, Actor, RepositoryName, IssueNumber, CommentBody
| order by TimeGenerated desc

Velociraptor VQL

VQL — Velociraptor
-- Hunt for GitHub CLI or Agent configurations on endpoints that might have over-privileged scopes
SELECT FullPath, Size, Mtime, Data
FROM glob(globs='/Users/*/.config/gh/**', '/root/.config/gh/**', '/home/*/.config/gh/**')
WHERE Data =~ 'oauth_token' 
   OR Data =~ 'workflow_scope'
   OR Data =~ 'read:org'
-- Check for local agent cache that might contain leaked context

Remediation Script (Bash)

Bash / Shell
#!/bin/bash
# Remediation: Audit and Report GitHub Workflow Permissions
# Usage: ./audit_workflow_perms.sh ORG_NAME

ORG_NAME=$1

if [ -z "$ORG_NAME" ]; then
  echo "Usage: $0 ORG_NAME"
  exit 1
fi

echo "[+] Auditing repositories in $ORG_NAME for default workflow permissions..."

# Get list of repos
REPOS=$(gh repo list "$ORG_NAME" --limit 400 -- name --jq '.[].name')

for repo in $REPOS; do
  echo "[+] Checking: $repo"
  
  # Check default workflow permissions at the org level is harder via CLI, 
  # so we inspect specific workflow files for 'permissions' block.
  
  # List workflows
  WORKFLOWS=$(gh api repos/$ORG_NAME/$repo/actions/workflows --jq '.workflows[].path' 2>/dev/null)
  
  if [ -z "$WORKFLOWS" ]; then
    continue
  fi

  for wf in $WORKFLOWS; do
    # Download workflow content
    CONTENT=$(gh api repos/$ORG_NAME/$repo/contents/$wf --jq '.content' 2>/dev/null)
    
    if [ ! -z "$CONTENT" ]; then
      DECODED=$(echo "$CONTENT" | base64 -d)
      
      # Check for 'contents: write' or missing permissions (implies default write)
      if echo "$DECODED" | grep -q "contents: write"; then
         echo "  [!] RISK: $wf has 'contents: write' permission"
      elif echo "$DECODED" | grep -q "permissions:"; then
         echo "  [OK] $wf has scoped permissions."
      else
         echo "  [!] WARNING: $wf has NO permissions block (defaults to write token)."
      fi
    fi
  done
done

echo "[!] Action Required: Explicitly set 'permissions: contents: read' in all workflow YAML files."
echo "[!] Action Required: Disable 'Read and write permissions' in Organization Settings -> Actions -> General."

Remediation

Immediate action is required to secure the CI/CD pipeline against this logical injection.

  1. Principle of Least Privilege (The Silver Bullet):

    • Org-Level Settings: Navigate to Settings > Actions > General. Under "Workflow permissions", select "Read repository contents and pull requests" (and uncheck "Allow GitHub Actions to create and approve pull requests"). This prevents workflows from having write access unless explicitly granted.
    • Workflow-Level Hardening: Edit every workflow YAML file. Add an explicit permissions block at the top level: yaml permissions: contents: read # Restrict to read-only issues: write # Only grant write if the bot must comment
  2. Scope Access granularly:

    • Ensure Agentic Workflows (like Copilot) are restricted to specific repositories. Do not grant the read:org scope to automation tokens unless absolutely necessary.
  3. Human-in-the-Loop for Public Triggers:

    • Configure workflows triggered by issue_comment or issues events on public repositories to require manual approval before posting comments or accessing internal data context.
  4. Output Filtering (Data Loss Prevention):

    • Implement a pre-publish validation step in your agent scripts that scans the generated text for regex patterns matching keys, internal IP addresses, or specific internal paths before allowing the comment to be posted.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

sigma-rulekql-detectionthreat-huntingdetection-engineeringsiem-detectiongithubagentic-aidata-leakprompt-injectiondevsecops

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.