All posts

Just-in-time access for AI agents on Snowflake

Want an AI agent querying Snowflake in the next few minutes without leaving a permanent credential behind? This is the short path. Just-in-time access means the agent gets a connection for the task and nothing afterward, so the fastest safe setup is also the one with the smallest standing footprint. No standing role, no password baked into the agent image, no live path sitting open at 3am. The grant opens when the agent asks, closes when the task ends, and every statement in between is recorded

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.

Want an AI agent querying Snowflake in the next few minutes without leaving a permanent credential behind? This is the short path. Just-in-time access means the agent gets a connection for the task and nothing afterward, so the fastest safe setup is also the one with the smallest standing footprint.

No standing role, no password baked into the agent image, no live path sitting open at 3am. The grant opens when the agent asks, closes when the task ends, and every statement in between is recorded. Here is the minimal first connection.

Connect Snowflake to the gateway

hoop.dev is an open-source Layer 7 access gateway. Register Snowflake as a connection once. From then on, engineers and AI agents query real Snowflake data through hoop.dev, and the gateway brokers access as the session principal so the agent holds no permanent warehouse credential.

You give the gateway the warehouse host, the role to broker with, and the credential one time. After that the connection is a named target your agents request by name, never by holding the secret. The credential lives at the gateway, not in the agent image, not in an environment variable, not in a config file that follows the agent around. That separation is what lets access be granted and revoked per task instead of per deploy.

Make the agent's grant just-in-time

Configure the agent's access as time-bound rather than permanent. Access opens when the agent requests a session and closes when the session ends. That single setting is what turns a standing grant into just-in-time access.

  1. Authenticate the agent to the gateway through your identity provider over the MCP server.
  2. Scope the session to one schema, the one the task needs.
  3. Run the query inside the session.
  4. Let the session close. The path is gone until the next request.

Run the first query

SELECT order_id, status FROM ops.orders WHERE status = 'pending';

The agent gets its results, the session is recorded at the gateway, and when it ends there is no live Snowflake connection left in the agent's environment. That is the minimal loop: request, query, close.

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.

What makes this fast rather than fiddly is that the agent never handles the warehouse credential. It asks the gateway for a session against a named connection, the gateway opens the path with the credential it already holds, and the agent runs its query through that path. There is no key to provision, no secret to rotate in the agent, and no Snowflake user to create per agent. The first connection is mostly registering the warehouse once; every session after that is a request the agent makes by name. Just-in-time access stays fast precisely because the slow parts, credential handling and scoping, happen at the gateway instead of in each agent.

Confirm it closed

Try the same query again without requesting a new session. It should fail. That failure is just-in-time access doing its job: the grant did not survive the task. Open the session record to see the open, the statement, and the close attributed to the agent. If the second query had succeeded, you would still be running standing access, and the test would have told you so before an incident did.

Pitfalls on the first try

  • Leaving the session window wide open. A long window is standing access wearing a costume. Keep it tight.
  • Skipping approval on writes. Route destructive statements through a review step even on the first connection.
  • Reusing one identity for several agents. Give each agent its own so the record stays clean.

See why just-in-time access fits autonomous agents and the getting-started guide for the full first run.

FAQ

How fast is the first connection?

Registering the Snowflake connection and running a scoped session is a few minutes once your identity provider is wired to the gateway.

Does the agent keep any credential after the session?

No. The gateway holds the warehouse credential and the agent's access closes with the session, so nothing standing remains.

Can I widen access later?

Yes. Adjust the policy per identity. Start minimal and grant more only when a task needs it.

hoop.dev is open source. Grab the code and run your first just-in-time Snowflake session 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