An AI coding agent that runs nightly builds pulls schema information from Snowflake, writes temporary tables, and then pushes generated data back to the warehouse, all under ffiec‑mandated controls. The agent authenticates with a service‑account token that has read‑write privileges across all databases, and no human ever watches the queries it issues.
In that situation the organization can’t tell which statements created a new table, which columns contained personally identifiable information, or whether a query was approved by a data steward. The token is static, the connection bypasses any review step, and Snowflake’s native audit logs only capture the fact that a user ran a query, not the intent or the policy context.
Most teams address the first part of the problem by federating the agent through an OIDC provider and granting the smallest set of roles required for the job. That step establishes who the request is and whether it may start, but the request still travels directly to Snowflake. No guardrails inspect the SQL, no inline masking hides sensitive columns, and no workflow forces a human to approve a risky DDL operation.
Enter hoop.dev. It sits in the data path between the AI coding agent and Snowflake, acting as an identity‑aware proxy that can enforce policy at the protocol layer. hoop.dev records every session, masks fields that match configured patterns, blocks commands that match deny lists, and routes high‑risk queries to an approval workflow before they reach the database.
How hoop.dev meets ffiec requirements
ffiec expects continuous evidence of who accessed what data, when, and under what controls. hoop.dev provides that evidence automatically:
- Session recording: Each interaction with Snowflake is recorded in a log that auditors can replay.
- Inline data masking: Sensitive columns such as SSN or credit‑card numbers are redacted in the response before they reach the agent, ensuring the agent never sees raw PII.
- Just‑in‑time approval: When a query matches a high‑risk pattern, e.g., a DROP TABLE or a bulk export of a regulated schema, hoop.dev pauses the request and requires a designated steward to approve it.
- Command blocking: Dangerous statements that violate policy are rejected outright, preventing accidental or malicious data loss.
All of these outcomes are produced because hoop.dev is the only component that can inspect traffic on the way to Snowflake. The identity provider supplies the token, but without hoop.dev the token would travel unexamined.
Architecture overview
The AI coding agent authenticates to an OIDC identity provider (Okta, Azure AD, etc.). hoop.dev validates the token, extracts group membership, and uses that information to apply fine‑grained policies. The gateway holds the Snowflake credentials, so the agent never sees them. When the agent issues a SQL statement, hoop.dev parses the wire protocol, applies masking rules, checks the command against deny lists, and either forwards it to Snowflake or triggers an approval workflow.