An AI agent does not log in the way a person does. It holds a key, opens a connection, and runs queries against your warehouse on its own schedule. The moment that key is a shared Snowflake login, you have lost the ability to say which agent did what. That is the gap a non-human identity closes.
Start from the requirement, not the tool. If an agent queries Snowflake, the system that authorizes and records the query must sit outside the agent process, because anything the agent runs in can be reconfigured by the agent. The identity an agent presents has to be issued, scoped, and attributed by something it does not control.
What non-human identity means for Snowflake
A human gets a username, an SSO group, and an audit row. An agent needs the same three things, expressed as machine credentials: a distinct principal per agent, a role that grants only the warehouses and schemas the task needs, and a log line that ties every statement back to that principal. A non-human identity is the agent's version of all three, governed centrally rather than baked into a config file the agent ships with.
Snowflake has its own role model: USE ROLE, grants on databases and schemas, and warehouse usage. The problem is not that Snowflake lacks roles. It is that agents tend to share one service account and one password, so the role is correct but the attribution is gone.
Snowflake also offers key-pair authentication and OAuth for programmatic users, which is better than a shared password but still leaves the identity question open. A key pair tells the warehouse a valid key signed the request. It does not tell you which of your five agents made it, whether the access should still be live, or what the agent ran once it was in. The key authenticates a connection. It does not give you a governed, attributed, revocable identity per agent. Those are different problems, and the second is the one that bites during an incident.
This is why the identity has to be issued and enforced at a layer above the warehouse. Snowflake roles scope what a principal can touch once it is connected. A non-human identity has to decide, per agent and per task, whether that principal should be connecting at all, and leave a record either way.
Put the access boundary in front of the warehouse
hoop.dev is an open-source Layer 7 access gateway. It proxies the connection to Snowflake through an agent that runs inside your network, and engineers and AI agents query real Snowflake data through hoop.dev rather than connecting straight to the warehouse. Authorization, recording, and masking run on that proxied connection, where the agent cannot turn them off.
- Register the Snowflake connection in hoop.dev with its credentials. hoop.dev holds the warehouse credential and brokers access as the session principal, so the agent never carries a standing Snowflake password.
- Authenticate the agent to the gateway through your identity provider over the built-in MCP server. The agent presents a non-human identity that maps to a scoped role, not a shared login.
- Grant that identity only the databases and schemas the task requires. Read-only on the analytics schema is a different identity from one that can write to a staging table.
- Run a query. hoop.dev attributes it to the agent identity, records the statement, and applies masking before results return.
Verify the attribution
Issue a SELECT through the agent, then open the session record. You should see the agent principal, the exact statement, and the timestamp, recorded at the gateway rather than inside the agent runtime. Rotate the agent's gateway credential and confirm the old one stops working without touching the Snowflake account itself. That separation is the whole point: the identity lives where the agent cannot edit it.
Common pitfalls
- Reusing one service account across several agents. You get a role but no per-agent attribution. Issue a distinct identity per agent.
- Embedding the warehouse password in the agent image. If the gateway holds the credential, a leaked image leaks nothing usable.
- Granting
ACCOUNTADMIN "to get unblocked." Scope the role to the task and widen it only with an explicit grant.
For the broader pattern across agents and warehouses, see how hoop.dev approaches identity-aware access, and the getting-started guide for the first connection.
FAQ
Does the agent ever hold the Snowflake password?
No. hoop.dev holds the connection credential and brokers access as the session principal. The agent authenticates to the gateway with its own non-human identity, so the warehouse secret never ships inside the agent.
Can two agents share one identity?
They can, but you lose per-agent attribution. Issue one identity per agent so every query in the session record points at a single principal.
Is this only for AI agents?
No. The same model covers service accounts and scheduled jobs. Any non-human caller gets a scoped, attributed identity instead of a shared login.
hoop.dev is open source. Read the gateway code, wire up your first Snowflake connection, and give every agent a real identity at github.com/hoophq/hoop.
