AI
Too Many Tools Break the Agent
The monolith agent demo failed. It accessed benefit-cost analysis, compensation analysis, and SQL tools but could not combine them correctly. The agent took over two minutes, then denied it had the data. The core problem: more tools make the agent less predictable. Each LLM call and each tool call adds stochasticity. Stacking them makes the system unreliable. More tools bloat the context window, increasing token cost and response time. A large tool set also makes security harder because every tool shares the same MCP server.
Agent as a First-Class Identity with Layered RBAC
Snowflake’s defense makes the agent a first-class entity with its own identity and security policies. This identity is layered with the user’s access controls. The agent spec defines which MCP servers and native tools it can use. The MCP server spec defines which tools are available. RBAC is enforced at four layers: agent, server, tool, and data. For example, an HR agent connects to three servers: employee info (Workday), benefits (Glean), and compensation (ADP). Access to compensation tools is restricted to HR admins only. These boundaries are independent and auditable. A coding agent can propose SQL grants for the security admin to approve.
Demo: Specialized Agent Delivers Precision
Josh switched to an HR analyst role and opened the HR assistant agent. That agent had only HR tools: benefit cost analysis, enrollment stats, and compensation lookup. He asked the same question the monolith agent failed on. The HR agent called its first tool immediately, explored the org chart, executed SQL, and streamed results. It returned a precise benefits cost breakdown by department. Then Josh switched to a finance role. The finance agent could not answer the HR question because its tools and data are scoped to finance. The demo showed how specialization reduces hallucinations and token cost while improving debuggability and auditability.
Q&A
How do you handle user-level access when everyone has the same role? Roles are the granularity. Interns get a different role with fewer privileges. ▶ Watch (19:02)
Where is tool filtering applied: on the agent side or the MCP server? At every layer. The agent filters native tools. The MCP server lists dynamic tools based on the user’s privileges, even within the same server. ▶ Watch (19:59)
If an agent already has access to tools, why do you also need an MCP server? Agents can use native tools directly. MCP servers allow third-party agents to connect, and Snowflake agents can also use external MCP servers as clients. ▶ Watch (21:09)
Notable Quotes
We’ve made agent a first-class entity. Josh Reini · ▶ Watch (4:33)
Prompts do not enforce access. They do not audit. They do not restrict anything. Reetika Roy · ▶ Watch (5:56)
The defense is a combination um identities plus policies at both the agent and the user level, and that’s how we do defense in depth. Reetika Roy · ▶ Watch (5:37)
Key Takeaways
- Specializing MCP servers and agents by domain cuts token cost and hallucination rates.
- Four-layer RBAC (agent, server, tool, data) contains the blast radius of prompt injections.
- Coding agents can generate SQL grants, reducing administrative overhead for security teams.
About the Speaker(s)
Josh Reini is a developer advocate for Snowflake, previously at TruEra (recently acquired by Snowflake). He is also a maintainer of open-source TruLens, a library to systematically track and evaluate LLM based applications. Josh has delivered tech talks and workshops to thousands of developers at events including PyData, Global AI Conference, NYC Dev Day, LLMs and the Generative AI Revolution, AI developer meetups including AI Camp and Unstructured SF Meetup.
Reetika Roy is a staff software engineer at Snowflake, leading the agent platform team.