Google Gemini in GitHub Actions needs runtime monitoring

At a glance

What this is: StepSecurity argues that Gemini in GitHub Actions has application-level observability, but not enough runtime visibility to explain or constrain what the agent does once execution starts.

Why it matters: IAM and CI/CD teams need to treat agent authentication and runtime containment as separate controls, because telemetry alone does not stop risky process, network, or file activity.

By the numbers:

• Google's run-gemini-cli review job generated 51 HTTPS events across 9 different destinations during a single review task.
• The workflow review job alone took 1 minute 18 seconds while Harden-Runner captured network, process and file activity.

Context

Google Gemini in GitHub Actions is a CI/CD security problem because the agent can be authenticated cleanly while still doing unpredictable work inside the runner. The core gap is not login, but runtime governance: once the workflow starts, application logs no longer show the full chain of network, process, and file activity.

StepSecurity's analysis places Gemini in the middle of a broader control question for AI coding agents. GitHub Actions teams already understand that identity and permission design matter, but this article shows that execution-time monitoring is a separate requirement when an agent can call external services, download tools, and modify repository state.

For practitioners, the lesson is that observability and containment are different layers. A workflow can look well-instrumented from a cloud telemetry perspective and still leave CI/CD security blind to the actions that matter most when code generation becomes code execution.

Key questions

Q: What breaks when AI coding agents in GitHub Actions are monitored only through cloud telemetry?

A: Teams lose visibility into the actions that matter most for containment: spawned processes, external endpoint calls, downloaded tools, and file changes. Cloud telemetry can confirm that a prompt was processed and a task finished, but it cannot prove that the workflow stayed within intended execution boundaries.

Q: Why does an authenticated AI agent still create runtime risk in CI/CD?

A: Authentication proves the workflow is allowed to talk to a service, not that the agent will behave safely once it is running. In a CI/CD runner, an agent can still fetch dependencies, invoke tools, and alter files, so the operational risk sits in behaviour after login, not in access alone.

Q: How do you know if AI agent monitoring is actually working?

A: It is working when you can explain why a sequence of actions was allowed, blocked, or escalated, using evidence from the full chain rather than a single request. If monitoring only shows isolated inputs, it is not capturing agent intent, which is where misuse usually appears.

Q: What is the difference between agent identity controls and runtime containment for AI security?

A: Agent identity controls establish who or what the agent is, while runtime containment limits what it can do when behavior becomes risky. Identity answers authentication and authorization questions. Containment handles drift, anomalous actions, and policy violations in motion. Mature programs need both, because identity alone does not stop a trusted agent from overreaching after access is granted.

Technical breakdown

Why application telemetry is not runtime security

Application telemetry records what an agent asked for, what model responded, and whether the workflow completed. Runtime security asks a different question: what the process tree, filesystem, and network stack actually did while that work was happening. In GitHub Actions, those are different control planes. A tool can emit traces to Google Cloud and still spawn child processes, fetch dependencies, and modify files without those events appearing in the application logs. The security blind spot is not the absence of data, but the wrong layer of data for the threat model.

Practical implication: Use runtime controls that observe execution, not just model or API telemetry.

Why AI coding agents expand the CI/CD trust boundary

An AI coding agent in a pipeline is not just another build step. It can consume prompts, call external endpoints, download packages, execute helper binaries, and write to the workspace, which makes it a dynamic participant in the runner's trust boundary. That turns the CI/CD environment into a live dependency graph rather than a fixed job graph. Authentication mechanisms such as API keys or Workload Identity Federation secure access to cloud services, but they do not constrain the agent's local behaviour once the workflow begins.

Practical implication: Treat the runner as an execution environment that needs policy enforcement, not only identity authentication.

What Harden-Runner is exposing that cloud logs miss

Harden-Runner captures the runtime chain that cloud logs omit: network calls to registries and model endpoints, process creation, and file-system activity. That matters because a single prompt can trigger multiple downstream actions, including tool downloads and container pulls, each of which creates a new risk surface. Security teams need that chain to understand whether an agent is behaving within intended bounds or simply producing a successful completion event while performing risky side effects underneath.

Practical implication: Instrument runners so investigators can reconstruct the full execution path after each agent action.

Threat narrative

Attacker objective: Exploit the visibility gap between AI application telemetry and CI/CD runtime behaviour to hide risky or malicious actions inside an otherwise legitimate workflow.

1. Entry occurs when Gemini is triggered inside GitHub Actions with valid authentication and begins executing a review task.
2. Credential and dependency use expands as the workflow reaches Google APIs, npm, GitHub releases, container registries, and other external services during execution.
3. Impact is the creation of an opaque runtime chain where model activity looks normal in application logs while the runner still performs network, process, and file operations that security teams cannot see from telemetry alone.

