SOC 2 for AI agents: controlling access for audit-ready operations (on Postgres)

Uncontrolled AI agents can silently exfiltrate or corrupt production data, jeopardizing audit compliance.

What SOC 2 expects from automated workloads

SOC 2 evaluates five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. For any system that runs code automatically, the standard demands concrete evidence that:

• Only authenticated identities can initiate a session.
• Each request is bounded by the principle of least privilege.
• All actions are recorded with exact timestamps and the identity that performed them.
• Any change that could affect data confidentiality or integrity is approved by a designated reviewer.
• Sensitive data in responses is protected from unintended exposure.

When the workload is an AI agent that talks to a PostgreSQL instance, the auditor will look for logs that tie every SQL statement back to the agent’s service account, records of any manual approvals, and proof that personally identifiable information (PII) or secret keys are masked before they leave the database.

The typical, insecure baseline for AI‑driven database access

Most teams provision an AI service account with a static database password and let the model connect directly to PostgreSQL. The connection bypasses any gatekeeper, so the agent can run arbitrary queries, retrieve raw rows, and write data without any visibility from the security team. Because the credential lives in the container image or secret store, a compromise of the container gives an attacker the same unrestricted database access. There is no session replay, no inline masking, and no approval workflow – all of which SOC 2 expects as part of a controlled environment.

Adding identity and least‑privilege controls, but still missing audit evidence

Moving the credential management to an OIDC‑based identity provider and assigning the agent a role that only allows SELECT on a specific schema is a step forward. The agent now authenticates with a short‑lived token, and the role limits the tables it can touch. However, the request still travels straight to PostgreSQL, leaving the following gaps:

• No guaranteed record of which exact rows were read or written.
• No mechanism to mask credit‑card numbers or social‑security numbers that might appear in query results.
• No real‑time approval step for high‑risk statements such as UPDATE or DELETE on production tables.
• No replayable session that an auditor can examine later.

Those gaps mean the environment cannot produce the evidence SOC 2 auditors require.

How hoop.dev fills the evidence gap

hoop.dev is an identity‑aware, layer‑7 gateway that sits between the AI agent and the PostgreSQL server. By proxying every connection, hoop.dev can:

• Record each SQL command together with the agent’s OIDC identity and a precise timestamp.
• Apply inline data masking rules so that columns marked as sensitive are redacted before they leave the database.
• Require a just‑in‑time human approval for commands that match a risk policy, such as DELETE or ALTER.
• Store a replayable session stream that can be reviewed by auditors or incident responders.

All of these artifacts are generated automatically, without any code changes in the AI model. The gateway’s policy engine runs at the data path, so the agent never sees the underlying credential and cannot bypass the controls.

Mapping hoop.dev evidence to SOC 2 requirements

Because hoop.dev records each query together with the verified identity and a precise timestamp, it satisfies the security criterion’s “audit log” and “access control” sub‑requirements. The just‑in‑time approval workflow satisfies the change‑management expectations under processing integrity. Inline masking demonstrates compliance with the confidentiality and privacy criteria by ensuring that regulated data never appears in clear text outside the database. Finally, the replayable session files give auditors a concrete artifact to verify availability and integrity of the recorded data.

In practice, a SOC 2 audit can reference the hoop.dev log export, the approval records, and the masked result snapshots as the evidence package that proves the organization’s controls are operating effectively.

Getting started with hoop.dev for PostgreSQL and AI agents

Deploy the gateway using the getting‑started guide, register your PostgreSQL endpoint, and define masking rules for any columns that contain PII. The documentation in the learn section walks through policy creation, approval workflow configuration, and how to retrieve audit logs for SOC 2 reporting.

FAQ

Does hoop.dev replace the need for separate logging agents?

No. hoop.dev centralizes logging at the protocol level, so you no longer need a separate database‑level audit extension. It complements existing infrastructure monitoring but provides the SOC 2‑specific evidence directly.

Can I use hoop.dev with multiple AI services simultaneously?

Yes. Each service registers its own identity and connection profile. The gateway enforces policies per‑identity, so you can grant read‑only access to one model while requiring approvals for another.

What happens to encrypted columns that the masking engine cannot read?

hoop.dev respects the encryption and passes the ciphertext through unchanged. Masking rules apply only to clear‑text fields, ensuring you do not unintentionally break encryption semantics.

Explore the open‑source implementation and contribute to the project on GitHub.