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

Unrecorded AI coding sessions on Kubernetes give teams no visibility into what code is generated or executed.

In many organizations, Copilot runs inside a pod that talks directly to the IDE, the container registry, and internal services. The pod is granted a broad service‑account token that lets it pull images, push artifacts, and even run arbitrary commands inside the cluster. No one watches the traffic, no logs capture the exact prompts or the code that is emitted, and any accidental leakage of secrets goes unnoticed until it is already in production.

Engineers quickly realize they need session recording to answer questions like: Who asked Copilot to generate this snippet? Did the agent retrieve a credential from a secret store? Were any prohibited commands issued? The desire for recording does not change the fact that the request still travels straight from the Copilot pod to the target service. Without an additional control layer, the request bypasses any audit, any inline masking, and any human approval step.

Why session recording must sit in the data path

Authentication and identity (OIDC, service accounts, group membership) tell the system who is making a request. That information is essential for deciding whether a request should be allowed to start, but it does not capture what happens after the request leaves the identity provider. The enforcement outcomes, recording every command, replaying a session, masking secrets in responses, can only be guaranteed if they are applied where the traffic actually flows.

Placing a guardrail in the data path creates a single, enforceable boundary. The boundary can inspect each protocol message, write it to an audit store, and optionally block or mask content before it reaches the target. This is the only reliable way to achieve true session recording for AI agents.

Introducing hoop.dev as the enforceable gateway

hoop.dev is an open‑source Layer 7 gateway that sits between identities and the infrastructure that Copilot accesses. It proxies connections to databases, Kubernetes APIs, SSH, and HTTP services. When a Copilot pod initiates a connection, the request is routed through hoop.dev’s gateway agent that runs inside the same Kubernetes cluster.

Because hoop.dev is the data‑path component, it can:

• Record every request and response, preserving the exact prompt, generated code, and any downstream API calls.
• Mask sensitive fields (for example, API keys that appear in generated snippets) before they are logged or returned to the user.
• Require just‑in‑time approval for high‑risk operations, such as writing to a production namespace.
• Replay a recorded session for forensic analysis or compliance review.

The gateway does not replace the existing identity system. You still configure OIDC or SAML providers (Okta, Azure AD, Google Workspace) so that only authenticated users or service accounts can obtain a token that hoop.dev will validate. The token’s claims drive the policy decisions inside the gateway, but the actual enforcement, recording, masking, approval, happens only because hoop.dev sits in the data path.

How the architecture works for Copilot on Kubernetes

1. Deploy the hoop.dev gateway in the cluster using the official Docker Compose or Helm chart. The deployment includes a network‑resident agent that lives next to the Copilot pod.

2. Register the Copilot service as a connection in hoop.dev. The connection definition includes the target Kubernetes API endpoint and the credential that hoop.dev will use to authenticate to the API. The credential never leaves the gateway.

3. When the Copilot pod starts a request (for example, a kubectl exec to run a build script), it authenticates to hoop.dev with its OIDC token. hoop.dev validates the token, extracts group membership, and checks the policy for that identity.

4. The request passes through the gateway. hoop.dev writes the full request and response to its audit store, applies any configured inline masking, and, if the operation matches a high‑risk rule, pauses for a human approver before forwarding the command to the Kubernetes API server.

5. After the operation completes, the session remains available for replay. Auditors can filter recordings by user, time, or resource, and developers can watch the exact sequence that led to a change.

All of these outcomes, recording, masking, approval, replay, exist only because hoop.dev is positioned in the data path. If you removed hoop.dev, the Copilot pod would still be able to talk to the API, but none of the enforcement would occur.

Getting started

Follow the getting started guide to spin up the gateway and register a Copilot connection. The documentation also covers how to define masking rules and approval workflows in the feature documentation. For a hands‑on example, clone the repository and explore the Helm chart that ships with hoop.dev.

View the source on GitHub to see how the gateway is built and contribute improvements.

FAQ

Does session recording add latency to Copilot operations?

hoop.dev records traffic as it passes through the gateway. The additional latency is typically a few milliseconds, far less than the network round‑trip to the Kubernetes API server.

Can I disable recording for specific low‑risk namespaces?

Yes. Policies are expressed in the gateway configuration, allowing you to scope recording to particular resources, users, or request types while leaving others unrecorded.

Is the recorded data stored securely?

All recordings are written to the audit store configured for hoop.dev. Access to that store is controlled by the same OIDC‑based policies that protect the gateway, ensuring only authorized personnel can view or replay sessions.