One of the biggest blockers to building agents is getting the data 'agent-ready'. Teams spend months building pipelines, wiring up sources, cleaning data, and centralizing it - before an agent can even ask its first question.
Pylar now does this out of the box.
We re source-agnostic. Whether your data lives across multiple databases and warehouses (Supabase, Snowflake, MySQL, etc.), you can connect one or many instantly, no re-architecture required.
If you don't have a warehouse yet, we ve got you covered. Pylar ships with 100+ built-in integrations across marketing tools, CRMs, support platforms, product databases, and billing systems. Data comes in cleaned, transformed, and centralized, ready for agents to work with.
Next up is agent views - once you've connected to your sources, you can write SQL across or within to create precise, sanitized, sandboxed views purpose built for specific agents.
Agents don t roam your databases arbitrarily. You deterministically scope exactly what fields they can access, so they do their job well, without hallucinating or giving you different answers for the same/similar questions.
Give it a try and let me know what you think!
Pylar
👋 Hey everyone, I'm Hoshang, Co-founder of Pylar.
Super excited to finally share what we’ve been building.
Agents today are great at reading docs, invoices, websites, transcripts -
but the moment you want them touching structured systems where sensitive customer data is stored e.g Snowflake, Postgres, CRMs… things get tricky.
We kept hearing the same two blockers over and over:
Agents may over-query and silently spike warehouse bills
Agents are at a risk of leaking sensitive data (PII, financials, customer history) because access isn’t properly scoped
And right now, teams have two options:
- Off-the-shelf MCP servers : 18,000 exist, ~10% are malicious, and most are exploitable or too generic for production.
- Custom API wrappers : months of engineering bandwidth used up in building endpoints, policies, and governance… all brittle, fragmented, and hard to audit.
This forces companies into a painful choice: lock agents down so much they become useless, or open things up and risk a security incident.
Traditional database ACLs weren’t designed for autonomous systems. Custom APIs are hard to build, govern and control for agent level interactions.
Pylar exists to fix this. It’s a governed access layer between your agents and your entire data stack.
You connect your datasources → define sandboxed SQL views → turn them into MCP tools → ship them to any agent builder… all from one control plane, with full observability.
What you get out of the box:
Agent-specific sandboxed views (never raw DB access)
Enforced permissions & guardrails
Automatic breach containment + audit logs
Publish to any agent builder (n8n, Cursor, Claude, LangGraph, etc.) via a single secure link
We’re already working with some fantastic data, platform, and security teams - everything from internal analytics copilots to customer-facing AI features wired directly into production data.
If you’re exploring structured-data access for agents, I’d love to hear your thoughts, help you build your use case or just share best practices on what we've been seeing with our customers. You can book a call with me here if you'd like.
Thanks for checking us out — means a lot. 🚀
- Hoshang
Co-founder, Pylar
@hoshang_m Love that you’re tackling agent over‑querying, feels like a pain everyone’s quietly dealing with right now.
Pylar
@masump Thanks for the support! And yes, as companies go deeper into agent use-cases, this is where most projects get stuck. Agents operate at machine scale, so one bad query can have a much bigger impact than a human ever would.
Claude-Mem
@masump @hoshang_m my solution for over querying is strict progressive disclosure rules in my search skill (for Claude-Mem)
Search and get indexed list, select data to read, contextualize data by getting a timeline of activity at those observation points, then read summary level information.
But that’s structured and requires thought in the way the data is created and stored vs. this tool which lets you access anything from any source! Which is really really cool that it does that :)
How does it handle over querying and context window limits?
Visla
@hoshang_m Congrats! Great launch!
Pylar
@hoshang_mReally interesting problem space — and honestly, one that’s becoming more pressing as teams try to push agents beyond simple document Q&A.
You nailed the two blockers perfectly: cost explosions from uncontrolled queries and the real security risk of giving agents broad access to sensitive systems. Both are major reasons adoption stalls in enterprise environments.
I like that Pylar sits between “generic MCP servers that aren’t production-ready” and “months of building brittle custom wrappers.” That gap is very real.
Excited to see how you handle policy enforcement and auditability as things evolve. Congrats on the launch — feels like the right product at the right time.
This is the exact missing layer for “agents touching real data.” Love the sandboxed views → MCP tools approach. Quick Q: do you support per-agent budgets/rate limits + alerts, and is it BYO LLM across Cursor/LangGraph/n8n?
Pylar
@vouchy Thanks for the question, Van! Instances of agents leaking sensitive data is on the rise, recently Salesforce had a security incident where their ai agents accidentally leaked sensitive crm data through through their agentforce powered web-to-lead form. attackers injected a malicious prompt on website forms to make the AI share internal data with outside domains.
basically, hiding malicious instructions inside normal text. the ai read it… and pulled private data it had permission to see. I did a deep dive here, you might find this interesting - https://www.pylar.ai/blog/forcedleak-salesforce-agentforce-vulnerability-deep-dive
Zivy
Congrats on the launch @hoshang_m this solves a serious gap for teams working with sensitive, structured data. I’m curious how Pylar handles evolving permission needs over time. If schema or data-access policies change, can sandboxes and guardrails adapt without teams rebuilding the entire setup?
Pylar
@harkirat_singh3777 Thanks for your support! The sandboxed view is the “source of truth.” If your schema changes or your data-access rules shift, you just update the view in Pylar - the agents automatically start using the new version. No redeploying, no rebuilding tools, no touching the agent builder again.
We basically treat it like a control plane: you tweak the view or the policy once, and every connected agent adapts instantly.
CodeBanana
@vishalbajaj Great product! All the best for your launch 🎉
Pylar
Airbook AI
@zethleezd appreciate your support Zeth
@hoshang_m Congratulations. And happy product launch.
Pylar
@huisong_li Thank you! 🙌🏻
Airbook AI
@huisong_li thank you for your support Huisong!
Incredible
Awesome! Is it possible to have an agent that sync my Notion page with notes of different customers to my CRM system Attio?