The 5 layers of safely connecting agents to your databases:
Most AI agents need access to structured data (CRMs, databases, warehouses), but giving them database access is a security nightmare. Here's a layered architecture that addresses this:
Layer 1: Data Sources
Your raw data repositories (Salesforce, PostgreSQL, Snowflake, etc.). Traditional ETL/ELT approaches to clean and transform it needs to be done here.
Layer 2: Agent Views (The Critical Boundary)
Materialized SQL views that are sandboxed from the source acting as controlled windows for LLMs to access your data. You know what data the agent needs to perform it's task. You can define exactly the columns agents can access (for example, removing PII columns, financial data or conflicting fields that may confuse the LLM)
These views:
• Join data across multiple sources
• Filter columns and rows
• Apply rules/logic
Agents can ONLY access data through these views. They can be tightly scoped at first and you can always optimize it's scope to help the agent get what's necessary to do it's job.
Layer 3: MCP Tool Interface
Model Context Protocol (MCP) tools built on top of agent data views. Each tool includes:
• Function name and description (helps LLM select correctly)
• Parameter validation i.e required inputs (e.g customer_id is required)
• Policy checks (e.g user A should never be able to query user B's data)
Layer 4: AI Agent Layer
Your LLM-powered agent (LangGraph, Cursor, n8n, etc.) that:
• Interprets user queries
• Selects appropriate MCP tools
• Synthesizes natural language responses
Layer 5: User Interface
End users asking questions and receiving answers (e.g via AI chatbots)
The Flow:
User query → Agent selects MCP tool → Policy validation → Query executes against sandboxed view → Data flows back → Agent responds
Agents must never touch raw databases - the agent view layer is the single point of control, with every query logged for complete observability into what data was accessed, by whom, and when.
This architecture enables AI agents to work with your data while maintaining:
• Complete security and access control
• Reduces LLMs from hallucinating
• Agent views acts as the single control and command plane for agent-data interaction
• Compliance-ready audit trails
If you're building agents that touch sensitive customer information stored across your data stack, Pylar can help!
We’re putting together a small Slack group for ops, data and devs who are hands-on building internal AI agents — people experimenting with things like n8n, LangGraph, Zapier, Make, OpenAI agents, Agno, or custom setups.
The goal’s to share what’s actually working: use cases, architecture ideas, prompt design, and maybe a few fails too.
If you’re building agents for analytics, internal ops, or workflow automation inside your company — would love to have you join.
@auslegung - Do you let agents touch internal structured data stored in a warehouse (for example)? If so, how do you do that today?
Would love to have your thoughts on this - https://youtu.be/98PZMcYQKDI
yes.. that makes a lot of sense to me. I'm almost imagining building an evals layer to show which views were useful (or not) for the agent to do it's thing.. so i'd know whether to increase/decrease the scope of the views + further tuning the custom mcp layers. thoughts on how you'd imagine doing this?
that's a good baseline..db rbac locks scope, but i guess not behavior. inside that schema the agent can still fire off wide scans, weird joins, or grab way more rows than needed.. Ai can write apt queries for sure but there's always a dependancy on the kinda prompt it gets. you may also lose semantic clarity and telemetry .. no way to know if it actually pulled the right data. how would you enforce “only these lookups” or “only these joins” with just db perms? is there a way?
We've been working on Airbook, a tool that helps teams turn their data notebooks into fully functional CDPs—instantly.
Most companies either struggle with fragmented customer data or spend months engineering a homegrown solution.
We thought: what if you could just use the data notebooks you already have?
With Airbook, you can:
Connect to your existing data stack (dbt, BigQuery, Snowflake, Salesforce etc.)
Define customer identities, audiences and segments dynamically
Sync insights to downstream tools to trigger growth campaigns—without custom pipelines
Thanks Peter! You're 100% right. At the moment, we're built to handle reasonably large volumes of data and making it super fast is something we're definitely taking care off.
We've been working on something exciting and would love your feedback. We just built a No-Code Query Builder that allows data savvy business teams to join data across 150+ sources—everything from business apps like HubSpot, Salesforce, Zendesk to databases like Snowflake, PostgreSQL, Redshift—without needing SQL.
The idea is to make data accessible to anyone, regardless of their technical skills.
It’s designed for people who want insights but don’t have the time (or the SQL chops) to dig through multiple sources manually.
Here’s what it can do:
-In a few clicks connect to your data across 150+ tools and databases
-Do joins across Hubspot, SFDC, Stripe, Amplitude and more
-Do aggregates, calculated fields and conditional filters
I'd love to know:
What are your thoughts on a tool like this?
What can we do to improve the design?
Let me know if you'd like to try it out—I’d be happy to share more details!
Most AI agents need access to structured data (CRMs, databases, warehouses), but giving them database access is a security nightmare. Here's a layered architecture that addresses this:
Layer 1: Data Sources Your raw data repositories (Salesforce, PostgreSQL, Snowflake, etc.). Traditional ETL/ELT approaches to clean and transform it needs to be done here.
Layer 2: Agent Views (The Critical Boundary) Materialized SQL views that are sandboxed from the source acting as controlled windows for LLMs to access your data. You know what data the agent needs to perform it's task. You can define exactly the columns agents can access (for example, removing PII columns, financial data or conflicting fields that may confuse the LLM)
These views: • Join data across multiple sources • Filter columns and rows • Apply rules/logic
Agents can ONLY access data through these views. They can be tightly scoped at first and you can always optimize it's scope to help the agent get what's necessary to do it's job.
Layer 3: MCP Tool Interface Model Context Protocol (MCP) tools built on top of agent data views. Each tool includes: • Function name and description (helps LLM select correctly) • Parameter validation i.e required inputs (e.g customer_id is required) • Policy checks (e.g user A should never be able to query user B's data)
Layer 4: AI Agent Layer Your LLM-powered agent (LangGraph, Cursor, n8n, etc.) that: • Interprets user queries • Selects appropriate MCP tools • Synthesizes natural language responses
Layer 5: User Interface End users asking questions and receiving answers (e.g via AI chatbots)
The Flow: User query → Agent selects MCP tool → Policy validation → Query executes against sandboxed view → Data flows back → Agent responds
Agents must never touch raw databases - the agent view layer is the single point of control, with every query logged for complete observability into what data was accessed, by whom, and when.
This architecture enables AI agents to work with your data while maintaining: • Complete security and access control • Reduces LLMs from hallucinating • Agent views acts as the single control and command plane for agent-data interaction • Compliance-ready audit trails
If you're building agents that touch sensitive customer information stored across your data stack, Pylar can help!