Putting access controls around GitHub Copilot: session recording for AI coding agents (on Azure)

A development team that can replay every line of code suggested by GitHub Copilot, thanks to session recording, sees who approved each AI‑driven edit, and traces the exact moment a secret was injected, has full confidence in its AI‑assisted workflow. In practice, many organizations let Copilot run unchecked, using a shared personal access token or a service account that has blanket read‑write rights to every repository. The result is a blind spot: no audit of which prompts generated which snippets, no evidence of human oversight, and no way to prove that a secret‑leaking suggestion was never persisted.

Common mistakes compound the risk. First, teams often store the Copilot token in plain text within CI pipelines, exposing it to anyone who can read the build logs. Second, the AI‑coding agent talks directly to GitHub’s API, bypassing any internal proxy that could enforce policy. Third, because the traffic is not recorded, compliance auditors cannot verify that developers followed the organization’s code‑review process when AI‑generated changes were merged. The lack of session recording leaves the organization vulnerable to accidental data loss, insider threats, and regulatory scrutiny.

Why session recording matters for AI coding agents

Session recording captures a complete, immutable transcript of every request and response that flows between an AI coding agent and the GitHub API. With a reliable recording, security teams can answer three critical questions after the fact: who triggered the Copilot suggestion, what exact prompt was sent, and what code was returned. This evidence is essential for forensic investigations, for demonstrating adherence to internal policies, and for satisfying audit requirements that demand a traceable history of code changes.

The missing control in typical Copilot deployments

Most Copilot setups satisfy the identity requirement – the agent authenticates with an OIDC‑issued token – but they stop short of placing any enforcement point on the data path. The request travels straight from the developer’s workstation or CI runner to GitHub, and the response is rendered in the IDE without any intermediate gate. In this configuration the organization still has a token that proves the caller’s identity, yet there is no mechanism to record the session, mask sensitive data that might appear in a suggestion, or require a human approval before a risky snippet is merged. The precondition we need is a gateway that sits between the identity layer and the GitHub endpoint, where policy can be applied.

How hoop.dev provides immutable session recording for Copilot

hoop.dev is a Layer 7 gateway that proxies connections to infrastructure services, including the GitHub API used by Copilot. By deploying the hoop.dev gateway inside the Azure virtual network that hosts the CI runners and developer workstations, every Copilot request is forced to pass through the gateway before reaching GitHub. The gateway validates the OIDC token, extracts group membership, and then records the full request‑response exchange. Because hoop.dev sits on the data path, it is the only component that can guarantee a session recording exists for each AI‑driven interaction.

When a Copilot prompt is issued, hoop.dev creates a session record that includes the authenticated user, the exact prompt payload, and the code snippet returned. The record is stored in a secure store managed by the gateway, ensuring that later analysis cannot be altered. If the organization wants to mask secrets that appear in a suggestion – for example, API keys that the model may hallucinate – hoop.dev can apply inline masking before the response reaches the IDE. Additionally, hoop.dev can be configured to require a just‑in‑time approval step for any suggestion that touches privileged files, adding a human checkpoint without changing the developer workflow.

All of these controls happen without exposing the underlying GitHub token to the developer or the AI agent. The gateway holds the credential, the agent never sees it, and the policy engine runs where the developer cannot tamper with it. This separation satisfies the three‑beat arc: the starting state lacked any recording, the precondition adds identity but still leaves the request unchecked, and hoop.dev completes the picture by inserting the enforcement point that produces the session recording.

Getting started on Azure

To implement this architecture, start by deploying the hoop.dev gateway with the Azure‑compatible Docker Compose file provided in the official documentation. The quick‑start guide walks you through configuring OIDC authentication against Azure AD, registering a GitHub connection, and assigning the minimal role needed for the gateway to call the Copilot API. Once the gateway is running, update your CI pipelines and developer machines to point their GitHub client URLs to the hoop.dev endpoint. From that point forward, every Copilot interaction is recorded automatically.

For step‑by‑step instructions, see the getting‑started guide. The learn section provides deeper coverage of session‑recording policies, masking rules, and approval workflows.

Next steps and resources

• Review the policy model in the documentation to define which repositories require approval before AI‑generated changes are merged.
• Configure retention and export settings for session recordings to align with your audit schedule.
• Test the end‑to‑end flow with a non‑production repository before rolling out to production workloads.

Explore the open‑source repository on GitHub to examine the implementation details and contribute improvements: hoop.dev on GitHub.