Google Gemini in GitHub Actions needs runtime monitoring

At a glance

What this is: This is StepSecurity’s analysis of securing Google Gemini in GitHub Actions, with the key finding that native observability does not expose the runtime behaviour security teams need to govern.

Why it matters: It matters because IAM, NHI, and CI/CD security teams must control both authenticated access and runtime action boundaries when AI coding agents can fetch dependencies, spawn processes, and modify files.

By the numbers:

• The workflow recorded 51 HTTPS events across 9 destinations during a single review task.
• The review job alone took 1 minute 18 seconds while Harden-Runner captured the full activity chain.

👉 Read StepSecurity's analysis of securing Google Gemini in GitHub Actions

Context

AI coding agents in CI/CD environments create a governance gap when authentication is strong but execution is not constrained. The primary issue is not whether the agent can reach the model, but whether teams can see and control what it does after it receives a task. That becomes a real identity and NHI problem when the agent relies on service credentials, external package fetches, and delegated workflow permissions.

In GitHub Actions, the runtime boundary matters as much as the prompt boundary. Gemini's hybrid model is useful for flexibility, but application telemetry alone does not show process spawns, file writes, or outbound connections from generated code. For IAM and PAM teams, this is a reminder that identity assurance for agents must extend into runtime monitoring and least-privilege execution, not stop at login or token issuance.

Key questions

Q: What breaks when observability is used instead of access control for AI agents?

A: What breaks is the security boundary itself. If teams rely on observability alone, they may see suspicious agent behaviour only after the agent has already accessed data or taken action. The control gap is not detection quality, but the absence of enforceable authorization before execution.

Q: Why do enterprise AI agents complicate NHI governance?

A: They complicate NHI governance because the security model was built around predictable non-human identities such as API keys and workload credentials. Agents reason over context, can chain actions, and may use multiple protocols in one workflow. That makes permission modelling necessary but insufficient, because the real control issue is whether the execution still reflects approved intent.

Q: What do security teams get wrong about Workload Identity Federation for agents?

A: They often assume cloud authentication is the main control when the larger risk sits inside the runner. Federation can confirm who the workload is to the cloud, but it does not restrict package downloads, child processes, or file writes once the job is executing. Identity proof is necessary, but not sufficient.

Q: How should organisations govern AI coding agents in GitHub Actions?

A: Give them the minimum repository and secret access needed, add runtime monitoring for network and process activity, and tightly control external dependencies they can fetch during execution. The right model is layered control: authentication, task scope, egress limits, and evidence of behaviour after the job begins.

Technical breakdown

Why application telemetry is not runtime security

Application telemetry tells you what an AI agent accomplished, but not how it achieved the result. In a CI/CD runner, that distinction matters because the same prompt can trigger dependency downloads, shell execution, file modification, and outbound calls to registries or cloud APIs. Runtime security needs process, network, and file visibility, while observability tools usually expose model usage and service logs. Those are different control layers. Without runtime monitoring, teams cannot reconstruct the true attack surface created by the agent's execution path.

Practical implication: pair model telemetry with runner-level monitoring so security teams can see execution behaviour, not just job success.

How flexible authentication creates an identity boundary problem

Gemini's support for API keys and Workload Identity Federation illustrates a common pattern in agentic systems: the authentication mechanism can be sound while the downstream privilege boundary remains too loose. The identity presented to Google services is not the same as the identity governing what the agent may do inside the workflow runner. That separation is where overreach occurs. If the agent can fetch packages, invoke tools, and modify files under inherited workflow permissions, the credential model is only solving one side of the trust problem.

Practical implication: bind agent credentials to task-scoped permissions and separate cloud authentication from execution privilege.

Supply chain exposure in agent-driven CI/CD workflows

Agentic workflows often expand the trusted computing base by pulling from package registries, container registries, and release assets at runtime. That makes dependency resolution part of the security boundary, not a background build detail. In the StepSecurity example, multiple external destinations were contacted during a single task, which means a compromised dependency, malicious tool, or poisoned artifact could influence execution path and output. For security architects, the concern is not only code generation but the live supply chain the agent assembles while working.

Practical implication: restrict outbound access and verify dependencies at runtime, not only during repository review.

Threat narrative

Attacker objective: The attacker objective is to exploit the agent's runtime trust boundary so approved automation can perform unintended actions inside the CI/CD pipeline.

1. Entry occurs when the agent is triggered inside GitHub Actions and begins executing with authenticated access to cloud and repository resources.
2. Credential access is not the sole issue here, because the risk comes from inherited permissions that allow the agent to fetch tools, packages, and container images during the run.
3. Impact occurs when unmanaged execution expands the attack surface through uncontrolled network calls, file changes, or malicious downstream dependencies.

NHI Mgmt Group analysis

