All posts

Non-human identity for AI agents on Snowflake

Teams get human access to Snowflake right. SSO, group-based roles, an audit row per analyst. Then an AI agent ships with a shared service account and a password in an environment variable, and every control they built for people quietly does not apply to the agent. The skipped control is non-human identity, and it is the one that matters most for the caller that never sleeps. It gets skipped because agents feel like infrastructure, not users. But an agent that queries production data is exactly

Free White Paper

Non-Human Identity Management + 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.

Teams get human access to Snowflake right. SSO, group-based roles, an audit row per analyst. Then an AI agent ships with a shared service account and a password in an environment variable, and every control they built for people quietly does not apply to the agent. The skipped control is non-human identity, and it is the one that matters most for the caller that never sleeps.

It gets skipped because agents feel like infrastructure, not users. But an agent that queries production data is exactly a user, just one that does not forget it has access and does not stop to think before running a query. It needs the same identity discipline you already give people.

The control teams skip

The missing piece is a distinct, scoped, attributed identity per agent. Human access has it by default through your identity provider. Agents tend to get a single shared login, which collapses three controls at once: you cannot scope per agent, you cannot attribute a query to one agent, and you cannot revoke one agent without breaking the rest. A non-human identity restores all three.

The reason it gets skipped is usually onboarding pressure. The human path was built once, deliberately, by an identity team. The agent shows up later, owned by an application team that just needs it talking to Snowflake by Friday. A shared service account is the fastest way to get there, and it works, so it ships. The gap is invisible until an agent does something surprising and you discover the audit trail cannot tell it apart from the other four agents on the same login.

Closing the gap does not mean rebuilding your identity stack. It means routing the agent through the same identity boundary your people already use, so the agent inherits per-principal scope, attribution, and revocation instead of opting out of them by default.

Continue reading? Get the full guide.

Non-Human Identity Management + AI Human-in-the-Loop Oversight: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Add it 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. The gateway is where the agent's identity is verified, scoped, and recorded, so the control you skipped gets added at the boundary rather than inside the agent.

  1. Register the Snowflake connection in hoop.dev. The gateway holds the warehouse credential and brokers access as the session principal.
  2. Give each agent its own non-human identity, authenticated to the gateway through your identity provider over the MCP server.
  3. Map each identity to a least-scope Snowflake role: only the warehouses and schemas that agent's task needs.
  4. Record every statement against that identity so attribution survives.

Verify the control is really there

Run a query as one agent and confirm the session record names that specific identity, not a shared account. Then revoke that one identity and confirm the other agents keep working. If a single agent can be scoped, attributed, and revoked on its own, the non-human identity control is in place. If revoking one breaks all of them, you are still on a shared login.

Pitfalls

  • One service account for the whole fleet. It is the default and it defeats attribution. Issue one identity per agent.
  • A password in the agent environment. Let the gateway hold the warehouse credential so the secret never ships with the agent.
  • Reusing a human's identity for an agent. The agent's behavior then hides inside a person's audit trail.

See how identity-aware access applies to agents and the getting-started guide to configure the connection.

FAQ

Why is a non-human identity different from a service account?

A shared service account is one credential for many callers. A non-human identity is distinct per agent, so it can be scoped, attributed, and revoked individually.

Does each agent need its own Snowflake user?

The gateway brokers access as the session principal and maps each agent identity to a scoped role, so attribution and scope hold without a sprawl of raw warehouse logins.

Can I revoke one agent without downtime for the rest?

Yes. With per-agent identities you revoke one at the gateway and the others keep running.

hoop.dev is open source. Read the code and give every agent a real non-human identity 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