All posts

Audit logging for autonomous agents on Snowflake

Autonomous agents that can query Snowflake without oversight create a blind spot for compliance. Why audit logging matters for autonomous agents When a script or AI-driven process runs queries on a data warehouse, the organization loses visibility into who asked what, when, and why. Regulators and internal auditors expect a reliable trail that ties each statement back to an identity. Without audit logging, a mis-configured transformation can exfiltrate sensitive columns, and the breach invest

Free White Paper

K8s Audit Logging + Single Sign-On (SSO): The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

Autonomous agents that can query Snowflake without oversight create a blind spot for compliance.

Why audit logging matters for autonomous agents

When a script or AI-driven process runs queries on a data warehouse, the organization loses visibility into who asked what, when, and why. Regulators and internal auditors expect a reliable trail that ties each statement back to an identity. Without audit logging, a mis-configured transformation can exfiltrate sensitive columns, and the breach investigation will lack the evidence needed to pinpoint the cause.

Current practice and its gaps

Many teams grant service accounts direct credentials to Snowflake and let bots connect with the same static password or key. The connection goes straight from the agent to the warehouse, bypassing any central control point. In that model:

  • Only the Snowflake query history records the raw SQL; it does not capture the originating identity of the autonomous process.
  • There is no way to enforce a policy that requires a human approval before a destructive command runs.
  • Session replay is impossible because the agent holds the credential and can stream results without a checkpoint.

These gaps leave the organization exposed to accidental data loss, policy violations, and audit failures.

The missing control: a data-path gateway

What the environment needs is a single, enforceable boundary that sits between the identity that initiates the request and the Snowflake endpoint. The gateway must be the only place where traffic can be inspected, approved, or recorded. Identity verification (OIDC or SAML) can still happen upstream, but the actual enforcement, capturing every query, attaching the user’s claim, and storing a log, must occur where the request passes through.

Introducing hoop.dev as the audit gateway

hoop.dev provides exactly that layer-7 proxy. It runs a network-resident agent inside the same VPC as Snowflake, and every connection from a bot or AI agent is forced through the gateway. The gateway authenticates the caller’s token, maps the token to a role, and then proxies the Snowflake wire protocol. While proxying, hoop.dev records each statement, timestamps it, and tags it with the caller’s identity. The recorded session can be replayed later for forensic analysis.

Continue reading? Get the full guide.

K8s Audit Logging + Single Sign-On (SSO): Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

How hoop.dev captures audit logs for Snowflake

Setup. Engineers configure an OIDC provider (for example Okta or Azure AD) as the source of identity tokens. Each autonomous agent obtains a short-lived JWT that proves who it is. The token is presented to hoop.dev, which validates the signature and extracts group membership.

The data path. Once the token is accepted, hoop.dev becomes the sole conduit to Snowflake. The gateway holds the Snowflake service credentials internally; the agent never sees them. All SQL traffic flows through hoop.dev, which can inspect the protocol without requiring any changes to the client library.

Enforcement outcomes. hoop.dev records every query in a log, associating it with the original identity and the exact timestamp. It also captures the full response payload, enabling replay of the session exactly as the agent saw it. Because the gateway is the only place where traffic passes, it can enforce additional guardrails, such as blocking DROP statements or requiring a manual approval step before a write-heavy operation proceeds.

The audit log is stored in a backend that the organization controls, and the logs can be exported to SIEMs or retained for compliance reporting. Since hoop.dev is open source, teams can inspect the implementation and verify that the logging behavior meets their policy requirements.

Getting started

To add audit logging for Snowflake agents, follow the getting-started guide that walks you through deploying the gateway, configuring OIDC, and registering a Snowflake connection. The learn section provides deeper detail on session recording, replay, and how to query the audit store.

Explore the source code, contribute improvements, or raise issues on the project’s GitHub repository: github.com/hoophq/hoop.

FAQ

Does hoop.dev store query results in clear text?

No. The gateway records the raw payload for replay, but the storage location is configurable. Teams can encrypt the log store or forward logs to an external system that meets their data-handling policies.

Can I still use Snowflake’s native query history?

Yes. hoop.dev’s audit logs complement Snowflake’s own logs by adding the caller’s identity and the exact session timeline, which Snowflake alone cannot provide for service accounts.

What happens if an autonomous agent tries to run a blocked command?

hoop.dev intercepts the command before it reaches Snowflake and returns an error to the agent. The attempt is still logged, giving you visibility into the policy violation.

Open source

Save the open-source gateway for agent data access

Hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.

Star and save the repo →More posts