When SOC 2 auditors see a complete, tamper‑evident trail of every AI‑generated code change and data request on Azure, they can certify that the organization meets the standard’s strict access‑control and audit‑logging requirements.
In many teams, AI coding agents run as long‑lived service principals that hold broad permissions to source repositories, build pipelines, and data stores. Those credentials are often baked into CI/CD jobs or stored in plain text in configuration files. The agents can read proprietary code, write patches, and pull sensitive datasets without any human in the loop. Because the connection goes straight from the agent to Azure resources, there is no record of who triggered a change, what exact command was issued, or whether the data returned contained confidential information.
This reality violates two core SOC 2 criteria: (1) the ability to produce a complete, immutable log of all privileged actions, and (2) the enforcement of least‑privilege access at the moment of use. Without a control point that can observe and intervene on the traffic, organizations cannot demonstrate that they prevent unauthorized reads or writes, nor can they prove that every AI‑driven operation was approved.
Many teams have already adopted modern identity practices: they issue short‑lived OIDC tokens to agents, assign service accounts to specific projects, and configure Azure role‑based access control (RBAC) to limit scope. These steps identify *who* the request is coming from and *what* resources it may touch, but the request still travels directly to the Azure endpoint. No gateway sits in the middle to enforce policies, mask returned secrets, or capture a replayable session. The gap leaves the audit trail incomplete and the enforcement surface exposed.
The missing piece is a data‑path enforcement layer that can inspect every wire‑level request, apply just‑in‑time approvals, block dangerous commands, and record the full interaction for later review. That layer must be positioned between the identity system and the Azure target, so that no agent can bypass it.
Explore the source code and contribute at github.com/hoophq/hoop.
hoop.dev provides exactly that Layer 7 gateway. It sits on the network, receives the authenticated request, evaluates policy, and only then forwards the traffic to the Azure resource. Because the gateway is the sole path for traffic, all enforcement outcomes are guaranteed to happen.
What SOC 2 expects for AI coding agents on Azure
SOC 2’s Trust Services Criteria for security require organizations to:
- Maintain an immutable log of every privileged operation, including the identity of the requester, the command executed, and the response returned.
- Enforce least‑privilege access, ensuring that agents can only act on resources they are explicitly authorized for.
- Provide evidence that sensitive data is protected in transit and at rest, and that any exposure is detected and recorded.
- Allow auditors to replay critical sessions to verify that controls behaved as intended.
AI coding agents amplify the risk because they can generate large numbers of requests automatically. Without a centralized enforcement point, each request can silently bypass controls, making it impossible to prove compliance.
How a Layer 7 gateway satisfies the requirement
Setup. The organization configures OIDC or SAML identity providers (Azure AD, Okta, etc.) and creates service accounts for each AI agent. Tokens are short‑lived and scoped to the minimum set of Azure roles needed for the task. This step decides who may start a request, but on its own does not enforce any guardrails.
The data path. hoop.dev is deployed as a network‑resident gateway. All AI‑initiated connections to Azure services, whether to Azure SQL, Blob Storage, or the Azure Kubernetes Service, are routed through this gateway. Because the gateway is the only path, it becomes the exclusive place where enforcement can occur.
Enforcement outcomes. Once traffic reaches the gateway, hoop.dev records each session, captures the exact command and response, and stores the replayable stream for audit. If a request attempts to read a secret column, hoop.dev masks the value before it reaches the agent. When a risky operation (for example, deleting a production database) is detected, hoop.dev prompts a human approver and blocks the command until approval is granted. All of these actions, session recording, inline masking, just‑in‑time approval, and command blocking, exist only because hoop.dev sits in the data path.
Architectural flow for AI coding agents
1. An AI coding agent authenticates to the identity provider and receives a short‑lived OIDC token.
2. The token is presented to hoop.dev, which validates the signature and extracts the agent’s identity and group memberships.
3. hoop.dev consults policy rules that define which Azure resources the agent may access, what commands are allowed, and which data fields must be masked.
4. The gateway forwards the request to the Azure endpoint only after the policy check passes. If the request requires approval, hoop.dev pauses the flow and notifies the designated approver.
5. The Azure service processes the request and returns a response. hoop.dev masks any sensitive fields, records the full exchange, and then streams the sanitized result back to the agent.
This flow guarantees that every privileged action is observable, controllable, and auditable, satisfying the core SOC 2 evidence requirements.
Benefits for SOC 2 evidence
- Immutable session logs provide a complete, searchable trail that auditors can review without relying on the AI agent’s internal logs.
- Just‑in‑time approvals create a documented decision point for high‑risk actions, turning ad‑hoc permissions into verifiable events.
- Inline data masking ensures that secret values never leave the gateway in clear text, reducing the risk of accidental exposure.
- Replay capability lets auditors watch exactly what happened during a code generation or data extraction, proving that controls behaved as intended.
Because hoop.dev is the single point of control, organizations can generate the audit artifacts required by SOC 2 without stitching together logs from multiple services.
Getting started
Begin with the getting‑started guide to deploy the gateway in your Azure network. The documentation explains how to connect AI coding agents, configure OIDC identity, and define policy rules for masking and approvals. For deeper technical details, the learn section covers policy language, session replay, and integration patterns.
FAQ
Does hoop.dev replace Azure RBAC?
No. hoop.dev works alongside Azure RBAC. Azure RBAC defines the static permissions for a service principal, while hoop.dev adds dynamic, request‑time controls such as approvals, masking, and detailed logging.
Can hoop.dev be used with other cloud providers?
Yes. The gateway supports multiple connectors, including AWS and on‑premise services. The same architectural principles apply: identity verification, data‑path enforcement, and audit‑ready outcomes.
Is the recorded session data stored securely?
hoop.dev records sessions in a tamper‑evident store that is separate from the agent’s runtime. The storage location is configured by the operator, and access to the logs is governed by the same policy engine that protects live traffic.
