All posts

Configuring AI agents access to Snowflake with just-in-time access

Count the agents in your stack that hold a permanent Snowflake grant they use once a week. Each of those standing credentials is a key left in the door, valid at 3am whether or not anyone meant to run a query. Just-in-time access flips that: the grant exists for the task, then it is gone. Standing access is the default because it is easy. An agent gets a role, the role never expires, and the credential sits in a config file forever. One ends access when the work ends. The other leaves a live pa

Free White Paper

Just-in-Time Access + AI Human-in-the-Loop Oversight: The Complete Guide

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

Free. No spam. Unsubscribe anytime.

Count the agents in your stack that hold a permanent Snowflake grant they use once a week. Each of those standing credentials is a key left in the door, valid at 3am whether or not anyone meant to run a query. Just-in-time access flips that: the grant exists for the task, then it is gone.

Standing access is the default because it is easy. An agent gets a role, the role never expires, and the credential sits in a config file forever. One ends access when the work ends. The other leaves a live path into production data indefinitely. For an autonomous agent that runs unattended, the second option is the larger blast radius.

Standing grants versus scoped, per-task access

A standing grant answers "can this agent reach Snowflake?" with a permanent yes. Just-in-time access answers it per task: this agent, this schema, for this window, recorded. When the task finishes or the window closes, the path is gone and there is nothing left to steal from the agent's environment.

This matters most for agents because they do not get tired of having access. A human forgets a credential exists. An agent keeps a live connection open and will use whatever it holds, so the safest grant is the one that is not there between tasks.

Snowflake makes standing access especially tempting because connecting is cheap. A long-lived role and a key pair, and the agent can query forever at no extra setup cost. The cost shows up later, as a credential nobody remembers granting, attached to a role nobody has reviewed, reachable by any process that gets hold of the agent's environment. Just-in-time access trades that quiet, permanent exposure for a grant you can see start and see end. The warehouse role still defines the ceiling on what the agent could do; the time-bound grant defines whether the agent can do anything at all right now.

Continue reading? Get the full guide.

Just-in-Time Access + AI Human-in-the-Loop Oversight: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Set it up through the gateway

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 instead of connecting directly. The grant, the recording, and the masking live on that connection, outside the agent.

  1. Add the Snowflake connection to hoop.dev with its credentials. The gateway brokers access as the session principal, so there is no permanent password in the agent.
  2. Define the agent's access as time-bound rather than permanent. Access opens when the agent requests a session and closes when the session ends.
  3. Scope the session to the schema the task needs. A reconciliation job does not get the same reach as an analytics read.
  4. Route higher-risk operations, like a write to a production table, through an approval step before the session opens.

Verify that access actually closes

Open a session, run a query, end the session, then try the same query again without requesting access. It should fail. That failure is the control working: just-in-time access means the path does not survive the task. Check the session record to confirm the open, the statement, and the close are all attributed to the agent.

Pitfalls to avoid

  • Setting a "temporary" window so long it is effectively standing access. Keep windows tight to the task.
  • Granting the agent broad reach "to avoid re-requesting." Re-requesting is the feature, not the friction.
  • Forgetting writes need review. Pair just-in-time grants with an approval step for destructive statements.

See how just-in-time access changes the agent threat model and the getting-started guide to wire the first Snowflake connection.

FAQ

Does just-in-time access slow agents down?

Requesting a session adds a step, not a wait, for low-risk reads. Only operations you route for approval pause, and those are the ones worth pausing.

What happens to the connection after the task?

It closes. The agent holds no standing Snowflake credential, so there is nothing to reuse until it requests the next session.

Can I still allow always-on reads where they make sense?

Yes. Scope the policy per identity. A read-only analytics path can stay open while writes stay just-in-time and reviewed.

hoop.dev is open source. Read the code, model your Snowflake grants as just-in-time, and start 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