How can you prove that your AI agents are operating within SOC 2 controls? Auditors ask for concrete evidence that every request made by an automated workload is authorized, that sensitive data never leaks, and that any deviation from policy is captured and reviewed. In many Azure deployments, AI agents run as service principals with wide‑ranging permissions, connect directly to databases or internal HTTP services, and leave no trace of what they actually did. The result is a black box that satisfies functional requirements but fails every audit checkpoint.
Typical AI‑agent pipelines start with a static client secret stored in a key vault, then launch a container that talks straight to a PostgreSQL instance, an internal API, or a Kubernetes exec endpoint. The agent authenticates once, holds the credential for the whole lifetime of the pod, and can issue any command the underlying role permits. When a breach occurs, there is nothing to show which query exposed personal data, which command triggered a privilege escalation, or whether a human ever approved the operation.
From an auditor’s perspective, the missing artifacts are:
- Immutable logs that tie each request to a specific identity and time stamp.
- Evidence that privileged actions were gated by a human or automated policy.
- Proof that any response containing regulated fields (PII, PHI, credit‑card numbers) was masked before it left the system.
- Replay‑able sessions that can be examined line‑by‑line during a compliance review.
Providing these items requires more than just configuring Azure AD roles. The setup, identity federation, least‑privilege service accounts, and token issuance, determines who may start a request, but it does not enforce any guardrails on the request itself. Without a control point in the data path, the request reaches the target directly, bypassing audit, masking, or approval mechanisms.
Why the data path must host the enforcement layer for SOC 2
SOC 2’s Trust Services Criteria demand that access to critical systems be both authorized and monitored. When the enforcement point lives inside the agent process, the agent can be compromised, the logs can be altered, and masking can be disabled. The only place where you can guarantee that every byte flowing between identity and resource is inspected is the gateway that sits between them. That gateway becomes the single source of truth for who did what, when, and how the data was transformed.
In practice, this means routing every AI‑agent connection through a Layer 7 proxy that understands the underlying protocol (SQL, HTTP, SSH, etc.). The proxy can apply policies in real time, record the full session, and emit structured events that map directly to SOC 2 audit requirements. Because the proxy is deployed as a network‑resident agent inside the customer’s VNet, it never exposes credentials to the calling AI service, and it can be hardened independently of the workload.
How hoop.dev creates audit‑ready evidence for SOC 2
hoop.dev is built exactly for this purpose. It sits in the data path and becomes the authoritative enforcement point for every AI‑agent request. The platform records each session, masks regulated fields on the fly, and requires just‑in‑time (JIT) approval for privileged commands. Because the enforcement happens outside the AI container, the evidence cannot be tampered with by the workload itself.
Session recording
hoop.dev records the full request‑response stream for every connection. The recordings are stored in an immutable log that includes the identity token, the timestamp, and the exact protocol payload. Auditors can replay a session to see the exact query that was run against a database, the parameters passed, and the response returned. This satisfies the SOC 2 requirement for “complete and accurate logging of system activity.”