Hoshang07

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?

fixed a few things, here's a new link - https://claude.ai/public/artifacts/037456ea-caa4-420f-90c0-d...

(the old link still works too)

Nice work!

Hey HN!

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

We'd love to hear your thoughts!

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.