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

When every AI‑driven coding session is captured, replayable, and tied to a verified engineer, you achieve reliable session recording that proves Copilot never leaks secrets and lets you investigate any unexpected change after the fact. The ability to review exactly what the model suggested, what the developer accepted, and which internal services were touched gives your security team the evidence they need without slowing down development.

Achieving that level of confidence does not require rewriting the Copilot integration or instrumenting every IDE. Instead, you place a transparent gateway between the AI agent and the internal resources it talks to. The gateway records each request and response, tags the traffic with the user’s identity, and makes the log available for audit and replay. With that foundation, session recording becomes a built‑in part of your AI‑assisted development workflow.

Why session recording matters for AI coding agents

GitHub Copilot runs inside your organization’s network as an internal SaaS that receives prompts from developers, queries internal codebases, and sometimes writes code directly to repositories. Because the model can generate code that includes credentials, API keys, or proprietary algorithms, a single stray suggestion can become a data‑leak incident. Without a reliable audit trail, you cannot prove whether a secret was introduced by a human, an AI, or a compromised service account.

Beyond leakage, session recording helps you answer compliance questions, perform post‑mortems, and train your own guardrails. If a production outage is traced to a change suggested by Copilot, you can replay the exact exchange, see the context the model had, and verify that the change followed your change‑management policy.

Current practice and its blind spots

Many teams deploy Copilot as an internal service that authenticates with a shared service‑account token. The token is stored in configuration files or environment variables that every developer’s machine can read. The AI agent then talks directly to internal Git repositories, package registries, or secret stores. In that model, the connection bypasses any central control point. The result is a "wild west" of access: anyone who possesses the token can issue commands, and no one can tell which user triggered a particular request. No session logs are produced, no inline masking of sensitive fields occurs, and there is no way to pause a risky operation for human approval.

Because the gateway is missing, the organization can only rely on downstream logs that are fragmented, unlinked to identity, or stored in places the AI agent itself can reach. The lack of a unified audit surface makes it impossible to enforce policies such as "record every Copilot‑initiated push" or "mask any secret returned in a response".

The data‑path solution: hoop.dev

hoop.dev is a Layer 7 gateway that sits between identities and the infrastructure that Copilot accesses. It proxies the traffic, inspects the wire‑protocol, and applies policies before the request reaches the target. Because enforcement occurs only in the data path, hoop.dev is the sole component that can guarantee session recording, inline masking, and just‑in‑time approvals.

Setup components, OIDC or SAML identity providers, service‑account definitions, and least‑privilege role bindings, determine who may initiate a request, but they do not enforce any control. The gateway is where the enforcement happens. hoop.dev records each session, tags it with the verified identity, and makes the log available for replay. In other words, hoop.dev makes session recording a reality; without it, the same setup would leave the traffic unobserved.

How hoop.dev captures Copilot sessions

When a developer invokes Copilot, the client sends a request to the internal Copilot endpoint. Instead of pointing the client at the Copilot service directly, you configure the client to connect through hoop.dev. The gateway authenticates the user’s OIDC token, extracts group membership, and decides whether the user is allowed to call the AI model. Once authorized, hoop.dev forwards the request to the Copilot service over a secure channel.

During the round‑trip, hoop.dev records the full request payload, the model’s response, and any subsequent Git operations that the model triggers. Each record is linked to the user’s identity, providing a clear audit trail. If the response contains a secret pattern, hoop.dev can mask that field in the stored log, ensuring that downstream auditors never see the raw secret while still preserving the context of the operation.

Because hoop.dev sits in the data path, it can also enforce just‑in‑time approval for high‑risk actions. For example, a Copilot‑generated push to a production repository can be routed to a human approver before the actual Git write is performed. The approval decision is recorded alongside the session, giving you end‑to‑end visibility.

Getting started

To add session recording for your internal Copilot deployment, start with the official getting‑started guide. The guide walks you through deploying the gateway with Docker Compose, configuring OIDC authentication, and registering your Copilot endpoint as a connection. Once the gateway is running, point your Copilot client at the gateway’s address and let hoop.dev handle the rest.

All of the policy definitions, masking rules, and approval workflows are expressed in configuration files that the gateway reads at start‑up. Detailed examples are available in the learning portal, where you can see how to define a rule that masks anything that looks like an AWS secret key or a private TLS certificate.

When the gateway is in place, every Copilot‑driven operation will be captured, and you will have a replayable session for each interaction.

FAQ

Do I need to modify the Copilot SDK or change my code?

No. hoop.dev works as a transparent proxy. You only change the endpoint address that the client uses; the rest of the SDK remains unchanged.

Where are the recorded sessions stored?

hoop.dev makes the recorded sessions available through its audit interface, where they can be queried by identity, time range, or resource.

Can I keep using my existing identity provider?

Yes. hoop.dev is an OIDC/SAML relying party and can integrate with any provider that issues standards‑based tokens, such as Okta, Azure AD, or Google Workspace.

Start protecting your AI‑assisted development workflow today by adding hoop.dev as the gatekeeper for session recording. Explore the open‑source repository for the full source code and contribution guidelines.