Runtime observability is now a governance requirement for AI coding agents. The StepSecurity analysis shows that application-level logs are insufficient when a single workflow can touch registries, packages, containers, and file systems. Security teams need evidence of process execution and network behaviour, not just prompts and model responses. In identity terms, the agent behaves like a non-human identity with delegated authority that must be monitored at runtime, not only authenticated at startup.

Hybrid authentication does not solve privilege containment. API keys and Workload Identity Federation reduce some credential risks, but they do not define what the agent may do once it enters the runner. That is the control gap: identity proof at the cloud boundary without execution scoping inside the workload boundary. Practitioners should read this as a reminder that IAM and PAM controls must extend into GitHub Actions permissions, egress rules, and tool execution policy.

Supply chain risk grows when the agent composes its own dependency chain. The article's runtime trace shows the agent calling registries and downloading binaries during the task itself. That is a concrete example of supply chain expansion at execution time, where trust shifts from curated build inputs to live retrieval decisions. The named concept here is runtime dependency sprawl: the widening set of external artifacts an agent pulls while completing a task, which increases both exposure and blast radius.

Least privilege for agents has to include the runner, not just the account. Many teams focus on the credentials presented to the cloud provider and overlook the local execution context where commands, files, and child processes are created. This is where agentic AI security overlaps with NHI governance. A workflow can be fully authenticated and still behave like an uncontrolled workload if the runner is allowed to inherit broad access. Practitioners should treat the workflow environment as part of the identity perimeter.

Defence-in-depth for CI/CD now means pairing identity controls with runtime controls. The article reinforces a wider pattern across AI-assisted development: trust is distributed across model, prompt, package, container, and runner layers. No single control removes the risk of an AI coding agent acting outside intent. Teams should use this as a trigger to re-evaluate where they rely on telemetry, where they rely on permissions, and where they still have no visibility at all.

What this signals

Runtime dependency sprawl is the control problem that AI coding agents create in CI/CD. Once an agent can fetch packages, containers, and release assets during execution, identity governance has to expand beyond who authenticated the job and ask what external trust chain the job assembled. Teams should anchor that review to runtime evidence and align it with the NIST AI Risk Management Framework where agentic behaviour is in scope.

The next maturity step is not more telemetry in the abstract. It is combining workflow identity, runner monitoring, and outbound access policy so an AI agent cannot silently widen its own blast radius inside the build system. That shift will matter most where GitHub Actions, service accounts, and secrets access overlap with code generation and deployment.

Practitioners should also expect the governance conversation to move closer to NHI inventory management. If an AI assistant can make dozens of outbound calls across registries and cloud services in a single task, then the question becomes whether the organisation can enumerate and constrain that behaviour with the same discipline it applies to other service identities.

For practitioners

• Instrument the runner, not just the model Capture process creation, outbound network access, and file events for every AI-assisted GitHub Actions job so security teams can reconstruct the full execution path.
• Separate cloud authentication from execution privilege Use Workload Identity Federation or API credentials only as the first trust layer, then constrain the workflow with task-scoped permissions, explicit egress policy, and minimal filesystem write access.
• Treat runtime dependency fetching as a control point Block or approve external package, container, and binary downloads during agent execution, because the dependency chain itself can become the attack path.
• Review GitHub Actions permissions as NHI policy Map each AI coding agent workflow to the smallest viable repository, cloud, and secret access set, then remove inherited permissions that the job does not need.
• Validate observability coverage against incident questions Ask whether current logs answer what the agent did, what it touched, and what it spawned. If not, add runtime monitoring before expanding agent usage.

Key takeaways

• AI coding agents in CI/CD can be fully authenticated and still remain operationally opaque at runtime.
• The StepSecurity trace shows a single review task can fan out into dozens of network calls across multiple trust boundaries.
• Security teams need runner-level monitoring, task-scoped privilege, and dependency controls before expanding agent use in production pipelines.

Key terms

• Runtime Dependency Sprawl: The expansion of external packages, container images, binaries, and services that an AI agent pulls during execution. It matters because each added dependency becomes a trust decision, a possible attack path, and a source of behaviour that static review may never see.
• 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.
• Workflow Identity: A workflow identity is the non-human identity represented by an automated CI/CD process when it authenticates, accesses secrets, or performs actions in other systems. In practice, it is the authority carried by the pipeline itself, and it must be governed with explicit scope, review, and revocation.
• 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.

What's in the full article

StepSecurity's full post covers the operational detail this post intentionally leaves for the source:

• Workflow run evidence showing exactly how Harden-Runner captured network, process, and file activity during Gemini execution
• Destination-by-destination runtime analysis across Google Cloud, GitHub, npm, and container registries
• Screenshots and trace examples from the Harden-Runner insights page for practitioners validating detection coverage
• Configuration patterns for pairing Gemini's native controls with runtime monitoring in production CI/CD

👉 StepSecurity's full post covers the runtime trace, dependency map, and Harden-Runner evidence in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management. It gives practitioners a practical foundation for governing delegated access across identity and security programmes.