Breaches seen in the wild

• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime monitoring, not telemetry, is the governing control for AI coding agents in CI/CD. Application observability tells teams that an agent completed a task, but it does not show the external endpoints, spawned processes, or file writes that define the real risk. In GitHub Actions, that means the control boundary must move from model output to execution behaviour. Practitioners should judge agent safety by what happens on the runner, not by what appears in cloud logs.

AI coding agents create a new form of CI/CD control gap: authenticated execution without observable containment. The article shows that Gemini can be integrated cleanly into GitHub-native workflows while still reaching beyond the view of native telemetry. That is a governance problem, not a tooling convenience issue. Security teams need policies that define what an agent may execute, what it may download, and what it may modify during a workflow run.

Execution-time evidence is now part of CI/CD assurance. Traditional pipeline assurance often focuses on secrets, permissions, and build provenance, but AI-driven steps add behaviour that only runtime inspection can verify. The governance assumption that a successful job equals a safe job no longer holds when an agent can hide dependency resolution, process spawning, and filesystem changes inside the same run. Teams should treat runtime evidence as a first-class audit input.

AI coding agent governance will increasingly converge on identity plus runtime control. This article sits at the intersection of GitHub Actions, workload identity, and machine behaviour, which is exactly where NHI governance becomes operational rather than theoretical. The next control question is not whether an agent can authenticate, but whether the authenticated workload can be observed and constrained after issuance. Practitioners should align CI/CD identity controls with execution monitoring.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Runtime visibility is becoming the differentiator for AI-enabled CI/CD governance. A workflow that can authenticate cleanly but still contact multiple services, spawn child processes, and modify files is already beyond what most application telemetry can explain. Security teams should assume that agent execution will be more dynamic than traditional build steps and design controls around containment plus inspection, not logging alone.

Agent observability is only useful when it captures behaviour at the runner boundary. According to the State of Secrets Sprawl 2026, Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025. That kind of leakage pattern shows why AI-assisted work needs execution-time controls, not just model-level telemetry.

Execution evidence is now part of CI/CD assurance. Teams that cannot reconstruct the process tree, network destinations, and file changes from an AI agent run cannot prove that a successful workflow was also a safe one. The practical move is to make runtime monitoring a standard control in AI-enabled pipelines, especially where external dependency resolution is part of normal operation.

For practitioners

• Deploy runtime monitoring on AI-enabled runners Instrument GitHub Actions jobs with process, network, and file visibility so agent activity can be reconstructed after execution, not just after model calls.
• Separate authentication from behavioural control Treat API keys and Workload Identity Federation as access mechanisms, then add runner policy controls that limit outbound connections, child processes, and workspace writes.
• Review dependency-fetch behaviour in agent jobs Track package downloads, container pulls, and release-asset retrievals from AI coding workflows because those fetches often represent the least visible trust expansion.
• Define a minimum audit trail for agent runs Require logs that capture prompts, spawned processes, outbound endpoints, and modified files so investigations can distinguish normal completion from risky side effects.

Key takeaways

• AI coding agents in CI/CD create an observability gap when teams rely on cloud telemetry instead of execution-level monitoring.
• Gemini's authentication options reduce access friction, but they do not stop risky network, process, or file activity once a workflow starts.
• Runtime controls must become part of pipeline assurance whenever AI agents can download dependencies, spawn subprocesses, or alter repository state.

Key terms

• Runtime Monitoring: The practice of observing identity activity while it is happening, not after the fact. For agents and NHIs, it means tracking tool calls, credential use, and resource access in real time so deviations from approved scope can be detected before damage compounds.
• Application Observability: Application Observability is the ability to understand application health from emitted telemetry such as logs, metrics, traces, and experience signals. It goes beyond simple uptime checks by linking symptoms to dependencies and user impact. Strong observability lets teams investigate complex failures faster and validate whether fixes actually restore service quality.
• Execution boundary: The point at which an authorised task turns into a real system change, such as writing data, deleting records, spending money, or invoking a downstream tool. In AI governance, controlling the execution boundary matters more than simply approving access, because harm occurs when actions are allowed to complete unchecked.
• Runner Boundary: The runner boundary is the trust boundary around a CI/CD execution environment such as a GitHub Actions job runner. It is where orchestration ends and actual code behaviour begins, so it is the right place to enforce containment, inspection, and audit controls.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners align identity controls with the runtime realities of modern CI/CD and agentic workflows.