How can you prove to an auditor that a fleet of autonomous agents running on Azure is following SOC 2 controls?
Auditors expect concrete artifacts: who accessed what, when, and whether any sensitive data was exposed. When a script or AI‑driven process talks directly to a database or a Kubernetes cluster, the trace often ends at the network level. The agent holds a static credential, the connection stays open‑ended, and the cloud provider’s logs only show that the principal was used, not which SQL statements were executed, which rows were returned, or whether a secret was inadvertently printed.
That is the reality many teams face today. An autonomous agent receives a service principal in Azure AD, gets a role that can read and write to a database, and then launches in a CI/CD pipeline. The role assignment decides whether the request may start. Once the agent runs, it can execute any command its role permits, and Azure’s audit logs record only the sign‑in event, leaving the organization without the evidence required for SOC 2.
Why soc 2 evidence matters for autonomous agents
SOC 2 focuses on five trust service criteria, with security and confidentiality being the most relevant for automated workloads. The criteria demand:
- Documented access controls that enforce least‑privilege.
- Complete, immutable logs of every access request and response.
- Mechanisms to prevent or review risky operations before they happen.
- Protection of sensitive data in transit and at rest, including masking of PII in responses.
When an agent talks directly to a target, the only evidence you can hand to an auditor is the Azure AD sign‑in log. That log tells you the principal was used, but it does not satisfy the “what was done” or “was it approved” requirements of SOC 2. The gap is not the identity system; it is the lack of a control surface that can observe and enforce policy on the data path.
Setup: identity and least‑privilege for agents
The first step is to give each autonomous agent a distinct identity in Azure AD. Use service principals or managed identities, assign them only the permissions they need, and store those credentials in a vault. This setup decides who the request is and whether it may start, but it does not provide any enforcement beyond the initial token validation. The agent can still execute any command its role permits, and Azure’s logs record only the sign‑in event.
The data path: inserting a gateway
To meet SOC 2, the enforcement point must sit on the data path between the agent and the target resource. That is where hoop.dev comes in. hoop.dev acts as an identity‑aware proxy that terminates the agent’s connection, inspects the wire‑protocol, and applies policy before the request reaches the database, Kubernetes API, or SSH server. Because the gateway is the only place the traffic can flow, it becomes the sole location where you can reliably enforce masking, request approvals, and record every interaction.
Enforcement outcomes that satisfy SOC 2
Once hoop.dev sits in the data path, it can provide the exact artifacts auditors need:
- Session recording. hoop.dev captures the full request and response stream for each connection. You can replay the recorded session to prove exactly what the agent did, satisfying the “complete logs” requirement.
- Just‑in‑time (JIT) approvals. For high‑risk commands, hoop.dev pauses the request and routes it to a human reviewer. The approval decision stores alongside the session, giving evidence that risky actions received proper authorization.
- Inline data masking. When a response contains personally identifiable information, hoop.dev redacts or masks those fields in real time. The masking policy logs each transformation, proving that confidential data remained protected in transit.
- Command blocking. hoop.dev rejects commands that violate policy, such as attempts to drop tables or modify RBAC settings. The block event records the attempt, showing that the organization prevented prohibited actions.
Each of these outcomes exists only because hoop.dev sits in the data path. If you remove hoop.dev, the agent regains unrestricted access and none of the audit artifacts remain.
How the evidence is delivered to auditors
After deployment, hoop.dev records session logs, approval records, and masking events in a store that can be exported in JSON or CSV format. You can feed the export directly into a SOC 2 audit package. Auditors can then verify:
- Timestamped proof that a particular agent identity performed a specific query.
- Whether the query result was masked according to policy.
- The approval workflow that allowed a privileged command.
- The complete command history for the audit period.
Because the gateway generates the logs, they remain independent of the agent’s own logging capabilities, eliminating the risk of log tampering by a compromised process.
Getting started
Deploy the hoop.dev gateway in your Azure virtual network using the Docker Compose quick‑start or the Helm chart for Kubernetes. Configure Azure AD as the OIDC provider, register each autonomous agent’s service principal, and define policies for masking and JIT approval in the hoop.dev policy file. Detailed steps are available in the getting‑started guide and the broader learn section. The source code and example configurations live in the public repository.
FAQ
Do I need to change my existing service principals?
No. hoop.dev works with any Azure AD‑issued token. You simply point the gateway to use the same client ID and secret, and hoop.dev enforces policies on top of the existing identity.
Can hoop.dev mask data in a PostgreSQL response?
Yes. hoop.dev inspects the PostgreSQL wire protocol and replaces configured column values with a placeholder before the response reaches the agent.
What happens if an agent tries to bypass the gateway?
Because hoop.dev is the only network‑reachable endpoint for the target resource, any direct connection attempt fails due to network policies. The gateway remains the sole enforcement point.
Is the audit data itself protected?
The system writes audit records once for the retention period.
Azure AD policies control who can retrieve the records, ensuring only authorized auditors access the evidence.
By placing an identity‑aware proxy in the data path, you turn autonomous agents from a compliance blind spot into a source of verifiable SOC 2 evidence. hoop.dev provides the session recording, just‑in‑time approvals, inline masking, and command blocking that auditors look for, while still allowing agents to operate at scale.
Explore the open‑source repository on GitHub to see the implementation details and start building a SOC 2‑ready pipeline for your autonomous agents.
