Let every person and every agent know your company as well as your best people do.
Marmot is the knowledgehouse for your company. It knows what your data means, governs who may use it and runs every query your people and agents make, checked and recorded.
What was revenue last week, and can I trust the number?
- Searched the catalogorders_daily in Snowflake, owned by Analytics Engineering
- Read its lineageBuilt by dbt from shop.public.orders
- Checked its accesssvc-finance may read orders_daily
- Ran a query on orders_daily7 rows in 412 ms, on record
- Asked for customer emailsRefused: no grant on customers.email
Revenue last week was £413,180 across 8,615 orders, from orders_daily, the table finance reports from.
“Marmot brings metadata, ownership and lineage into one searchable catalog, making data products easier to discover and understand.”
Manuel Jáñez GarcíaSenior Specialist of Data Governance ServicesReads metadata from the tools you already run, with 70+ plugins
PostgreSQL BigQuery Kafka dbt Airflow S3 ClickHouse Trino MongoDB - and dozens more
Built in the open by engineers from
HashiCorp, Adidas, Just Eat Takeaway.com and Traefik
More than 600 stars on GitHubAgents are only as good as what they know. Marmot gives them what your company knows, under your rules.
In Deloitte’s 2026 survey of 3,235 senior leaders, 74% of companies planned to deploy AI agents within two years, but only 21% had a mature model for governing them.
How each team works with Marmot
Engineers see what a change breaks before they merge it
Lineage follows data from source tables through every model to the dashboards that use it.
- Upstream and downstream, across tools
- From plugins and OpenLineage runs
- The dashboards a change would break
The full-screen lineage of orders_daily follows orders from the PostgreSQL table through the Airflow load and the dbt models to the Revenue overview dashboard. An edge declared by the dbt-analytics pipeline and a Spark job reported through OpenLineage open in the blade, then the two dashboards downstream of orders_daily and who to ask about them. Sample data.
Why a database password isn’t enough
The same finance agent, looking for last week’s revenue in the same six tables.
- Without MarmotWith only a read-only password, it guesses its way through four look-alike tables and reads customer emails on the way.
- With MarmotThe catalog points it to orders_daily, the table finance reports from, and its query for customer emails is refused.
Two maps of the same tables. Without Marmot, the agent guesses between look-alike order tables with a database password, and ends up reading customer emails. With Marmot, it takes one logged route to the orders_daily table finance reports from, and its query on the customer table is refused.
Ready for your security review. Your data stays where it lives.
How Marmot Cloud keeps your knowledge safeYour own instance
A dedicated database and encryption key for every customer.
Your identity provider
Single sign-on for people, a service account for every agent.
No stored passwords
Credentials stay in your secret store, or aren't needed at all.
Rows are never stored
Results go straight to whoever asked. Marmot keeps the record.
Questions
Anything else, email support@marmotdata.io.
A read-only user can read every table it has been granted, personal data included, and nothing ties its queries back to the question the agent was asked. It also tells the agent nothing about which orders table finance reports from. Through Marmot the agent picks from the catalog, each query is checked against what that agent may read, and every query is logged with who ran it and whether it was allowed.
A catalog tells people what exists. Marmot also serves that context to agents over MCP and runs their queries, so the system that knows a table holds personal data is the same one that decides who may query it. That is why we call Marmot a knowledgehouse for people and agents, with the catalog as one part of it.
Only what you grant them. People sign in as themselves and agents connect with their own service accounts, and Marmot checks every query against that identity’s roles before it reaches your database. Anything they may not read is refused, and every attempt is recorded.
No. Plugins read metadata from the systems you already run, and queries go to those systems in place. Your data stays where it is.
It is the same project. Cloud instances run the version we maintain for customers: fixes land there first, and many flow back into the MIT-licensed releases on GitHub. Nothing locks you in, and you can export your catalog and self-host the open source edition at any time.
Plugins send schemas, ownership, descriptions, lineage and run status. Rows reach your instance only when someone runs a query through a plugin that supports queries, and each query is checked against their roles and recorded in the query audit.
No. Register where the secret lives in Google Secret Manager, AWS Secrets Manager, Azure Key Vault or HashiCorp Vault, and your instance reads it when a run starts, over a five-minute OpenID Connect token your cloud trusts. The run record keeps a mask.
Get started with Marmot
Start free on Marmot Cloud, or talk to us about Enterprise to run it on your terms.
Marmot Cloud
We run it for you, with access control and an audit of every query.
- Access control per table, product and term
- Governed queries, with an audit log of every one
- Upgrades, nightly backups and support from the team
Free to start with no card, and unlimited users on every plan.
Enterprise
For large organisations with their own security and compliance needs.
- A per-agent audit trail, exported to your SIEM
- Data residency, VPC peering or your own infrastructure
- A named contact, a shared Slack channel and an SLA
Want to try it on your own first? The open source edition is MIT-licensed. View on GitHub