All posts

Audit logging for AI agents on Snowflake

An auditor's first question about an AI agent is not "do you have logs?" It is "could the agent have changed them?" If the honest answer is yes, you do not have audit logging. You have a diary the suspect keeps. For agents querying Snowflake, that distinction decides whether the record is worth anything. Lead with the requirement, because it dictates the architecture. Audit logging is trustworthy only when the log is written by something the agent does not control, attributed to a single princi

Free White Paper

K8s Audit Logging + AI Audit Trails: The Complete Guide

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

Free. No spam. Unsubscribe anytime.

An auditor's first question about an AI agent is not "do you have logs?" It is "could the agent have changed them?" If the honest answer is yes, you do not have audit logging. You have a diary the suspect keeps. For agents querying Snowflake, that distinction decides whether the record is worth anything.

Lead with the requirement, because it dictates the architecture. Audit logging is trustworthy only when the log is written by something the agent does not control, attributed to a single principal, and captured at the level of individual statements. Get those three right and the rest is configuration.

The requirement, stated plainly

The record of what an agent did on Snowflake must live outside the agent process. An agent that writes its own audit log can rotate it, omit a line, or never start it. So the log has to be produced at a boundary the agent passes through but cannot reconfigure. That is the architectural constraint audit logging has to satisfy before any tooling matters.

There is a second clause to the requirement that teams miss. The log has to attribute each statement to one identity, not to the shared connection everyone runs through. Snowflake's QUERY_HISTORY records the statements, but for agents it usually records them under a single service account, because that is how agents connect. An audit log that says "the service account ran 40,000 queries" cannot answer "which agent ran this one," and that is the question every investigation actually asks. Attribution per agent is as load-bearing as tamper resistance.

Put together, the requirement is three things at once: the log lives outside the agent, ties to a per-agent principal, and captures individual statements with their outcomes. Miss any one and the log degrades from evidence to anecdote.

Continue reading? Get the full guide.

K8s Audit Logging + AI Audit Trails: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Meet it with a gateway boundary

hoop.dev is an open-source Layer 7 access gateway. It proxies the Snowflake connection through an in-network agent, so engineers and AI agents query real Snowflake data through hoop.dev. Because every statement passes through the gateway, audit logging happens there, outside the agent runtime, which is exactly where the requirement says it must be.

  1. Register the Snowflake connection in hoop.dev. The gateway brokers access as the session principal and holds the warehouse credential.
  2. Authenticate each agent to the gateway through your identity provider over the MCP server, so each log entry maps to a known principal.
  3. Capture at the command level: each statement, the principal, the timestamp, and the outcome, including denials.
  4. Route the session events to your sink, for example by pointing the webhooks plugin at a monitoring destination, so the audit record sits alongside the rest of your evidence.

Verify the log is independent

Run a query through the agent and confirm the audit entry shows the statement, principal, and time at the gateway. Then confirm the agent has no path to edit or delete that entry. Independence from the agent is the property that turns a log into audit logging, so test for it directly rather than assuming it.

Pitfalls

  • Trusting agent-side logs as the record. They are convenient and not authoritative. Keep the system of record at the gateway.
  • Logging connections but not statements. "Session opened" is not an audit trail. Capture the commands.
  • Dropping denied attempts. The queries an agent could not run belong in the log.

See how gateway audit logging is structured and the getting-started guide to set up the connection.

FAQ

Is Snowflake's own query history enough for audit logging?

It helps, but tying every statement to a specific agent identity and capturing it outside the agent is what makes the record defensible. The gateway provides both.

Can I send the audit log to my existing tools?

Yes. Session events can be emitted through the webhooks plugin to a monitoring or evidence sink so the audit record lives with the rest of your stack.

Does the log include sensitive data?

Masking redacts regulated fields in returned data before the client sees them, so the audit record does not become a store of PII.

hoop.dev is open source. Read the code and build agent audit logging you can defend at github.com/hoophq/hoop.

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