Putting access controls around GitHub Copilot: session recording for AI coding agents (on CI/CD pipelines)

Why session recording matters for AI‑assisted CI/CD

When an AI coding assistant like GitHub Copilot writes code during a build, the resulting files can contain secrets, insecure patterns, or logic errors that only surface later in production. Without a reliable record of what the assistant generated, teams struggle to trace the origin of a vulnerability, to attribute responsibility, or to satisfy auditors who demand evidence of how code was produced. The cost of a leaked credential or a compliance finding can be weeks of emergency response, lost developer time, and reputational damage.

Most organizations run Copilot directly inside their CI runners or local development containers. The AI agent receives a prompt, emits code, and the pipeline proceeds to compile, test, and deploy. In that flow, there is no immutable log of the interaction, no way to mask accidental secret exposure, and no checkpoint for a human reviewer before the code touches production resources. The request travels straight from the CI job to the build environment, bypassing any guardrail that could capture the exchange.

What the problem looks like today

Engineers typically grant the CI service account a static token that lets the runner pull source, run tests, and push artifacts. The same token also permits the Copilot‑driven step to write files into the repository. Because the AI runs as part of the job, any secret it accidentally emits is written to the repository and may be scanned later by secret‑detection tools, but the exact moment of creation is lost. Auditors ask for a timeline of who generated which line of code; the answer is “the CI job” – a black box that cannot be dissected.

Even when teams enable basic logging on the runner, those logs only capture process start‑up and exit codes. They do not retain the full request‑response payload of the AI model, nor do they allow inline redaction of sensitive fields before the data lands in the repository. The gap is a missing enforcement layer that sits between the AI agent and the CI environment.

How to add session recording with hoop.dev

To close the gap, place an identity‑aware gateway in the data path between the Copilot agent and the CI runner. The gateway authenticates the request via OIDC, reads the user or service‑account identity, and then proxies the traffic to the runner. While the request flows through the gateway, hoop.dev records every interaction, timestamps each message, and stores the session log in a durable backend. Because the recording happens inside the gateway, the AI‑generated code is captured before it reaches the repository, giving teams a complete replayable audit trail.

hoop.dev also supports inline masking. If a secret pattern is detected in the AI output, the gateway can replace the value with a placeholder before the code is written, preventing accidental exposure. The same gateway can enforce just‑in‑time approval: a policy can require a human reviewer to sign off on any change that modifies authentication‑related files. All of these controls are enforced at the gateway, not in the CI runner, ensuring that the runner never sees unapproved or unmasked content.

Setting up this architecture follows three logical steps:

• Deploy the gateway. Use the Docker Compose quick‑start to run hoop.dev alongside your CI infrastructure. The deployment includes an agent that lives on the same network segment as the runner, so traffic is proxied locally.
• Configure the GitHub Copilot connection. Register the CI runner as a target in hoop.dev, providing the runner’s credentials (the static token) to the gateway. The gateway stores the credential; the AI agent never sees it.
• Enable session recording. In the gateway policy, turn on the recording flag for the Copilot‑to‑runner flow. The policy also defines masking rules and approval steps if desired.

Once the gateway is in place, every Copilot‑driven coding session that runs in CI is captured as a replayable record. Security teams can query the logs to see exactly which prompts produced which code snippets, and auditors can extract a timeline that shows who approved each change. The approach also satisfies the principle of least privilege: the CI service account only receives a short‑lived token from the gateway, and the gateway can revoke access instantly if a policy violation is detected.

Key benefits of the gateway‑based model

• Full auditability: hoop.dev records each AI‑generated request and response, providing a forensic‑ready log.
• Real‑time protection: inline masking prevents secrets from ever being written to the repository.
• Human oversight: just‑in‑time approval workflows ensure that high‑risk changes are reviewed before they execute.
• Zero credential exposure: the AI agent never handles the runner’s static token; the gateway abstracts the secret.

The architecture keeps enforcement where it belongs – at the data path – and leaves identity verification to your existing OIDC provider. This separation means you can adopt the same gateway for other AI agents, databases, or SSH access without redesigning your identity stack.

Getting started

For a step‑by‑step walkthrough, see the getting‑started guide. The documentation walks you through deploying the gateway, registering a CI runner, and enabling session recording for AI‑driven pipelines. All configuration details, including policy syntax and masking rule definitions, are covered in the learn section of the site.

The source code and example manifests are available in the open‑source repository: github.com/hoophq/hoop. Clone the repo, follow the README, and you’ll have a production‑ready gateway that records every Copilot session in your CI/CD workflow.

FAQ

Does session recording add latency to the CI job? The gateway adds only the network hop between the AI agent and the runner. In practice the overhead is measured in milliseconds and is outweighed by the security benefits.

Can I retroactively apply recording to existing pipelines? Yes. Once the gateway is in place, you can update the policy to enable recording for any existing target without changing the CI scripts.

What happens to the logs after a job completes? hoop.dev stores the session logs in a durable backend that can be queried for audits. Retention policies are configurable, allowing you to align with compliance requirements.