# dhino.io full content Markdown version of every page on https://dhino.io, generated at build time. Per-page markdown: append .md to any path (drop the trailing slash), e.g. https://dhino.io/product/fetch.md --- title: dhino - Enterprise data access and governance platform description: dhino sits between your enterprise data and the people, systems, and AI that need it. Simplified access. Built-in governance. One platform for all consumers. url: https://dhino.io/ --- # Make complex data work for every user and every AI. dhino sits between your data and its consumers, making access simple, secure, and consistent everywhere. ## Your data is trapped between those who have it and those who need it Business teams wait weeks for reports. LLMs and agents hallucinate because they lack business context. Dashboards show different numbers for the same metric. Every new integration becomes a custom project. The root cause: there is no shared, governed layer between your data and the things that want to use it. People, systems, and AI all need access. Without that layer, every consumer reinvents access. Definitions drift. Security becomes an afterthought. And your data team spends its time fighting fires instead of building anything. ## One layer between data and everything that needs it dhino defines your enterprise data knowledge once and enforces it everywhere, for people, systems, and AI. Your data Dataverse, SQL, APIs dhino Integration · Context · Control AI & apps Copilot, Power Apps ### Simplified data access No SQL. No schema knowledge. Business users get the data they need through pre-defined templates and natural language, without waiting on IT. ### Built-in governance Fine-grained access control, compliance by default, and full audit trails. Security is the foundation, not an afterthought. ### Consistent answers everywhere Humans, systems, and AI all use the same governed layer. Same definitions, same rules, same results. No more conflicting numbers. [See the platform](https://dhino.io/product) Built for the Microsoft ecosystem Dataverse Copilot Power Apps Power BI > "There's a clear and growing need for a Dataverse connector that's powerful yet simple enough for citizen developers and Copilot alike. dhino's solution hits that sweet spot." > > Christian Mainka > > Sr. Partner Solution Architect | Business Applications & AI, Microsoft ## Let's crack your data challenges. Tell us about your data challenges and we will show you how dhino fits. ## Go deeper Articles and definitions for the concepts behind governed data access. [Blog ### Why AI gets enterprise data wrong Why AI fails on structured data and what trustworthy data access looks like. ](https://dhino.io/blog/why-ai-gets-enterprise-data-wrong)[Blog ### Template-based data access vs. text-to-SQL Two approaches to AI data access compared on accuracy, governance, and enterprise readiness. ](https://dhino.io/blog/template-based-vs-text-to-sql)[Glossary ### What is a semantic data layer? How an abstraction layer translates database complexity into business terms. ](https://dhino.io/glossary/semantic-data-layer) [All articles](https://dhino.io/blog) [Glossary](https://dhino.io/glossary) ## Common questions What is dhino? dhino is a data access and governance platform that sits between enterprise data and the people, systems, and AI that need it. Instead of every consumer writing queries or reinventing security rules, dhino defines business logic once and enforces it everywhere. Who is dhino for? Enterprise teams tired of waiting on IT for data, IT teams tired of answering the same ad-hoc requests, and organizations that want AI tools like Copilot to work reliably on their own data. dhino is built for the Microsoft ecosystem first (Dataverse, Power Platform, Azure, Copilot). How is dhino different from text-to-SQL? Text-to-SQL generates a query at runtime and hopes it is right. dhino runs pre-defined templates: deterministic logic, parameterized, tested. The same question returns the same answer every time, from every consumer, with governance built in. Is dhino a BI solution? No. BI tools like Microsoft Fabric, Power BI, or Tableau are where people explore and visualize data. dhino is a governed access layer that sits in front of your data and serves it wherever it needs to go: powering a dashboard, sending scheduled reports, feeding a marketing segmentation, triggering an integration, or answering a Copilot query. A BI tool can be one of dhino's consumers. dhino is complementary to Fabric, not a replacement. What data sources does dhino work with? dhino is Microsoft-first, with deep support for Dataverse, Azure SQL, and the Power Platform. Beyond Microsoft, anything with an API can be connected, so dhino can pull from external systems and expose them through the same governed templates as your Microsoft data. How does dhino keep data secure? Every request runs through a pre-defined template. Consumers never touch the raw database. Field-level access controls, role-based permissions, and full audit trails apply automatically to every caller, human or AI. Hosted on Microsoft Azure. --- title: About dhino - Enterprise data access experts description: Meet the team behind dhino. Deep Microsoft expertise, a clear vision for reliable data access and governance, and a commitment to solving real enterprise problems. url: https://dhino.io/about/ --- # Why dhino exists We saw AI and business users failing on enterprise data. Not because the models were bad or the effort was missing. Because data without context is worthless. ## Our story We started dhino because we kept seeing the same problem: business users waited weeks for data. AI hallucinated without context. Every integration became a custom project. The root cause was always the same: no governed layer between enterprise data and the people, systems, and AI that need it. Our vision is a future where accessing enterprise data is simple, governed, and reliable for everyone. We achieved this by separating understanding from execution. dhino defines your business logic once and enforces it everywhere. Business users get answers without waiting on IT. AI gets context without guessing. And everyone gets results they can trust. ## The team We bring deep expertise in the Microsoft ecosystem. Power Platform, Dataverse, Azure, Copilot. We have built enterprise solutions, led data teams, and seen firsthand what works and what does not. Now we are applying that experience to solve enterprise data access and governance. ![Mats Necker](https://dhino.io/_astro/about-team-mats.DoK1ptGG.webp) ### Mats Necker Co-Founder, Product 15 years experience as developer, consultant, and entrepreneur. Microsoft MVP from 2022 to 2026. 🦕 Favorite dinosaur: Brontosaurus [LinkedIn](https://www.linkedin.com/in/matsnecker/) ![Tim Thedens](https://dhino.io/_astro/about-team-tim.0QkyZoEQ.webp) ### Tim Thedens Co-Founder, GTM 12 years in B2B Tech Marketing. Bringing enterprise software to the teams that need it. 🦕 Favorite dinosaur: Dilophosaurus [LinkedIn](https://www.linkedin.com/in/tim-thedens/) ## Meet us in person [ ### Nordic Summit ](https://nordicsummit.info/)Speaking Sep 21-22, 2026 Billund, Denmark · Billund [ ### Scottish Summit 2026 ](https://scottishsummit.com/)Speaking Oct 2-3, 2026 Edinburgh, Scotland · Murrayfield Stadium [ ### ESPC Microsoft 365 and AI Conference 2026 ](https://espc.tech/conference/espc-2026/)Speaking Nov 30 - Dec 3, 2026 Amsterdam, Netherlands · RAI Amsterdam ## Frequently asked questions about dhino Who is behind dhino? dhino was founded by Mats Necker (Co-Founder, Product) and Tim Thedens (Co-Founder, GTM). Mats has 15 years as a developer, consultant, and entrepreneur in the Microsoft ecosystem and held the Microsoft MVP award for five consecutive years, from 2022 to 2026. Tim has 12 years in B2B tech marketing, focused on bringing enterprise software to the teams that need it. Where is dhino based? Hamburg, Germany. dhino GmbH is registered at Eschelsweg 4, 22767 Hamburg. When was dhino founded? dhino GmbH was incorporated in 2026, and that is when the dhino brand launched. The platform itself is two years older. Mats Necker built it and ran it in production with enterprise customers during his freelance consulting work before incorporating the company. The name is new; the product is mature. What kind of company is dhino? A B2B software company. dhino sells a data access and governance platform delivered as multi-tenant SaaS on Microsoft Azure. Customers are enterprises that need governed, reliable data access for people, systems, and AI. How does dhino make money? dhino is a subscription platform sold to enterprises. Engagements typically include the SaaS subscription plus optional onboarding services such as template authoring and agent integration. What is dhino's relationship to Microsoft? dhino is built for the Microsoft ecosystem first. The platform runs on Microsoft Azure and integrates deeply with Power Platform, Dataverse, and Copilot. Co-founder Mats Necker was a Microsoft MVP from 2022 to 2026. ## Get in touch ### Contact Got a data access problem and want to talk it through? Reach out. [hello@dhino.io](mailto:hello@dhino.io) ### Follow us Follow along for product updates and plain-talk takes on enterprise data. [](https://www.linkedin.com/company/dhino/) --- title: Enterprise data and AI blog | dhino description: Articles on AI data accuracy, Microsoft Dataverse, governed data access, and template-based architecture. Written for IT and data teams in the Microsoft ecosystem. url: https://dhino.io/blog/ --- Blog # Enterprise data and AI insights Practical articles on AI data accuracy, Microsoft Dataverse, governed data access, and template-based architecture. Written for IT professionals, data teams, and enterprise architects in the Microsoft ecosystem. ## Things that seem obvious in hindsight [ January 22, 2026 ### What is Dataverse and why does it matter for enterprise data? Microsoft Dataverse is the data backbone for Power Platform, Dynamics 365, and Copilot. What it does, where it fits, and how to get data out of it. ](https://dhino.io/blog/what-is-dataverse)[ January 14, 2026 ### Why AI gets enterprise data wrong 45% of enterprises cite inaccuracy as the top barrier to AI adoption. Why AI fails on structured data and what to look for in trustworthy data access. ](https://dhino.io/blog/why-ai-gets-enterprise-data-wrong)[ February 18, 2026 ### Why your data and AI investments are not paying off Only 19% of executives see revenue gains from AI. The problem is not the AI. It is the broken data layer underneath. The four root causes and what to fix first. ](https://dhino.io/blog/why-data-ai-investments-underperform) ## Things people keep asking us [ February 3, 2026 ### How to give Copilot accurate access to Dataverse data Copilot needs Dataverse data to answer business questions. The template-based approach to governed, accurate Copilot data access. ](https://dhino.io/blog/copilot-enterprise-data-access)[ March 13, 2026 ### How to connect Copilot Studio agents to governed enterprise data Copilot Studio agents need enterprise data but standard connectors lack governance and business context. Learn how template-based access solves this. ](https://dhino.io/blog/copilot-studio-governed-data)[ March 6, 2026 ### How to build governed data segments without waiting on IT Marketing teams wait days for data segments while Excel workarounds erode trust. How template-based self-service gives business users governed access. ](https://dhino.io/blog/governed-data-segments-without-it) ## Things we wish more people asked [ May 12, 2026 ### How AI agents should access enterprise data: tools, MCP, and the deterministic execution gap AI agents access enterprise data through tools, and MCP is becoming the default protocol. What separates a safe production tool from a demo, and where the field is heading in 2026. ](https://dhino.io/blog/ai-agents-and-enterprise-data)[ March 2, 2026 ### What Model Context Protocol means for enterprise data teams MCP standardizes how AI tools access enterprise data. What it is, how it works, and what it changes for data team architecture. ](https://dhino.io/blog/mcp-enterprise-data-access)[ March 18, 2026 ### Dataverse data access: connectors, APIs, and the governed alternative Compare Dataverse data access methods: connectors, Web API, FetchXML, virtual tables, and SSIS. What each solves and where a governed layer fills the gap. ](https://dhino.io/blog/dataverse-data-access-methods)[ March 24, 2026 ### AI data governance: what enterprises need before scaling AI access AI access to enterprise data is scaling faster than governance. The four requirements enterprises need before expanding AI access. ](https://dhino.io/blog/ai-data-governance-enterprise) ## Things we have opinions about [ February 13, 2026 ### Template-based data access vs. text-to-SQL: an honest comparison Two approaches to AI data access compared on accuracy, governance, and enterprise readiness. When to use each and where they fall short. ](https://dhino.io/blog/template-based-vs-text-to-sql) ## See these ideas in practice Learn how dhino gives AI tools governed access to your enterprise data, from Dataverse to Copilot. --- title: How AI agents should access enterprise data | dhino description: AI agents access enterprise data through tools, and MCP is becoming the default protocol. What separates a safe production tool from a demo, and where the field is heading in 2026. url: https://dhino.io/blog/ai-agents-and-enterprise-data/ --- Blog # How AI agents should access enterprise data: tools, MCP, and the deterministic execution gap May 12, 2026 The way AI agents reach enterprise data is changing fast. A year ago the question was how to stuff enough context into a prompt. Today the answer is increasingly the same across every major framework: don't stuff context, give the agent tools it can call. The shift sounds technical, but the implications are organisational. Once an agent can call your data, the quality of that call layer decides whether the agent is a demo or a system you would let near a real customer record. This post walks the pattern, the protocol, the failure modes most current implementations carry into production, and what a tool actually has to do to be safe. ## Key takeaways 1. The agent-as-tool-user pattern is replacing prompt-stuffing and brittle RAG across LangChain, AutoGen, Microsoft Agent Framework, and Copilot Studio. 2. A tool is a function with typed parameters that an agent can call. MCP is the connectivity layer that lets any agent talk to any tool. 3. Most current data tools are unsafe in production: they wrap CRUD across all tables under the calling user, or generate SQL at runtime with no per-agent scope. 4. A production-ready data tool needs per-agent scoping, named operations carrying business logic, deterministic execution, durable context, per-call audit, and multi-source reach behind one endpoint. 5. In 2026, governance and accountability become the actual differentiator between agent platforms, not model size. ## The agent-as-tool-user pattern is taking over For a while, retrieval-augmented generation looked like the dominant architecture for enterprise AI. Pull the relevant documents, paste them into the prompt, ask the model to answer. It works for unstructured corpora. It struggles the moment the question needs an exact number from a specific table. The pattern that is winning in 2026 looks different. The agent reasons about user intent. The agent does not fetch data itself. Instead, it calls a tool. The tool is the piece of software that knows how to talk to the data system. The agent decides what to ask; the tool runs the actual operation and returns the result. This split shows up everywhere you look right now. LangChain has had a tool abstraction from the start. AutoGen orchestrates multi-agent conversations around shared tools. The Microsoft Agent Framework is built around it. Copilot Studio agents call connectors and MCP servers as tools. Custom orchestrators built directly on top of an LLM API converge on the same shape because the alternative, an agent that tries to be the database client itself, does not survive contact with a real schema. These platforms argue about a lot. They agree on one thing: the agent reasons, the tool executes. ## What "tool" actually means in this pattern A tool in this context is not a UI button or a CLI command. It is a function with a name, a typed parameter list, and a return shape that an agent can discover and call. The model sees a catalogue of tools, picks one based on the user's request, supplies the parameters, and reads the result back. Until 2024, every agent framework defined its own tool protocol. LangChain tools were not OpenAI function calls were not Anthropic tool use messages were not Copilot Studio connectors. Building a tool meant building it once per framework, or accepting that your tool worked with one client only. [Model Context Protocol](https://dhino.io/glossary/model-context-protocol) (MCP) closes that fragmentation. It is an open standard that defines how a client (the agent) discovers and calls tools served by a server (the data or system endpoint). Any MCP-compliant agent can connect to any MCP-compliant tool. The protocol is the connectivity layer; what the tools actually do is up to whoever runs the server. For a longer read on why this matters for data teams, see [what MCP means for enterprise data teams](https://dhino.io/blog/mcp-enterprise-data-access). The short version: MCP turns the AI-to-data integration problem from N times M into N plus M. ## Why most current data tools are unsafe for production Connectivity is solved. Governance is not. A lot of the MCP servers and agent tools in circulation today are written for demos, then pushed into production with the same shape. Three patterns recur, and each one breaks something real. **Pattern one: CRUD across every table under the calling user.** The tool wraps create, read, update, and delete verbs against the whole data layer. Whoever invokes the agent gives the agent their full permissions for that call. An admin runs the agent, and for the duration of that call the agent has admin rights. There is no way to say "this agent reads accounts but never writes them" without rebuilding the permission model from scratch. **Pattern two: SQL generation at runtime.** The tool exposes a single "query the database" operation and asks the model to write the SQL. This is the deterministic execution gap. The same question asked twice can return two different queries, two different shapes, two different answers. Worse, the model can write a join that is syntactically valid and semantically wrong, and nothing in the pipeline catches it. Read [deterministic execution](https://dhino.io/glossary/deterministic-execution) for the longer treatment; the short version is that a query layer the model writes is a query layer the model can hallucinate. **Pattern three: no audit dimension separate from the user.** Standard data-layer audit captures record-level changes against whoever invoked the call. If the agent is acting as the user, the audit says the user did it. There is no way after the fact to ask "what did the lease agent touch this week?" because the lease agent does not exist as a distinct actor in the log. Each of these is fine for a demo. None of them is fine for an agent that updates customer data, books revenue, or sends communications on the company's behalf. ## What a production-ready data tool actually requires If you are evaluating an MCP server, a Copilot Studio connector, a LangChain toolkit, or a homegrown agent tool, here is the list to run it against. Each criterion is what separates a generic tool from one fit for an [enterprise AI agent](https://dhino.io/glossary/enterprise-ai-agent): a requirement of the tool, not a property of the agent or the model. - **Per-agent, per-table, per-action scoping.** One agent reads Accounts and updates Cases. Another agent has its own scope, defined separately. The tool's configuration, not the invoking user's role, decides what the agent can touch. - **Named operations carrying business logic, not just CRUD.** Custom business actions and any platform-specific custom APIs should be registered as named tools. The agent calls "RenewLeaseContract" by name and the tested logic for that operation runs. The model is not asked to figure out the CRUD chain that approximates it. - **Deterministic execution against tested templates.** The tool runs defined queries with parameters, not model-generated SQL. The same question always returns the same answer. Failures are query failures, not silent semantic drift. The underlying pattern is captured in [data access templates](https://dhino.io/glossary/data-access-templates): define the operation once, parameterise it, run it forever. - **Agent credentials separate from the invoking user.** The agent authenticates with its own identity. The scope granted to the agent is separate from what the invoking user can see, so the same person can use different agents with different access without juggling role assignments. - **Row-level and field-level filters configurable per agent.** "Only this department," "only active records," "only the user's own opportunities" are expressible without inventing new security roles in the underlying data system. - **Durable domain context.** Domain concepts like "lease agreement" or "qualified opportunity" are defined once with their tables, relationships, and rules, then reused across agents. Every new agent does not start from a blank schema. - **Per-agent audit trail of tool calls.** The log records what the agent did, with the call inputs and the result, separated from the user dimension. "The lease agent did it" is a sentence the audit can support. - **Multi-source aggregation behind a single endpoint.** One server combines data from multiple systems behind one MCP endpoint. For the agent it looks like one source. The access rules and audit apply across all of them, not per connector. Use the list to evaluate any agent platform. A tool that fails three or more of these is still useful for a prototype. It is not the tool you want behind an agent that ships to customers. ## Where the field is going in 2026 Three things are happening at once, and they are reinforcing each other. The first is framework consolidation. The number of agent frameworks worth building against is shrinking, not growing. Microsoft Agent Framework, Copilot Studio, LangChain, AutoGen, and a handful of custom orchestrators cover most production workloads. The differences between them are getting smaller as they converge on similar primitives. The second is MCP becoming the default. As of May 2026, every major agent platform either supports MCP natively or has a published path to it. The proprietary tool protocols are not going away yet, but new integrations default to MCP, and the cost of not supporting it is climbing fast. The third is the one that matters most. Once the frameworks consolidate and the protocol is shared, the actual differentiator between agent platforms in production is governance. Not model size. Not context window. Whether a given agent platform can answer the questions an auditor will ask: who can this agent reach, what did it do, under what identity, with what business logic, and can you prove it. The teams that win in production are the ones whose tools are governed. The teams that stay in pilot are the ones whose tools are clever. ## Where dhino fits dhino is one implementation of this pattern in the Microsoft ecosystem: an MCP server for Dataverse and adjacent sources, built around named operations, per-agent scoping, deterministic execution against tested templates, and a per-call audit trail. For a concrete capability comparison against Microsoft's standard Dataverse MCP server, see [dhino's Dataverse MCP server vs Microsoft's](https://dhino.io/compare/dataverse-mcp). For the product page, [dhino Trust](https://dhino.io/product/trust). --- title: AI data governance: what enterprises need first | dhino description: AI access to enterprise data is scaling faster than governance. Learn the four governance requirements, including audit trails, access controls, and data residency, that enterprises need before expanding AI access. url: https://dhino.io/blog/ai-data-governance-enterprise/ --- Blog # AI data governance: what enterprises need before scaling AI access March 24, 2026 Your AI pilot worked. A small team connected an LLM to a data source, got useful answers, and now leadership wants it rolled out across the organization. More teams, more data sources, more use cases. The pressure to scale is real. But here is the question nobody is asking loudly enough: what governance is actually in place? Not the policy document that legal signed off on. Not the slide in the AI strategy deck. The enforced, technical controls that determine what data AI can access, under what conditions, with what accountability. In most enterprises, the honest answer is: not enough. ## Key takeaways 1. AI access to enterprise data is expanding faster than the governance controls that should regulate it. 2. AI data governance requires enforced access controls, audit trails, embedded business logic, and data residency guarantees. Not policy documents. 3. GDPR and the EU AI Act create specific obligations around transparency, data minimization, and accountability that apply to AI systems accessing personal data. 4. Most governance failures happen because controls exist in documentation but not in the systems that process data. 5. Governance infrastructure must be in place before scaling AI access, not retrofitted after an incident. ## AI access is scaling faster than governance Two years ago, AI touching enterprise data was an experiment. Today, teams across organizations are connecting AI tools to CRM systems, financial databases, customer records, and HR platforms. Copilot reads your Dataverse. Custom agents query your data warehouse. Each connection is a new access point to sensitive information. The governance structures that exist were designed for a world where humans requested data through IT. Access reviews happened quarterly. Permission changes went through tickets. That cadence cannot keep pace with AI tools that make thousands of data requests per day, each one potentially touching personal, financial, or compliance-sensitive records. This is not a theoretical risk. Organizations that [struggle to see returns from AI investments](https://dhino.io/blog/why-data-ai-investments-underperform) often discover the problem is not the AI itself. It is the absence of a governance layer that makes AI safe to scale. ## What AI data governance actually requires AI [data governance](https://dhino.io/glossary/data-governance) is not a policy. It is infrastructure. The distinction matters because policies describe intent. Infrastructure enforces it. When a DPO presents the AI governance framework to the board, the question should not be "do we have a policy?" It should be "is the policy enforced in the system, or does it depend on people following rules?" Four capabilities separate governance that works from governance that exists only on paper. ### Enforced access controls Every AI consumer needs its own permission boundary. Not the same permissions as the human who deployed it. Not blanket read access to an entire database. Granular, enforced rules that determine which fields, which records, and which operations each AI tool can perform. If your customer service agent can query financial data, something is wrong. ### Complete audit trails When a regulator asks "what data did your AI system access last Tuesday?", you need an answer. Not an approximation. A log showing which AI tool accessed which data, with what parameters, at what time, returning what results. This is not optional under GDPR. And with the EU AI Act, the requirements for AI system transparency are expanding. ### Embedded business logic AI systems need to operate on the same business definitions as the rest of the organization. When an AI agent retrieves "active customers in DACH", it should use the same definition your finance team uses. Not a definition it inferred from the data schema. This requires [deterministic execution](https://dhino.io/glossary/deterministic-execution) of predefined logic, not generated queries that vary with each request. ### Data residency guarantees Where does the data go when an AI tool processes it? For European enterprises, this is not a nice-to-know. It is a compliance requirement. GDPR restricts the transfer of personal data outside the EEA. If your AI governance infrastructure cannot guarantee where data is processed and stored, you have a regulatory exposure that no policy document can close. ## The European regulatory context European enterprises operate under regulatory pressure that makes AI data governance more than a best practice. GDPR has been enforced since 2018, and regulators have become increasingly specific about how it applies to AI. Data minimization, purpose limitation, and the right to explanation all apply when AI systems process personal data. The fines are real: up to 4% of global annual turnover. The EU AI Act adds another layer. High-risk AI systems (which includes many enterprise use cases touching employment, credit, or public services data) must meet specific requirements for transparency, human oversight, and data quality. Organizations must document how their AI systems work, what data they access, and how decisions are made. For CIOs and CDOs reporting to boards in Europe, this creates a clear obligation. Scaling AI access without governance infrastructure is not a calculated risk. It is a compliance gap with a price tag attached. The organizations that move first on governance infrastructure will have a structural advantage: they can scale AI access because they have the controls to do it safely. ## Where governance breaks down in practice The pattern is consistent across organizations. A governance framework exists. It was approved by legal, endorsed by leadership, presented at a town hall. And then AI tools are deployed without any of those controls being enforced at the technical level. The breakdown happens because governance was designed as a process, not as infrastructure. Access reviews happen in spreadsheets. Audit logs depend on individual tools reporting their own activity. Business definitions live in wikis that AI systems cannot read. Data residency is assumed based on the vendor's marketing, not verified through technical architecture. When [new protocols like MCP](https://dhino.io/blog/mcp-enterprise-data-access) make it easier for AI tools to access data, this gap widens. Connectivity improves. Governance stays manual. The result is more AI tools accessing more data with the same level of oversight that was already insufficient. The fix is not more process. It is a governance layer that sits between AI and data, enforcing controls at the point of access. Some organizations build this internally. Others use platforms (like [dhino](https://dhino.io/product/trust/governed-ai-at-scale)) that provide governed AI data access with European data residency on Azure. The approach matters less than the outcome: controls that are enforced by default, not dependent on people remembering to follow them. ## Building governance infrastructure before scaling AI The temptation is to scale AI access now and add governance later. This is how most security incidents happen. Not through malice, but through speed outpacing controls. The organizations that scale AI successfully do it in the opposite order: governance infrastructure first, then expanded access. Start with an inventory of what AI can currently access. Most organizations discover that the actual access footprint is larger than anyone realized. Shadow deployments, broad permission grants from pilot phases, and inherited access from the humans who set up the tools all contribute to an uncontrolled surface area. Then ask four questions. Can you prove what data each AI system accessed last month? Can you restrict an AI tool to specific fields and records, not just tables? Are business definitions enforced in the system or just documented in a wiki? Can you guarantee where personal data is processed? If any answer is no, that is where governance infrastructure needs to go before AI access expands further. The board will ask about AI governance eventually. The regulators will ask about it eventually. The question is whether you build the infrastructure proactively or explain its absence reactively. --- title: How to give Copilot accurate Dataverse access | dhino description: Copilot needs Dataverse data to answer business questions. Learn the template-based approach that gives Copilot governed, accurate access to enterprise data. url: https://dhino.io/blog/copilot-enterprise-data-access/ --- Blog # How to give Copilot accurate access to Dataverse data February 3, 2026 Your sales director asks Copilot: "What is the pipeline value for Q2?" Copilot generates a query, runs it against Dataverse, and returns a number. The number is wrong. The director does not know it is wrong. Decisions get made on bad data. This is not a hypothetical scenario. It is the default behavior when AI tools access enterprise data directly. The [fundamental problem](https://dhino.io/blog/why-ai-gets-enterprise-data-wrong) is well documented. This article focuses on a concrete solution. ## Why Copilot struggles with Dataverse Copilot is good at understanding what you are asking. It correctly interprets "pipeline value for Q2" as a request for sales pipeline data filtered to the second quarter. That part works. The failure happens next. Copilot needs to translate that understanding into a query against your Dataverse instance. Which table stores pipeline data? How are opportunities linked to accounts? What counts as "pipeline" (all open deals? qualified only? weighted value?). What defines Q2 in your fiscal calendar? Copilot guesses. And the guess changes based on phrasing, context, and model behavior. Same question, different answers. This is [text-to-SQL](https://dhino.io/glossary/text-to-sql) in practice: powerful for exploration, unreliable for business decisions. ## The template-based approach The solution separates two distinct tasks. Let Copilot do what it is good at: understand the question. Then hand execution to a system that uses predefined, tested logic to get the answer. In practice, this works in two stages. Stage one is non-deterministic: Copilot interprets the user's intent and figures out what data they need. Stage two is [deterministic](https://dhino.io/glossary/deterministic-execution): a predefined template executes the exact query that your data team wrote and tested. "Pipeline value" always means the same thing. The same tables, the same joins, the same filters. Whether a sales rep asks or the CFO asks. Whether they ask on Monday or Friday. ## How dhino connects Copilot to Dataverse [dhino Trust](https://dhino.io/product/trust) sits between Copilot and your Dataverse data. It provides governed, template-based access through the Model Context Protocol (MCP). Your data team defines templates that carry business logic: what "pipeline value" means, what "active customer" means, how quarterly revenue is calculated. These templates carry access controls (who can see what) and are fully auditable (what was accessed, when, by whom). When someone asks Copilot a data question, dhino matches the intent to the right template and executes predefined logic. No SQL generation. No schema guessing. No business rule reinvention. The same question always produces the same answer. [See a detailed walkthrough of the Copilot pipeline scenario](https://dhino.io/product/trust/copilot-pipeline). ## What this means for your organization Business users get trusted answers from Copilot. They do not need to know SQL, understand the database schema, or worry about whether the answer is accurate. If they can ask the question, they get the right answer. IT teams maintain control. Templates are defined and tested by people who understand the data. Access controls apply automatically. Every query is logged. Governance is not something IT has to enforce manually. It is built into the platform. Leadership sees real ROI from AI investments. When Copilot gives accurate, consistent answers about pipeline, revenue, and operations, people use it. When it gives wrong answers, they stop. The difference between adoption and abandonment is accuracy. The same approach works for [customer service agents querying account data](https://dhino.io/product/trust/customer-service-agent). --- title: Connect Copilot Studio to governed data | dhino description: Copilot Studio agents need enterprise data but standard connectors lack governance and business context. Learn how template-based access solves this. url: https://dhino.io/blog/copilot-studio-governed-data/ --- Blog # How to connect Copilot Studio agents to governed enterprise data March 13, 2026 You built a Copilot Studio agent. It handles conversations well. Then someone asks it for actual business data and the wheels come off. The agent either returns wrong numbers, makes up definitions, or hits a dead end because it cannot reach the data it needs. The instinct is to connect more data sources. Add connectors. Give the agent access. But access without governance creates a different set of problems. The [accuracy problem with AI and enterprise data](https://dhino.io/blog/why-ai-gets-enterprise-data-wrong) does not go away just because the pipe is wider. ## Key takeaways 1. Standard Copilot Studio connectors pass raw data without business context, leading to inconsistent or wrong answers. 2. Connectors solve transport but not meaning: they do not know what "active customer" or "pipeline value" means in your business. 3. A governed data layer separates AI intent recognition from deterministic data execution, so the same question always returns the same answer. 4. Look for template-based access with embedded business logic, access controls, and full audit trails when connecting agents to enterprise data. ## The connector problem Copilot Studio has connectors for Dataverse, SharePoint, SQL Server, and hundreds of other sources. On paper, the data access problem looks solved. Your agent can reach the data. Ship it. In practice, reaching data and correctly using data are two different things. Connectors handle authentication and transport. They get your agent past the front door. But they carry no business context. A connector does not know that your fiscal Q2 starts in October, that "pipeline value" excludes deals on hold, or that your European entity uses a different account hierarchy than North America. That context lives in your team's heads, in spreadsheets, in documentation nobody has updated in two years. Without it, your agent falls back on [text-to-SQL](https://dhino.io/glossary/text-to-sql): generating a new query every time, guessing tables, joins, and business definitions. The answer changes depending on phrasing and model behavior. There is also no governance layer. Who asked what? Which data was returned? Did the agent have permission to see those records? Connectors are plumbing. They move data. They do not control it. ## How governed data access works with Copilot Studio The fix is not to remove connectors. It is to add a governed layer between the agent and your data. Instead of the agent generating queries on the fly, it calls predefined [data access templates](https://dhino.io/glossary/data-access-templates) that your data team wrote, tested, and approved. Each template carries the business logic for a specific data operation. "Pipeline value" is defined once: the right tables, the right joins, the right filters, the right exclusions. The agent does not have to guess. It selects the right template based on what the user is asking, fills in the parameters (which quarter? which region?), and gets a [deterministic result](https://dhino.io/glossary/deterministic-execution). Same question, same answer. Whether the VP of Sales asks or a new hire asks. Whether they ask on Tuesday or Saturday. The business definition does not change because the agent had a different idea today. ## What the architecture looks like The architecture separates two jobs that are often tangled together. The AI handles understanding. A governed execution layer handles the data. Stage one: the Copilot Studio agent receives a user question and interprets the intent. This is the non-deterministic part. AI is good at this. It understands that "how did we do last quarter in EMEA" means revenue, filtered by region and time period. Stage two: the agent passes that intent to a governed data layer (like [dhino Trust](https://dhino.io/product/trust)) which matches the intent to a template and executes the predefined query. Access controls apply automatically. The query is logged. The result is returned to the agent, which formats the answer for the user. No SQL generation. No schema guessing. No business rules reinvented on every request. The AI focuses on conversation and intent. The governed layer focuses on getting the right data, safely. For a worked example of this pattern in action, [see how dhino connects Copilot to Dataverse](https://dhino.io/blog/copilot-enterprise-data-access), or read the [Microsoft Dataverse MCP server vs dhino's](https://dhino.io/compare/dataverse-mcp) comparison. ## What to look for when connecting agents to enterprise data If you are building Copilot Studio agents that need real business data (not just document search or FAQ answers), the connector layer alone will not get you there. Here is what to evaluate. Business logic encoding. Can you define what your terms mean once and have those definitions apply to every agent request? If the agent still generates ad-hoc queries, accuracy will stay unpredictable. Access controls at the data layer. Governance applied at the connector level is too coarse. You need field-level and row-level controls that follow the user, not just the agent. Audit trails. When something goes wrong (and it will), you need to trace the path from question to answer. Which agent, which user, which data, when. Consistency. Ask the same question twice. If you get the same answer, you are on the right track. If not, the agent is guessing. Your users will notice before you do. --- title: Dataverse data access: connectors, APIs, and alternatives | dhino description: Compare Dataverse data access methods: connectors, Web API, FetchXML, virtual tables, and SSIS. Learn what each solves and where a governed layer fills the gap. url: https://dhino.io/blog/dataverse-data-access-methods/ --- Blog # Dataverse data access: connectors, APIs, and the governed alternative March 18, 2026 [Dataverse](https://dhino.io/blog/what-is-dataverse) holds the data that runs your business applications. Customer records, sales pipelines, service cases, financial transactions. Getting that data out of Dataverse and into the systems, reports, and AI tools that need it is a problem every Microsoft shop faces eventually. There is no single "right" method. Dataverse offers several access paths, each designed for different scenarios. But most of them solve the same thing: transport. They move data from point A to point B. What they typically do not solve is governance: who can access what fields, what business logic applies, and who accessed what data when. ## Key takeaways 1. Dataverse offers multiple data access methods: standard connectors, Web API, FetchXML, virtual tables, and SSIS packages. 2. Each method solves the transport problem but none include business logic, field-level access controls, or audit trails by default. 3. The Web API is the most flexible option but requires significant developer effort and custom governance code. 4. A governed access layer sits on top of any transport method and adds the controls that production environments need. 5. The right choice depends on who consumes the data, how often, and what controls are required. ## The standard ways to access Dataverse data The most common starting point is the Dataverse connector in Power Automate or Power Apps. It is built into the platform, requires no code, and works well for simple scenarios: trigger a flow when a record changes, pull a list of accounts into a canvas app, update a field based on a condition. The connector has limits. It follows Dataverse's built-in security model, which means it respects table-level and row-level security but does not let you add custom business logic. You cannot filter results based on rules that do not exist in Dataverse's security configuration. And throughput is constrained by Power Platform API limits, which matter once you move past small data volumes. For Power BI, the Dataverse connector (formerly Common Data Service) provides read access for reporting. It works but loads entire tables unless you write custom queries. For large Dataverse environments, this creates performance problems that force teams into incremental refresh patterns or Azure Synapse Link for staging. ## What the Web API gets right and where it stops The Dataverse Web API is the most powerful access method available. It is a RESTful OData endpoint that supports full CRUD operations, complex queries, batch requests, and function/action calls. Any system that can make HTTP requests can talk to Dataverse through the Web API. This flexibility is also the Web API's biggest challenge. Building a reliable integration means handling authentication (Azure AD OAuth), pagination (Dataverse returns 5,000 records per page by default), throttling (429 responses under load), and error handling for every edge case. That is real development work, not configuration. The deeper issue: the Web API gives you raw data access. It does not include business logic. If "active customer" means something specific in your organization (created more than 90 days ago, has at least one open order, not flagged for review), that logic lives in your integration code, not in Dataverse. Every new integration reimplements it. Every reimplementation is a chance to get it wrong. ## FetchXML, virtual tables, and SSIS: niche tools for specific problems FetchXML is Dataverse's native query language. It is XML-based, supports aggregations and linked entity queries, and respects Dataverse security. Developers use it inside plugins, custom workflows, and SSRS reports. It is more expressive than simple OData filters but significantly more verbose. Maintaining complex FetchXML queries across environments is tedious, and debugging is harder than it should be. Virtual tables take the opposite approach. Instead of pulling data out of Dataverse, they bring external data in. A virtual table maps an external data source (a SQL database, a SharePoint list, an API) into Dataverse's table structure so it looks like native data. This is useful for giving Power Apps users a unified view, but it adds latency and has limitations around write operations and complex joins. SSIS (SQL Server Integration Services) packages handle batch ETL scenarios. If you need to move large volumes of Dataverse data into a data warehouse on a schedule, SSIS with the KingswaySoft connector or the Dataverse OData source is a proven pattern. It solves bulk movement well but does not help with real-time access, ad hoc queries, or self-service scenarios. ## What a governed access layer adds on top Every method above solves transport. Data gets from Dataverse to somewhere else. What none of them solve by default is [governance](https://dhino.io/glossary/data-governance): consistent business logic, field-level access controls that go beyond Dataverse's built-in security, and audit trails showing who accessed what data through which channel. A governed access layer sits between Dataverse and its consumers. It uses [predefined data operations](https://dhino.io/glossary/data-access-templates) that define business logic once. "Active customer" means the same thing whether a business user requests a list, an integration syncs records to another system, or an AI tool answers a question. The definition lives in one place and applies everywhere. This pattern is not new. It is the same principle behind API gateways and database views, applied to the specific challenge of making Dataverse data usable outside Power Platform. Platforms like [dhino](https://dhino.io/product/trust) implement this pattern natively for Dataverse, while other organizations build custom middleware. The approach matters less than the outcome: consistent, auditable, governed data access regardless of who or what consumes it. ## Choosing the right approach for your environment The right access method depends on four things: who consumes the data, how much data moves, how often it moves, and what controls are required. Standard connectors work for low-volume, internal Power Platform scenarios. The Web API fits custom integrations where a development team can maintain the code. FetchXML belongs in Dataverse-native customizations. SSIS handles bulk warehouse loads. Most Dataverse environments end up using several of these methods simultaneously. The risk is not in choosing one over another. It is in having five different access paths with five different implementations of what "active customer" means and no central record of who pulled what data. If your Dataverse data stays inside Power Platform, built-in connectors may be sufficient. Once data needs to reach external systems, AI tools, or non-technical users outside the Microsoft ecosystem, the governance question becomes unavoidable. For a deeper look at how [Model Context Protocol is changing AI data access](https://dhino.io/blog/mcp-enterprise-data-access), or how to [give Copilot accurate Dataverse access](https://dhino.io/blog/copilot-enterprise-data-access), those posts cover the AI side of this problem in detail. If you are evaluating a [governed Dataverse MCP server for AI agents](https://dhino.io/compare/dataverse-mcp), the side-by-side comparison covers how it differs from Microsoft's standard server. --- title: Build governed data segments without IT | dhino description: Marketing teams wait days for data segments while Excel workarounds erode trust. Learn how template-based self-service gives business users governed access. url: https://dhino.io/blog/governed-data-segments-without-it/ --- Blog # How to build governed data segments without waiting on IT March 6, 2026 You need a list of all customers in the DACH region who attended an event last year but have not renewed their contract. You know the data exists. You just cannot get to it without filing a ticket and waiting for someone in IT to write the query. So you do what everyone does. You export what you can to Excel, manually cross-reference two spreadsheets, and hope you picked the right fields. The campaign goes out. The numbers look close enough. Nobody is fully confident. ## Key takeaways 1. Business teams wait days or weeks for data segments because every request routes through IT, even for recurring lists. 2. The Excel workaround creates ungoverned, inconsistent data: different people use different fields, filters, and definitions. 3. Template-based segmentation lets IT define the right logic once so business users can build segments on their own, with guardrails. 4. Governed self-service means independence for business teams without sacrificing accuracy, audit trails, or access controls. ## The segmentation bottleneck Marketing needs data segments constantly. Target lists for campaigns, attendee lists for events, exclusion lists for opt-outs, region-specific cohorts for localised messaging. These are not one-off requests. They repeat every week, every month, every quarter. But the data lives across CRM tables, event systems, and subscription databases. Getting a segment that combines data from two or more of those sources means someone has to understand how the tables relate, which fields to use (and which five similar-sounding fields to ignore), and how filters should be applied. That someone is usually in IT. IT is not slow on purpose. They have a backlog. Your segmentation request sits behind infrastructure work, security patches, and other data requests from Sales, Finance, and Operations. Turnaround is measured in days when you need it in hours. Standard tools do not help much either. Dynamics 365 Marketing only segments on Accounts, Contacts, and Leads. Need to segment on event attendance, product usage, or contract status? That is outside the box. Power Apps does not offer real segmentation at all. ## What goes wrong with Excel workarounds When IT cannot deliver on time, business teams improvise. They export raw data to Excel, apply their own filters, and build segments manually. It works, technically. But it creates a set of problems that compound over time. First, definitions drift. One marketer filters "active customers" by last login date. Another uses last purchase date. A third uses contract renewal status. All three believe their list is correct. The CEO sees three different numbers in three different reports and trusts none of them. Second, there is no [governance](https://dhino.io/glossary/data-governance). Nobody tracks who exported what, when, or why. Sensitive fields (personal data, financial data) end up in spreadsheets on laptops. That is a compliance risk in any regulated environment, and in Europe it is a GDPR problem waiting to happen. Third, the work is not reusable. Every time the same segment is needed, someone starts from scratch. The knowledge about which fields to use and how to combine them stays in one person's head. When that person leaves or is on holiday, the segment is gone. ## How template-based segmentation works The pattern that fixes this separates two jobs. IT (or a data-savvy power user) defines the segmentation logic once. Business users consume it whenever they need to, without touching the database. The logic lives in [data access templates](https://dhino.io/glossary/data-access-templates). A template for "event attendees by region" knows which tables to query, how those tables relate to each other, which fields represent the region, and which filters to apply. The business user selects the template, picks their parameters (DACH, Q4 2025), and gets a result. No SQL. No guesswork about field names. Templates can also handle multi-step logic. Need all contacts who match criteria A, minus everyone already contacted this quarter, plus a newsletter subscriber list? That is a combine-subtract-add operation. With templates, each step is a defined data operation. The business user assembles them like building blocks. This is the approach [dhino Fetch](https://dhino.io/product/fetch) uses. IT builds the templates with the correct logic, relationships, and guardrails. Everyone else uses them. The domain knowledge does not live in someone's head anymore. It lives in the platform, available to anyone with permission. ## What governed self-service looks like in practice Self-service without governance is just a faster way to make mistakes. The reason IT controls data access is not bureaucracy. It is because giving raw database access to everyone creates real risk. The goal is not to remove IT from the picture. It is to change their role from "run this query for me" to "build the templates that everyone uses safely." In a governed model, access controls follow the user. A marketing manager sees marketing-relevant data. A regional lead sees data for their region only. Field-level permissions keep sensitive columns out of exports. Every segment request is logged with who ran it, what parameters they used, and when. That is the audit trail that compliance teams need. The result is [deterministic](https://dhino.io/glossary/deterministic-execution). Same template, same parameters, same answer. Whether a junior marketer runs the segment on Monday or the head of marketing runs it on Friday, the logic is identical. No more conflicting numbers in leadership meetings. IT builds once. Business uses many times. The backlog shrinks because recurring requests become self-service. New use cases get added as new templates, not as new tickets. For a detailed look at how this applies to [marketing campaign segmentation](https://dhino.io/product/fetch/marketing-segmentation), the scenario page walks through a complete example. --- title: What MCP means for enterprise data teams | dhino description: Model Context Protocol standardizes how AI tools access enterprise data. Learn what MCP is, how it works, and what it changes for data team architecture. url: https://dhino.io/blog/mcp-enterprise-data-access/ --- Blog # What Model Context Protocol means for enterprise data teams March 2, 2026 Every AI tool your organization adopts needs data. And right now, every one of those tools connects to your data differently. Different auth models, different query formats, different assumptions about your schema. For data teams, this is becoming unsustainable. Model Context Protocol (MCP) changes that equation. It is an open standard that gives AI tools a single, consistent way to access enterprise data. For data teams, MCP shifts the question from "how do we connect each AI tool?" to "how do we expose governed data once and let any AI tool consume it?" ## Key takeaways 1. MCP is an open standard for AI-to-data communication, replacing one-off connectors with a single protocol. 2. Data teams build one integration point instead of one per AI tool. New tools plug in without new infrastructure. 3. Governance centralizes at the MCP server layer: access controls, audit trails, and business logic live in one place. 4. MCP handles connectivity but not governance. Enterprise teams must evaluate what sits on top of the protocol. 5. The architectural shift is from "which AI tools do we support?" to "what data operations do we expose, and with what rules?" ## The connector problem nobody wants to maintain Count the AI tools touching your data today. Copilot for CRM queries. ChatGPT for analysis. Claude for document review. Custom agents for specific workflows. Each one needs data access, and each one got its own connector, its own auth integration, its own assumptions about your schema and business rules. Data teams now maintain a growing web of point-to-point integrations. Adding a new AI tool means building another connector. Removing one means hunting for orphaned infrastructure. Updating a business rule means changing it in every connector separately. This is the pre-USB era for AI data access. Every device had its own cable. MCP is the standard port. ## What MCP is and where it came from [Model Context Protocol](https://dhino.io/glossary/model-context-protocol) is an open standard created by Anthropic that defines how AI tools communicate with external data sources. Instead of each AI vendor building proprietary connectors, MCP provides a shared protocol: one way for AI tools to discover, request, and receive data. The standard specifies how AI tools discover what data sources are available, what operations they can perform, and how results flow back. One protocol instead of dozens of custom integrations. MCP is gaining adoption because the alternative does not scale. As organizations deploy more AI tools, the cost of maintaining individual connectors grows linearly. MCP makes it sublinear: build the server once, connect any compatible tool. ## How MCP works in practice MCP defines two roles. Clients are the AI tools that need data: Copilot, ChatGPT, custom agents. Servers are the systems that provide data: your databases, APIs, SaaS platforms, or a governed data layer that sits in front of them. A server exposes two things: tools (actions the AI can invoke, like "get active customers for region X") and resources (data the AI can read, like a list of available reports). When an AI tool connects to an MCP server, it discovers what is available at connection time. No hardcoded integrations. The AI learns what it can do and adapts accordingly. For enterprise data teams, think of an MCP server as a governed API that any MCP-compatible AI tool can consume. You build the server once. You define what operations are available and who can access them. Every AI tool that speaks MCP plugs in without additional work. ## What changes for enterprise data architecture The first change is operational. Standardized connectors mean your data team builds one integration point for AI access instead of one per tool. When the next AI tool arrives (and it will), it plugs into the existing MCP infrastructure. No new project. The second change is architectural. [Governance](https://dhino.io/glossary/data-governance) centralizes at the MCP server layer. Access controls, audit trails, and business logic live in one place rather than scattered across individual connectors. When a business rule changes, you update it once. Every AI consumer inherits the change. The shift in thinking is meaningful. Instead of asking "which AI tools do we support?", data teams start asking "what data operations do we expose, and with what governance?" That is a more sustainable question for an architecture that will need to absorb new AI tools for years to come. ## What to look for in MCP implementations MCP solves the connectivity problem. It does not solve the governance problem. The protocol defines how AI tools communicate with data, but what happens on the server side (access controls, business logic, audit trails, query accuracy) depends entirely on implementation. When evaluating MCP implementations for enterprise use, look for: - Access controls that apply to every AI consumer, not just human users - Audit trails showing what data was accessed, by which tool, with what parameters - Business logic defined once and enforced across all consumers - [Deterministic execution](https://dhino.io/glossary/deterministic-execution) instead of AI-generated queries, so the same question always returns the same answer Some platforms, like [dhino](https://dhino.io/product/trust), are built as MCP-native data layers that add governance and template-based execution on top of the protocol. Other approaches build MCP servers directly on top of databases. The key distinction is whether the implementation adds an enterprise governance layer or simply exposes raw data access through a new protocol. For a concrete example, see this [Dataverse MCP server comparison: dhino vs Microsoft](https://dhino.io/compare/dataverse-mcp). ## Where this is heading MCP adoption is accelerating. As more AI tools and data platforms support the standard, the cost of not adopting it increases. Teams still building custom connectors today will be maintaining legacy infrastructure tomorrow. The teams that benefit most will be those that treat MCP as an opportunity to rethink their AI data access strategy, not just swap out one connector format for another. The protocol makes standardized access possible. What you build on top of it determines whether that access is governed, auditable, and trustworthy. For a practical look at the accuracy problem that governance needs to solve, [read why AI gets enterprise data wrong](https://dhino.io/blog/why-ai-gets-enterprise-data-wrong). --- title: Template-based vs. text-to-SQL comparison | dhino description: An honest comparison of template-based data access and text-to-SQL. Learn where each approach works, where it fails, and which fits enterprise requirements. url: https://dhino.io/blog/template-based-vs-text-to-sql/ --- Blog # Template-based data access vs. text-to-SQL: an honest comparison February 13, 2026 Two approaches dominate the conversation about AI data access. [Text-to-SQL](https://dhino.io/glossary/text-to-sql) generates database queries from natural language. Template-based access uses predefined logic that AI selects and calls. Both have real strengths. Both have real limitations. This comparison is written by dhino, which uses the template-based approach. We have tried to be genuinely balanced. Text-to-SQL is not a bad approach. It is the wrong approach for certain use cases, just as templates are wrong for others. ## How each approach works **Text-to-SQL:** A language model receives a question and a database schema description. It generates a SQL query that should answer the question. The query runs against the database. Results come back. Every question triggers a newly generated query. **Template-based:** Business logic is captured once in predefined templates by people who know the data. When a question comes in, AI identifies which template matches and calls it with the right parameters. The template executes [deterministic logic](https://dhino.io/glossary/deterministic-execution). Same question, same answer, every time. ## Side-by-side comparison Criteria Text-to-SQL Template-based Accuracy Variable. Research shows <50% on complex schemas Consistent. Predefined logic, tested results Flexibility High. Can answer questions nobody anticipated Limited to defined templates. New questions need new templates Setup effort Lower. Point at schema, start asking Higher. Templates must be defined and tested Governance Difficult. Generated queries bypass business rules Built in. Templates carry access controls Audit trail Complex. Every query is unique Straightforward. Known templates, known parameters Best for Ad-hoc exploration, simple schemas, data discovery Business-critical operations, complex schemas, regulated industries ## Where text-to-SQL wins Text-to-SQL is genuinely useful for exploration. When a data analyst needs to investigate an unfamiliar dataset, generating queries on the fly is faster than building templates. The analyst knows enough to validate the results and adjust the questions. For simple schemas with clear naming, text-to-SQL works well. A database with a single "orders" table and obvious column names produces reliable queries. The AI does not need to guess because there is nothing ambiguous. Text-to-SQL also wins on flexibility. It can answer questions nobody planned for. A template-based system needs someone to create a template first. Text-to-SQL just tries to generate the answer. Sometimes it gets it right. ## Where template-based access wins When accuracy matters more than flexibility, templates win. Business-critical questions like "What is our Q4 pipeline?" or "How many active customers do we have?" cannot tolerate variation. The board expects the same number from every source. Complex schemas expose the limits of text-to-SQL. Enterprise databases with hundreds of tables, implicit relationships, and business-specific definitions overwhelm query generation. The AI cannot guess that "active customer" means "account with a signed contract and at least one login in the past 90 days." Governance is the deciding factor for many enterprises. Templates carry access controls, produce consistent audit trails, and enforce business definitions. When compliance requires knowing exactly what logic produced each answer, templates provide that traceability. Generated queries do not. ## The practical answer: use both Most enterprises will use both approaches for different purposes. Text-to-SQL for ad-hoc exploration where accuracy is nice to have. Template-based access for business-critical operations where accuracy is mandatory. The question is not "which is better?" but "which is right for this use case?" If a data analyst is exploring a new dataset, let them use text-to-SQL. If the CFO asks Copilot for quarterly revenue, that answer should come from a governed template. dhino uses the template-based approach because the use cases it serves (business-critical data access, governed AI responses, cross-system integrations) require accuracy and governance. [See how dhino Trust applies template-based access to Copilot data queries](https://dhino.io/product/trust), or [how dhino compares overall to text-to-SQL and semantic layers](https://dhino.io/compare). --- title: What is Dataverse? Enterprise data explained | dhino description: Microsoft Dataverse is the data backbone for Power Platform and Dynamics 365. Learn what it does, where it fits, and how to make Dataverse data usable everywhere. url: https://dhino.io/blog/what-is-dataverse/ --- Blog # What is Dataverse and why does it matter? January 22, 2026 If you work in an organization that uses Microsoft, you have probably heard the word Dataverse. Maybe in a meeting about Power Apps. Maybe when someone mentioned Dynamics 365. Maybe when your IT team explained why you cannot just export that data to Excel. Dataverse is becoming more important, not less. As Microsoft builds Copilot deeper into its business applications, Dataverse is the data layer underneath. Understanding what it is (and what it is not) matters for anyone making decisions about enterprise data. ## What Dataverse actually is Dataverse is a cloud-based data platform built into Microsoft Power Platform. It stores structured business data in tables with defined columns, relationships, and security rules. Think of it as a managed database designed for business applications, not a raw SQL server. It comes with built-in features that raw databases do not have: row-level security, business rules, calculated fields, and a standard data model that Microsoft's own applications use. Dynamics 365 stores its data in Dataverse. Power Apps reads and writes to Dataverse. Power Automate triggers flows based on Dataverse events. For organizations already in the Microsoft ecosystem, Dataverse is not optional. It is the data backbone. ## Why Dataverse matters for enterprise data Dataverse is not just another database. It is the central data store for Microsoft's entire business application stack. Customer records, sales pipelines, service cases, inventory, HR data. If an organization runs Dynamics 365, all of this lives in Dataverse. This makes Dataverse strategically important. It holds the data that drives business decisions. Revenue figures, customer counts, pipeline values, operational metrics. The data that leadership asks about in every quarterly review. With Microsoft Copilot, this matters even more. Copilot needs access to structured business data to answer questions about customers, deals, and operations. That data lives in Dataverse. How you connect Copilot to Dataverse determines whether you get accurate answers or approximate guesses. [Learn how to give Copilot accurate Dataverse access](https://dhino.io/blog/copilot-enterprise-data-access). ## The Dataverse access problem Dataverse is excellent at storing and securing data. Getting data out of Dataverse and into the hands of people, systems, and AI that need it is harder than it should be. The standard options have limitations. Power BI connects to Dataverse but requires report-building skills. Custom connectors work but need developer time. Direct database exports break security models and create stale copies. The Dataverse Web API is powerful but complex. This creates a familiar pattern: the data exists, the data is valuable, but the people who need it cannot get to it without technical help. Marketing needs a customer segment. Finance needs a revenue breakdown. A partner needs account data through an API. Each request goes to IT, waits in a queue, and takes weeks. The problem gets worse with AI. When Copilot or other AI tools need Dataverse data, they face the same access challenges. Without a governed access layer, AI either cannot reach the data or reaches it without proper controls. ## Making Dataverse data usable beyond Power Platform The solution is a governed access layer that sits between Dataverse and everything that needs its data. Business users, external systems, websites, AI assistants. One layer, one set of rules, one audit trail. This is what dhino was built for. With deep expertise in Dataverse and Power Platform, dhino provides governed access to Dataverse data across every channel. [Fetch](https://dhino.io/product/fetch) lets business users pull Dataverse data without SQL. [Integrate](https://dhino.io/product/integrate) syncs Dataverse data with external systems reliably. [dhino Trust](https://dhino.io/product/trust) gives Copilot accurate, governed access to Dataverse data. The underlying principle is simple: Dataverse stores and secures your data. A governed access layer makes it usable everywhere else, safely. --- title: Why AI gets enterprise data wrong | dhino description: 45% of enterprises cite inaccuracy as the top barrier to AI adoption. Learn why AI fails on structured data and what to look for in trustworthy AI data access. url: https://dhino.io/blog/why-ai-gets-enterprise-data-wrong/ --- Blog # Why AI gets enterprise data wrong January 14, 2026 Ask your AI assistant a creative question and it performs well. Ask it how many active customers renewed last quarter and you get a number that looks right but probably is not. This is not a fringe problem. [McKinsey's State of AI report](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) found that 45% of enterprises cite inaccuracy as the number one barrier to AI adoption. Not cost. Not complexity. Inaccuracy. ## Key takeaways 1. AI generates a new query every time you ask a data question, guessing tables, joins, and business definitions. 2. Research shows LLMs achieve less than 50% accuracy on structured enterprise data queries. 3. Only 19% of C-level executives report more than 5% revenue increase from AI (McKinsey). 4. The problem is not AI understanding questions but the translation from intent to precise database queries. 5. Separating understanding (AI) from execution (deterministic logic) solves the accuracy problem. ## What goes wrong when AI answers data questions When you ask an AI assistant a data question, it does not look up the answer in a database. It generates a query. It guesses which tables to use, how to join them, and what your business terms mean. Every time you ask, it generates a new query. Consider a simple question: "How many active customers do we have?" To answer this, the AI needs to know which table stores customers, what "active" means in your business (last purchase within 90 days? current contract? logged in this month?), and whether to count parent accounts or individual contacts. The AI does not know any of this. It guesses. And the guess changes depending on how you phrase the question, what context the model has, and sometimes just randomness in the model's output. [Research published on arXiv](https://arxiv.org/abs/2411.07763) shows that large language models achieve less than 50% accuracy on structured enterprise data queries. Less than a coin flip. ## AI is good at language, not at data precision This is not a failure of AI. It is a mismatch between what AI does well and what data queries require. AI excels at understanding intent. When someone asks "show me customers who might churn," the AI understands the concept. It knows the person wants at-risk accounts. That part works. The part that fails is translation. Converting that understood intent into the exact database query that returns the right answer requires knowing your specific schema, your business rules, your access controls, and your data quality issues. These are not things a language model learns from training data. Writing a creative email and writing a precise SQL query are fundamentally different tasks. The first benefits from flexibility and variation. The second requires exactness. Same question, same answer, every time. ## The ROI gap nobody talks about The numbers tell the story. According to [McKinsey](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai), only 19% of C-level executives report more than 5% revenue increase from AI. Only 23% see AI delivering favorable cost changes. [Gartner](https://www.gartner.com/en/newsroom/press-releases/2025-06-gartner-hype-cycle-for-artificial-intelligence) places generative AI in the "Trough of Disillusionment." The hype peaked. Reality set in. Organizations that invested heavily in AI for data access are discovering that unreliable answers are worse than no answers at all. Inaccuracy is not a minor inconvenience. When the board gets the wrong pipeline number, when finance reports conflicting revenue figures, when a sales director makes decisions based on AI-generated data that turns out to be wrong, trust collapses. And once trust collapses, adoption stops. ## What to look for instead The problem is not AI itself. AI is excellent at understanding what people are asking. The problem is what happens after the AI understands the question. If the next step is "generate a query from scratch," accuracy will remain low. The AI has to guess too many things: the right tables, the right joins, the right business definitions, the right access controls. The alternative is separating understanding from execution. Let AI do what it is good at: interpret the question. Then hand execution to a system that uses predefined, tested logic to get the answer. Same question, same answer, every time. No guessing. When evaluating AI data access solutions, look for these qualities: - Business definitions established once and enforced everywhere - Access controls that apply regardless of who or what is asking - Audit trails showing exactly what logic produced each answer - Consistent results: the same question always returns the same answer AI will keep getting better at understanding questions. The organizations that figure out the execution side first will be the ones that actually see ROI from their AI investments. For a deeper look at the two main approaches, [read the comparison of template-based data access and text-to-SQL](https://dhino.io/blog/template-based-vs-text-to-sql). --- title: Why data and AI investments underperform | dhino description: Only 19% of executives see revenue gains from AI. The problem is not the AI. It is the broken data layer underneath. Learn the four root causes and what to fix first. url: https://dhino.io/blog/why-data-ai-investments-underperform/ --- Blog # Why your data and AI investments are not paying off February 18, 2026 The budget was approved. The tools were deployed. The consultants delivered their roadmaps. Six to twelve months later, the board is asking a question nobody wants to answer: where are the results? According to [McKinsey's State of AI report](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai), only 19% of C-level executives report more than a 5% revenue increase from AI. Only 23% see AI delivering favorable cost changes. The rest are spending money and hoping the next upgrade fixes things. It will not. ## Key takeaways 1. Only 19% of C-level executives report more than 5% revenue increase from AI, and only 23% see favorable cost changes (McKinsey). 2. Most AI underperformance traces back to the data layer, not the AI models themselves. 3. Fragmented systems, inconsistent definitions, missing governance, and manual handoffs are the four root causes. 4. Adding more AI tools on top of a broken data foundation accelerates waste, not value. 5. Fixing the data layer first is the prerequisite for AI investments to pay off. ## The spending is real, the returns are not Enterprise AI spending has grown year over year since 2023. Budgets for data platforms, analytics tools, and AI assistants keep expanding. But the results have not kept pace. In most organizations, the gap between what was promised and what was delivered is growing, not shrinking. [Gartner](https://www.gartner.com/en/newsroom/press-releases/2025-06-gartner-hype-cycle-for-artificial-intelligence) now places generative AI in the "Trough of Disillusionment." That is a polite way of saying that many organizations invested heavily based on vendor promises and are now confronting reality. The instinct is to blame the AI. The models are not mature enough, the reasoning is not good enough, the next version will be better. But the pattern repeats regardless of which model you use. The problem is not the intelligence layer. The problem is everything underneath it. ## Four reasons the data layer breaks AI investments When AI investments disappoint, the root cause almost always sits in the data layer. Not in the AI models, not in the team's skills, not in the vendor's product. Here is where it actually breaks down. ### 1\. Data is scattered across too many systems The average enterprise runs dozens of data-producing systems. CRM, ERP, marketing platforms, finance tools, HR systems, custom applications. Each one stores data in its own format with its own schema. Asking AI to reason across this landscape is like asking someone to write a report using books in five different languages with no translator. ### 2\. Business definitions are not consistent What is an "active customer"? Ask marketing, sales, and finance and you will get three different answers. These definitions live in people's heads, in scattered spreadsheets, in tribal knowledge that never gets transferred into systems. When AI encounters this ambiguity, it picks an interpretation. Sometimes it picks the right one. Often it does not. And nobody catches the error until the board deck has the wrong number in it. ### 3\. Governance is missing or manual [Data governance](https://dhino.io/glossary/data-governance) in most organizations means someone manually reviewing access requests and hoping the rules are followed. There is no automated layer enforcing who can access what data, under what conditions, with what audit trail. Without this layer, every new AI tool is a potential compliance risk. ### 4\. Manual handoffs kill speed and accuracy Business teams need data. IT teams prepare it. This handoff takes days or weeks. By the time the data arrives, the question has changed or the window has closed. AI was supposed to fix this, but if the AI relies on the same manual preparation pipeline, it inherits the same delays. Faster intelligence on top of slow infrastructure just means you wait slightly less while still getting inconsistent answers. ## Why adding more AI makes the problem worse The natural response to disappointing AI results is to invest in better AI. Upgrade the model. Add another tool. Hire a prompt engineer. This feels productive. It is not. Every new AI tool you deploy connects to the same broken data layer. It encounters the same scattered systems, the same ambiguous definitions, the same governance gaps. It just encounters them in new and creative ways. [Research shows LLMs achieve less than 50% accuracy](https://dhino.io/blog/why-ai-gets-enterprise-data-wrong) on structured enterprise data queries. Better models improve this margin incrementally. They do not solve it. Worse, each new tool multiplies the problem. Now you have three AI assistants giving three different answers to the same question, each confident, each pulling from a different slice of your fragmented data landscape. Finance's AI says revenue grew 12%. Sales says 8%. The CEO's dashboard says 10%. Nobody knows which one is right. This is not an AI problem. This is an infrastructure problem wearing an AI mask. ## What a functioning data layer actually looks like The organizations that do see returns from their AI investments share a common trait. They fixed the data layer first. Not by buying another tool, but by building (or adopting) an abstraction layer between their raw data and everything that consumes it. A functioning [data layer](https://dhino.io/glossary/semantic-data-layer) has specific characteristics. Business definitions are established once and used everywhere, so "active customer" means the same thing regardless of who (or what) is asking. Access controls are enforced automatically, not through manual review. Audit trails track every data request so compliance teams can verify what happened and when. Most importantly, the layer separates understanding from execution. AI can interpret questions (it is excellent at that). But the actual data retrieval should run through [deterministic, tested logic](https://dhino.io/glossary/deterministic-execution) that returns the same answer every time. Same question, same answer. No guessing. When this layer exists, AI works. Not because the models got smarter, but because the foundation is solid. Every AI tool, every dashboard, every integration consumes the same governed data. Consistency replaces chaos. The question for leadership is not "should we invest more in AI?" It is "have we built the data foundation that makes AI investments pay off?" If the answer is no, more spending on AI will produce the same disappointing results. Fix the layer underneath first. The returns follow. For a closer look at how different approaches to this problem compare, [read the comparison of template-based data access and text-to-SQL](https://dhino.io/blog/template-based-vs-text-to-sql). --- title: How dhino compares - text-to-SQL, semantic layers, Microsoft Fabric description: dhino sits in a different layer than most tools it gets compared to. See how it differs from text-to-SQL and semantic layers, and where it fits alongside Microsoft Fabric. url: https://dhino.io/compare/ --- # How dhino compares dhino is a governed access layer, not a data platform or a query generator. Here is how it differs from the tools it gets compared to, and where it fits alongside Microsoft Fabric. ## The short answer Every request to dhino runs a pre-defined template with deterministic execution. The same question returns the same answer, for every consumer, with field-level access and audit trails built in. That is the core difference. ## dhino vs text-to-SQL Text-to-SQL generates a query at runtime and hopes it is right. dhino runs pre-defined templates. That distinction decides everything else. Text-to-SQL dhino Generates a SQL query at runtime from natural language Executes a pre-defined template with parameterized logic Accuracy degrades on complex schemas; results can vary each time Same question, same answer, every time. Deterministic. Governance is applied at the query level, often as a prompt Field-level access, role-based permissions, and audit trails built in Primarily a tool for developers and analysts One layer for business users, applications, and AI agents Good for ad-hoc exploration Built for production data access [What is text-to-SQL?](https://dhino.io/glossary/text-to-sql) [Read the full comparison](https://dhino.io/blog/template-based-vs-text-to-sql) ## dhino vs a semantic layer A semantic layer describes how to query the data. dhino executes against the data. They overlap on modeling; they diverge on execution. Semantic layer dhino Describes the data: entities, metrics, joins Executes against the data through parameterized templates Still relies on generated queries underneath No runtime generation. Templates are tested and fixed. Better UX than raw SQL, same execution risk No execution risk. Same template, same result. Typically consumed by BI tools Consumed by humans, applications, and AI agents through one layer [What is a semantic data layer?](https://dhino.io/glossary/semantic-data-layer) ## dhino and Microsoft Fabric Fabric is a data platform: lakehouse, compute, BI. It is Microsoft's answer to Databricks and Snowflake. dhino is a governed access layer that sits on top of whatever data you have, Fabric included. Fabric is where data lives. dhino is how it gets served to the people, applications, and AI agents that need it. A Fabric customer is typically a strong fit for dhino: Fabric gives them the data, dhino gives every consumer a governed path to it. The categories dhino actually displaces: text-to-SQL tools, hand-rolled semantic layers, and the "every team builds its own governed API" pattern. ## Going deeper If you are evaluating MCP servers for Dataverse, the differences between Microsoft's standard implementation and a governed alternative shape what AI agents can do safely. [Dataverse MCP server: dhino vs Microsoft](https://dhino.io/compare/dataverse-mcp) ## Frequently asked questions Is dhino a competitor to Microsoft Fabric? No. Fabric is a data platform: lakehouse, compute, BI. dhino is a governed access layer above whatever data you have. A Fabric customer is typically a strong fit for dhino, because Fabric gives them the data and dhino gives every consumer a governed path to it. When is text-to-SQL the right choice? For ad-hoc data exploration by SQL-literate analysts, where an occasional wrong answer is acceptable. Text-to-SQL is fast for one-off questions in known schemas. For production data access, recurring questions, or any consumer who cannot read SQL to verify the answer, deterministic templates are safer. Does dhino replace a semantic layer? It overlaps on modeling and diverges on execution. A semantic layer describes how to query data; dhino executes pre-defined templates against it. If you already run a semantic layer for BI, dhino sits beside it to serve governed data to humans, apps, and AI agents. If you do not have one yet, dhino replaces the "every team builds its own data API" pattern without adding a separate semantic layer. How is dhino different from a stored procedure or a hand-rolled API? The mechanism is similar: a pre-defined operation that parameters can be passed to. The difference is scope. A stored procedure lives in one database and serves one application. dhino templates serve every consumer (Fetch, Trust, Integrate, Publish) through one governed layer, with field-level access, role-based permissions, audit trails, and observability built in. Most teams end up rebuilding all of that for every new API; dhino does it once. Why does runtime generation versus pre-defined templates matter? Generated queries can drift. The same question on Monday and Friday may produce different SQL because the model interpreted the prompt differently. Pre-defined templates are tested, fixed, and parameterized. Same inputs return the same outputs every time. For business-critical data, that determinism is the difference between trustworthy answers and confident guesses. ## Talk to us about where dhino fits Every data environment is different. Tell us what you are running and we will tell you honestly where dhino fits and where it does not. --- title: Dataverse MCP server: dhino vs Microsoft compared | dhino description: Compare dhino's Dataverse MCP server with Microsoft's standard MCP server for Dataverse. Per-agent access, custom actions, multi-source data, full audit. url: https://dhino.io/compare/dataverse-mcp/ --- # dhino's Dataverse MCP server vs Microsoft's Microsoft ships a standard Dataverse MCP server. dhino ships one too. They both connect AI agents to Dataverse, but they govern that access very differently. Here is what changes when you pick dhino. ## Why a second MCP server exists at all Once you point Copilot Studio, the Microsoft Agent Framework, or any other agent at Dataverse through the standard [MCP server](https://dhino.io/glossary/model-context-protocol), the agent inherits whatever the calling user can reach. That is fine for a demo. In production it means an agent built for one task can read every table the user has rights to, write back as that user, and leave a single audit trail that says "the user did it." The questions stack up quickly. Who is accountable when an agent updates the wrong record? How do you scope what one agent can do versus another? How do you call your own business logic instead of letting the model figure CRUD out on the fly? How do you bring in payment data from Business Central without standing up a second MCP server and reconciling its identity model? That is the gap dhino's Dataverse MCP server fills. Same protocol. Different [governance layer](https://dhino.io/glossary/data-governance). ## The short answer The Microsoft Dataverse MCP server and the dhino Dataverse MCP server both implement Model Context Protocol over Microsoft Dataverse, but they govern agent access differently. Microsoft's server gives an agent the same reach as the user who invoked it, over standard CRUD, over Dataverse alone. dhino's server narrows that down per agent, exposes your own business actions as named tools, can include data from outside Dataverse, and logs what the agent did, not just what the user did. Same protocol. Different governance layer. ## Feature comparison Both servers speak MCP. The difference is what they let an agent see, do, and prove. Read the table left-to-right per row to see what you give up by sticking with the standard server, and what you gain by adding dhino on top. Microsoft Dataverse MCP server dhino Dataverse MCP server Surfaces Dataverse CRUD verbs (create, read, update, delete). Each verb can be turned on or off, but the toggle applies across all tables the user can reach. Per-agent, per-table, per-action scoping. One agent reads Accounts and updates Cases. Another agent has its own scope, defined separately. As of May 2026, the standard server surfaces built-in CRUD verbs only. Dataverse Custom APIs and Custom Actions are not registered as named MCP tools in its public capability set. Custom Business Actions and Dataverse Custom APIs are registered as named MCP tools. The agent calls defined business logic, not a CRUD chain that has to approximate it. By default, the agent acts under the invoking user's Dataverse permissions. The agent's effective rights match whoever invokes it, so an admin invocation gives the agent admin-level rights for that call. Agents authenticate to dhino with their own credentials. The scope granted to the agent is separate from what the invoking user can see, so the same person can use different agents with different access without juggling role assignments. Row-level visibility follows the user's Dataverse security roles. Tightening per agent means duplicating roles for every agent. Row-level and field-level filters configurable per agent. "Only this department," "only active records," or "only the user's own opportunities" are all expressible without inventing new security roles. Microsoft's Dataverse MCP server is scoped to Dataverse. Combining data from other sources means running and connecting to a separate MCP server per source. One dhino MCP server can combine Dataverse with Business Central, Power BI, or other sources behind a single endpoint. For the agent it looks like one data source. No durable context layer. Each agent has to be prompted with what entities mean and how they relate. dhino carries durable context: domain concepts ("lease agreement," "qualified opportunity") are defined once with their tables, relationships, and rules, then reused across agents and use cases. Standard Dataverse auditing captures record-level changes against the invoking user. There is no separate audit dimension for the agent itself. Per-agent audit trail of MCP tool calls, including the call inputs and the result. Each agent's activity can be reviewed independently of the user that invoked it. ## Which Dataverse MCP server should you use? The Microsoft server is the right starting point for many scenarios. dhino is what you add when the governance shape changes. ### Use Microsoft's Dataverse MCP server when - A single agent acting with the calling user's full permissions is the right shape. - CRUD over standard tables is enough; you do not need to expose custom business logic. - A single audit dimension (the user) is sufficient for compliance. - You only need to reach Dataverse, not other data sources. Pricing note: as of December 15, 2025, MCP tool calls from agents created outside Copilot Studio are charged unless covered by a qualifying Dynamics 365 Premium or Microsoft 365 Copilot USL license (Dynamics 365 data only). See FAQ below. ### Use dhino's Dataverse MCP server when - You are building more than one agent and they need different access. - You want to expose Custom Business Actions and Custom APIs, not just CRUD. - You need the agent's identity and rights to be separate from the invoking user. - You need per-agent audit trails or one endpoint that spans multiple sources. ## Example: a lease management agent The table lists capabilities. Here is what they look like when an agent has actual work to do. With Microsoft's server, the agent reads and writes any Dataverse table the invoking user can reach, using standard CRUD. If the user is an admin, so is the agent. If delete is enabled for the user, the agent can delete. Custom logic in Dataverse, like a tested "RenewLeaseContract" [action](https://dhino.io/glossary/deterministic-execution), is not callable. Combining Dataverse data with payment records in Business Central means a second MCP server and a second integration. With dhino, the same agent is scoped to LeaseAgreements (read and update), Documents (read), and BillingEvents (create), and nothing else. It cannot delete in any table, regardless of what the user could do directly. It calls "RenewLeaseContract" by name. Payment context from Business Central comes through the same endpoint. Every call by the agent is logged with inputs and outcome, so "the lease agent did it" is a sentence you can actually defend in an audit. Configuration sits with whoever owns the platform: scopes, action allow-lists, and source mappings are defined once per agent in dhino, not duplicated across security roles in Dataverse. The same configuration pattern underpins [data access templates](https://dhino.io/glossary/data-access-templates) elsewhere in dhino. Same protocol either way. The difference is whether "the lease agent did it" is a sentence you can actually say in an audit, and whether the next agent you build inherits the same controls or starts from zero. ## Related reading - Background on the protocol itself: [what is Model Context Protocol?](https://dhino.io/glossary/model-context-protocol) - Why durable templates matter: [data access templates](https://dhino.io/glossary/data-access-templates) - How this fits a Copilot Studio build: [governed enterprise data for Copilot Studio agents](https://dhino.io/blog/copilot-studio-governed-data) - Other Dataverse access methods compared: [Dataverse data access methods](https://dhino.io/blog/dataverse-data-access-methods) - MCP in the enterprise: [what MCP means for enterprise data teams](https://dhino.io/blog/mcp-enterprise-data-access) ## Frequently asked questions What is a Dataverse MCP server? A Dataverse MCP server is a Model Context Protocol endpoint that lets AI agents read and act on Microsoft Dataverse data through a defined set of tools. Microsoft ships one. dhino ships one. Both speak the same protocol; what differs is which tools they expose and how they govern who can call them. Is dhino replacing Microsoft's Dataverse MCP server? No. Both servers speak the same protocol (MCP) over the same data layer (Dataverse). dhino's server is what you connect agents to when you need finer-grained access control, custom business actions, a service identity per agent, multi-source aggregation, or per-agent audit. If a single agent acting with the user's full permissions over standard CRUD is the right shape, the Microsoft server is enough. Why not just use Microsoft's MCP server with strict Dataverse security roles? You can. Dataverse security roles are powerful. The limit is that the agent runs as the calling user, so its permissions are whoever invokes it. Tightening per-agent access through roles means duplicating roles for every agent. dhino keeps the agent's scope separate from the user's, so the same person can invoke different agents with different access without inventing new security roles. Can dhino's MCP server expose data from outside Dataverse? Yes. One dhino MCP server can combine Dataverse with Business Central, Power BI, or other sources behind a single endpoint. For the agent, it looks like one data source. The access rules and audit trail apply across all of them. How are Custom Business Actions different from raw CRUD? Raw CRUD is "create, read, update, delete" against one table at a time. A Custom Business Action is a named operation that wraps tested business logic, often touching multiple tables and applying rules an agent should not have to re-invent. As of May 2026, Microsoft's standard Dataverse MCP server registers only the built-in CRUD verbs; Dataverse Custom APIs and Custom Actions are not surfaced as named MCP tools. dhino's server registers them, so an agent calling "RenewLeaseContract" runs the tested logic for that operation rather than a CRUD chain that has to approximate it. Does dhino's MCP server work with Microsoft Copilot Studio and the Microsoft Agent Framework? Yes. dhino exposes a standards-compliant MCP endpoint. Copilot Studio and the Microsoft Agent Framework both connect to it via the protocol. Other MCP-enabled clients can also connect; we recommend testing your specific client against the endpoint before production. Where does dhino's MCP server run? dhino runs as multi-tenant SaaS on Microsoft Azure, with European data residency available for customers that need it. The MCP endpoint is hosted in the same environment as the rest of the dhino platform; no additional self-hosting is required. Are there costs for using Microsoft's Dataverse MCP server? Yes, in most cases. Starting December 15, 2025, Microsoft charges for Dataverse MCP tool calls made by AI agents created outside Microsoft Copilot Studio. The only exemption is for tenants with qualifying Dynamics 365 Premium licenses or a Microsoft 365 Copilot User Subscription License (USL), and only when accessing Dynamics 365 data through these tools. For current billing rates, see Microsoft's Dataverse MCP documentation. The implication for buyers comparing options: outside Copilot Studio, Microsoft's MCP calls are charged by default. Free use is limited to those specific license tiers, and only for Dynamics 365 data. ## See dhino's Dataverse MCP server in action Bring us one agent you are trying to build or have already shipped. We will walk through the per-agent scope, the custom actions, and the audit trail against your own data, not a demo tenant. See also [how dhino compares overall](https://dhino.io/compare) and [dhino Trust](https://dhino.io/product/trust) . Last verified against Microsoft's Dataverse MCP server: May 2026. --- title: Events - Meet the dhino team in person description: Conferences, meetups, and industry events where the dhino team is presenting, exhibiting, or available to meet. Join us in person. url: https://dhino.io/events/ --- # Meet us in person Conferences, meetups, and community events where the dhino team is presenting, exhibiting, or available to meet. [ ### Nordic Summit ](https://nordicsummit.info/)Speaking Sep 21-22, 2026 Billund, Denmark · Billund [ ### Scottish Summit 2026 ](https://scottishsummit.com/)Speaking Oct 2-3, 2026 Edinburgh, Scotland · Murrayfield Stadium [ ### ESPC Microsoft 365 and AI Conference 2026 ](https://espc.tech/conference/espc-2026/)Speaking Nov 30 - Dec 3, 2026 Amsterdam, Netherlands · RAI Amsterdam --- title: Glossary of enterprise data and AI terms | dhino description: Definitions of key concepts in enterprise data access, AI data governance, and the Microsoft data ecosystem. From semantic data layers to Model Context Protocol. url: https://dhino.io/glossary/ --- Glossary # Enterprise data and AI terms Practical definitions for the concepts behind governed data access. Written for IT professionals, data teams, and enterprise architects working with Microsoft Dataverse, Power Platform, and AI systems. [ ## Agent Guardrails The mechanisms that constrain what an AI agent backed by a large language model is allowed to do. Guardrails operate at four layers: input, model, output, and tool calls. Only the tool-call layer holds deterministically when the prompt is broken. ](https://dhino.io/glossary/agent-guardrails)[ ## Data Access Templates Predefined, governed data operations that carry business logic, table relationships, and access rules into reusable units. Consumers select a template and supply parameters instead of writing or generating queries. ](https://dhino.io/glossary/data-access-templates)[ ## Data Governance The set of policies, processes, and controls that ensure enterprise data is accurate, consistent, secure, and used appropriately. In practice, it determines who can access what data, under what rules, and with what audit trail. ](https://dhino.io/glossary/data-governance)[ ## Deterministic Execution A data access approach where the same input always produces the same output. In contrast to AI-generated queries, deterministic execution uses predefined templates to guarantee consistent, predictable results. ](https://dhino.io/glossary/deterministic-execution)[ ## Enterprise AI Agent An AI agent designed to operate safely on enterprise systems, distinguished from generic AI agents by governed data access, deterministic execution, scoped credentials per agent, durable domain context, and per-call audit. ](https://dhino.io/glossary/enterprise-ai-agent)[ ## Governed Self-Service Data Access A pattern where business users access enterprise data directly, without writing queries or waiting on IT, while access rules, business definitions, and audit trails are enforced by the platform serving the data. ](https://dhino.io/glossary/governed-self-service)[ ## Metric Definition A documented, executable specification of a business metric, establishing how it is calculated, which records qualify, what the time boundaries are, and who owns it. ](https://dhino.io/glossary/metric-definition)[ ## Microsoft Fabric Microsoft's unified analytics platform: OneLake plus multiple compute engines, Data Factory pipelines, and Power BI in one SaaS environment. Fabric stores, prepares, and analyzes data; governing how downstream consumers reach it per person, agent, or app is a different layer. ](https://dhino.io/glossary/microsoft-fabric)[ ## Microsoft Power Platform A suite of low-code tools from Microsoft, including Power Apps, Power BI, Power Automate, Power Pages, and Copilot Studio, built on top of Microsoft Dataverse for building apps, automating workflows, and deploying AI agents. ](https://dhino.io/glossary/power-platform)[ ## Model Context Protocol (MCP) An open standard for connecting AI systems to external data sources, tools, and services. MCP provides a standardized interface so AI tools can access data without proprietary connectors. ](https://dhino.io/glossary/model-context-protocol)[ ## Parameterized Data Operation A pre-defined data operation that accepts typed parameters and runs the same tested query or business logic every time. Distinct from runtime-generated queries, which can produce different results for the same input. ](https://dhino.io/glossary/parameterized-data-operation)[ ## Policy Enforcement (for LLM Tools) A deterministic layer between an AI agent and the system of record that evaluates each tool call against rules in code and either executes or refuses. Policy enforcement runs outside the model and is not influenced by the prompt. ](https://dhino.io/glossary/policy-enforcement)[ ## Prompt Injection A class of attack where a user manipulates the input to a large language model so the model behaves outside its intended instructions. The injected content can arrive directly from the user or indirectly through data the model is asked to read. ](https://dhino.io/glossary/prompt-injection)[ ## Semantic Data Layer An abstraction layer between enterprise data sources and the consumers that use them. It translates database complexity into business terms, applies governance rules, and provides consistent, trusted answers. ](https://dhino.io/glossary/semantic-data-layer)[ ## Text-to-SQL An AI approach that converts natural language questions into SQL database queries. While powerful for ad-hoc exploration, text-to-SQL faces accuracy challenges on complex enterprise data. ](https://dhino.io/glossary/text-to-sql) ## See these concepts in action Learn how dhino applies these principles to give enterprises a single governed data layer for people, systems, and AI. --- title: What are agent guardrails? | dhino Glossary description: Agent guardrails are the mechanisms that constrain what an AI agent backed by an LLM is allowed to do. The four categories, what each can and cannot prove, and which kind holds when the prompt is broken. url: https://dhino.io/glossary/agent-guardrails/ --- Glossary # What are agent guardrails? Agent guardrails are the mechanisms that constrain what an AI agent backed by a large language model is allowed to do. They sit at four layers: input, model, output, and tool calls. Each layer catches a different class of misuse with a different degree of confidence. The interesting question is not whether to have guardrails. It is which layer carries the load. The first three operate on text and can in principle be defeated by a [prompt injection](https://dhino.io/glossary/prompt-injection). The fourth operates on the action and does not. ## The four kinds of guardrails **Input guardrails.** Code that runs before the prompt reaches the model. Pattern matching, classifiers trained to spot adversarial prompts, allow-lists on topics. Raises the cost of obvious attacks. Catches a lot. Cannot catch what it has not seen. **Model guardrails.** The model's own refusal behaviour, shaped by system prompts, fine-tuning, and safety training. The first thing most teams ship and often the only thing. Effective against clumsy prompts; defeatable by a creative one, because the model itself is what is being attacked. **Output guardrails.** Code that runs after the model produces a response. Strip personal data, block disallowed content, refuse output that names confidential systems. Useful, but the response has already happened: a refusal here is a fallback, not a prevention. **Tool-call guardrails.** Code or platform configuration between the agent and the system of record. When the agent asks to call a tool, this layer evaluates the call against the rules and either executes or refuses. It does not read the chat. It cannot be argued with by a prompt, because the prompt does not reach it. ## Which layer holds when the prompt is broken The first three layers all run as text against text. Each one reduces probability. None of them yields a guarantee, because the attack surface is exactly the same as the defence surface: language. The tool-call layer is structurally different. It is code, not language. It runs on typed parameters, not on the text of the conversation. A rule like "discount percentage must be at most 30" can be checked the same way every time, regardless of how persuasive the user was upstream. The model can be talked into asking; the layer decides whether the ask passes. That is the property that makes [deterministic execution](https://dhino.io/glossary/deterministic-execution) the load-bearing kind of guardrail for agents connected to real systems. ## Defence in depth, honestly All four layers belong in a production stack. Input filters cut volume. Model guardrails keep the easy cases easy. Output filters catch what slipped through. The tool-call layer keeps the consequences bounded. The honest framing: defence in depth works because the bottom layer does not depend on the layers above it succeeding. If the bottom layer is also probabilistic, depth is just more of the same thing. If the bottom layer is deterministic, depth is meaningful. This is the inversion most "AI security" stacks miss. They stack more text-layer defences on top of each other. A jailbroken model that has been told ten times not to do a thing is still a jailbroken model. ## How dhino implements tool-call guardrails dhino exposes data and business actions to AI agents through [Model Context Protocol](https://dhino.io/glossary/model-context-protocol) tools. Each tool is a named action with typed parameters. The agent never reaches the underlying database; it can only call the actions the platform has exposed. Above each action sits a [policy enforcement](https://dhino.io/glossary/policy-enforcement) layer: per-agent scoping (which tools may this agent call), per-call rules on parameters (a discount must be no more than 30%, a date range must fit a window), and per-call audit (input parameters and result recorded for review). See [dhino Trust](https://dhino.io/product/trust) for the product overview, and [dhino vs Microsoft's Dataverse MCP server](https://dhino.io/compare/dataverse-mcp) for how this differs from a connector that exposes raw CRUD. ## Common questions about agent guardrails ### What are the different types of AI agent guardrails? Four broad categories. Input guardrails scan or transform what reaches the model. Model guardrails are the model’s own refusal behaviour from system prompts and safety training. Output guardrails scan or transform what leaves the model. Tool-call guardrails are deterministic rules in code or platform configuration, between the agent and the system of record, that decide whether each action is allowed. The first three operate on text; only the last operates on the action. ### Do AI guardrails actually work? It depends on the kind. Text-layer guardrails reduce the probability of misuse but cannot prove a determined prompt will not get through. Tool-call guardrails, because they run in code outside the model, decide the same way every time regardless of how the model was prompted. For an agent that takes real action on enterprise data, this is the only kind whose outcome is auditable. ### What is the difference between a guardrail and a policy? Loose usage treats them as synonyms. The useful distinction: a guardrail is any mechanism that constrains an LLM agent’s behaviour, including text-layer filters and model-level refusals. A policy is a specific rule about what an action may or may not do, enforced in code at the action layer. Every policy is a guardrail; not every guardrail is a policy. ### How do guardrails fit into defence in depth for LLM agents? Each layer of guardrails catches a different failure mode at a different probability. Input and output filters raise the cost of obvious attacks. Model-level refusals catch most clumsy jailbreaks. The tool-call layer is the last line of defence: even if everything above it fails, an action with rejected parameters does not execute. Defence in depth holds when the bottom layer is deterministic, because it does not depend on the layers above it succeeding. ## Related terms [ ### Prompt injection The attack class guardrails are trying to contain. Why text-layer defences can be argued with, and tool-layer ones cannot. ](https://dhino.io/glossary/prompt-injection)[ ### Policy enforcement The specific pattern behind tool-call guardrails: rules in code between the agent and the system of record. ](https://dhino.io/glossary/policy-enforcement)[ ### Deterministic execution The property that makes a guardrail load-bearing under adversarial prompts. ](https://dhino.io/glossary/deterministic-execution) ## See deterministic guardrails in practice Tell us where one of your AI agents calls a real action. We will show you the difference between a guardrail in the prompt and one in the layer below it. --- title: What are data access templates? | dhino description: Data access templates are predefined, governed data operations that define business logic once and serve consistent results to people, systems, and AI. url: https://dhino.io/glossary/data-access-templates/ --- Glossary # What are data access templates? A data access template is a predefined, tested data operation that packages business logic, table relationships, field selections, and access rules into a reusable unit. Instead of each consumer writing or generating queries from scratch, templates provide a governed recipe: use these tables, apply these joins, enforce these filters, respect these access rules. Think of it as the difference between asking someone to cook from memory every time and handing them a tested recipe. The template is created once by someone with domain expertise and reused by everyone else, whether a business user, a connected system, or an AI agent. ## Why enterprises use data access templates Without templates, every data consumer reinvents access. A business user asks IT for a report. An AI assistant generates SQL on the fly. A connected system builds custom API calls. Each approach guesses independently at tables, joins, and business definitions. The result: conflicting numbers, security gaps, and no audit trail. Templates solve this by capturing institutional knowledge once. The person who understands "active customer" (last purchase within 90 days, excluding test accounts, counting parent entities only) writes that logic into a template. Everyone else reuses it. Same definition, same result, every time. This is especially critical when AI enters the picture. A [text-to-SQL](https://dhino.io/glossary/text-to-sql) approach generates a new query for each request, with no guarantee it applies the right business rules. Templates remove the guesswork entirely by providing [deterministic execution](https://dhino.io/glossary/deterministic-execution): same template, same parameters, same answer. ## How data access templates work Three steps from definition to consistent results. 1 ### Template creation A domain expert defines the data operation: which tables, how they join, which fields to return, what filters and business rules apply, and who has permission to use it. 2 ### Parameter binding A consumer selects a template and supplies the variable inputs: a date range, a region, a customer segment. The template logic stays fixed. Only the parameters change. 3 ### Deterministic execution The platform runs the predefined logic with the supplied parameters. Same template plus same parameters always equals same result. Every execution is logged for auditing. ## How dhino implements data access templates dhino uses data access templates as the core mechanism across all four products. Each product applies templates to a different consumer type, but the governing principle is the same: define once, enforce everywhere. [ ### Fetch Business users get self-service access to templates for segmentation, reporting, and data extraction without writing queries. ](https://dhino.io/product/fetch)[ ### dhino Trust AI tools like Microsoft Copilot connect to templates for deterministic answers instead of generating queries from scratch. ](https://dhino.io/product/trust)[ ### Integrate System-to-system data flows run through templates with full governance and audit trails. ](https://dhino.io/product/integrate)[ ### Publish External audiences access template-backed data through governed API endpoints. ](https://dhino.io/product/publish) ## Related terms [ ### Semantic data layer The architectural home for templates that serve every data consumer. ](https://dhino.io/glossary/semantic-data-layer)[ ### Deterministic execution What templates guarantee: same template plus same parameters equals same result. ](https://dhino.io/glossary/deterministic-execution)[ ### Data governance The policies that templates carry into every request as filters, fields, and rules. ](https://dhino.io/glossary/data-governance) ## See data access templates in action Learn how dhino uses templates to give every data consumer governed, consistent access to enterprise data. --- title: What is data governance? | dhino Glossary description: Data governance ensures enterprise data is accurate, secure, and used appropriately. Learn what it means in practice and why most implementations fail. url: https://dhino.io/glossary/data-governance/ --- Glossary # What is data governance? Data governance is the set of policies, processes, and controls that ensure enterprise data is accurate, consistent, secure, and used appropriately. In practical terms, it answers three questions: who can access what data, under what rules, and with what audit trail. Most definitions of data governance focus on organizational policies. That matters, but policies without enforcement are just documents. Effective data governance is enforced by the systems that serve data, not by the people who wrote the policy. ## Why most data governance fails Data governance programs typically start with a policy document. Access rules are defined, data owners are assigned, and compliance requirements are documented. Then everyone goes back to building reports, integrations, and dashboards the same way they always did. The gap is execution. Governance policies live in a document. Data access happens in SQL queries, API calls, Power BI reports, and AI prompts. Unless governance rules are embedded in the data access layer itself, they will be circumvented, forgotten, or misapplied. This becomes especially urgent with AI. When a language model generates SQL to answer a business question, it has no awareness of governance policies. It does not know that interns should not see salary data, or that "active customer" has a specific definition that differs from what the AI might guess. ## What effective data governance looks like Governance that works is built into how data is accessed, not bolted on afterward. ### Access controls Who can see what data is defined once and enforced everywhere. Field-level permissions mean the right people see the right data without manual review per request. ### Audit trails Every data access is recorded. Who accessed what, when, and through which channel. This is not optional when compliance requires it, and it should be automatic, not manually built per system. ### Consistent definitions Business terms like "active customer" or "quarterly revenue" are defined once and used by every report, integration, and AI tool. No conflicting numbers from different departments. ## How dhino builds governance into data access dhino is a data access and governance platform. Governance is not a feature that can be turned on or off. It is built into every data operation the platform executes. Every template inherits access controls. Every request is logged. Every business definition is enforced consistently. This means governance works the same whether a business user runs a report through [Fetch](https://dhino.io/product/fetch), an AI assistant queries data through [dhino Trust](https://dhino.io/product/trust), a system syncs records through [Integrate](https://dhino.io/product/integrate), or a partner accesses data through [Publish](https://dhino.io/product/publish). Same governance. Same rules. Same audit trail. ## Related terms [ ### Semantic data layer The architectural place where governance rules get enforced rather than documented. ](https://dhino.io/glossary/semantic-data-layer)[ ### Data access templates The unit that carries access rules, filters, and definitions into every request. ](https://dhino.io/glossary/data-access-templates)[ ### Microsoft Power Platform Where governance gaps surface most acutely as apps, flows, and AI agents multiply. ](https://dhino.io/glossary/power-platform) ## See governed data access in practice Learn how dhino makes data governance a built-in property of every data operation, not a policy document that gets ignored. --- title: What is deterministic execution? | dhino Glossary description: Deterministic execution means the same input always produces the same output. Learn why this matters for enterprise data access and AI accuracy. url: https://dhino.io/glossary/deterministic-execution/ --- Glossary # What is deterministic execution in data access? Deterministic execution means the same input always produces the same output. When someone asks "How many active customers do we have?", a deterministic system runs the same predefined logic every time and returns the same answer. No variation, no surprises. This is the opposite of how most AI systems handle data queries today. Large language models generate SQL or query logic on the fly. The same question asked twice can produce different queries and different answers. That is non-deterministic execution. ## Why deterministic execution matters Non-deterministic query generation works for creative tasks. It does not work for business-critical data operations. When the board asks for quarterly revenue, the finance team cannot accept "approximately right." They need exactly right, every time. The problem intensifies with AI. When a sales director asks Copilot for pipeline data, a text-to-SQL approach generates a new query each time. The same question might join different tables, apply different filters, or miss a business rule. Deterministic execution eliminates this risk by using predefined templates instead of generated queries. This is not a theoretical concern. Research shows that AI systems achieve less than 50% accuracy on structured enterprise data queries when using non-deterministic approaches. [Why AI gets enterprise data wrong](https://dhino.io/blog/why-ai-gets-enterprise-data-wrong) explores this problem in detail. ## Deterministic vs. non-deterministic data access Two fundamentally different approaches to answering data questions. ### Non-deterministic (generated queries) - AI generates a new query for each request - Same question can produce different answers - Business rules may be missed or misapplied - Difficult to audit or predict behavior - Good for: exploration and ad-hoc questions ### Deterministic (template-based) - Predefined template runs the same logic every time - Same question always produces the same answer - Business rules defined and enforced - Fully auditable and predictable - Good for: business-critical operations ## How dhino uses deterministic execution dhino separates understanding from execution. The first stage is non-deterministic: a human or AI interprets what is being asked. The second stage is deterministic: dhino executes a predefined, governed template to deliver the answer. This separation means AI tools like Microsoft Copilot can do what they are good at (understanding natural language) while dhino does what it is good at (delivering exact, governed data). No hallucinations on business-critical data. [See how dhino Trust applies deterministic execution to Copilot data access.](https://dhino.io/product/trust) ## Related terms [ ### Text-to-SQL The non-deterministic alternative that generates a fresh query for every request. ](https://dhino.io/glossary/text-to-sql)[ ### Data access templates The reusable units that make deterministic execution possible at enterprise scale. ](https://dhino.io/glossary/data-access-templates)[ ### Model Context Protocol The open standard that connects AI tools to deterministic data operations. ](https://dhino.io/glossary/model-context-protocol) ## See deterministic data access in action Learn how dhino delivers exact, governed answers to every data question, whether asked by a person, system, or AI. --- title: What is an enterprise AI agent? | dhino Glossary description: An enterprise AI agent is an AI agent built to operate safely on company data, with governed access, scoped credentials, and a per-call audit trail. url: https://dhino.io/glossary/enterprise-ai-agent/ --- Glossary # What is an enterprise AI agent? An enterprise AI agent is an AI agent designed to operate safely on enterprise systems. It reads, writes, and acts on company data the way a member of staff would: under a defined scope, against tested operations, with every action recorded. What separates an enterprise AI agent from a generic AI agent is not the model behind it. It is the access layer the agent operates through. Five properties show up in every production deployment: governed data access, deterministic execution against tested operations, scoped credentials per agent, durable domain context, and a per-call audit trail separate from the invoking user. ## What makes an agent enterprise-ready Three properties decide whether an agent belongs in production or stays in a demo. ### Per-agent scoping Per-agent, per-table, per-action access. One agent reads Accounts and updates Cases. Another agent has its own scope, defined separately. The agent's reach does not inherit the invoking user's full permissions. ### Deterministic execution The agent calls tested operations with typed parameters. The same question always produces the same answer. No runtime SQL generation that can drift on rephrased questions. ### Per-call audit Every tool call is logged with inputs and result, attributed to the agent itself, not collapsed into the user that invoked it. "The lease agent did it" is a sentence the audit can support. ## Why generic AI agents fall over in production Most current agent tools were written for demos and pushed into production with the same shape. Three failure patterns recur, and each one breaks something real. The first is CRUD under the invoking user. The agent gets create, read, update, and delete verbs across every table the user can reach. An admin runs the agent, and for the duration of that call the agent has admin rights. There is no way to say "this agent reads accounts but never writes them." The second is runtime SQL generation. The agent exposes one "query the database" operation and asks the model to write the SQL. The same question can return two different queries on different days, with no guarantee that either is correct. This is the [deterministic execution](https://dhino.io/glossary/deterministic-execution) gap. The third is no per-agent audit dimension. The data system logs whoever invoked the call. If the agent is acting as the user, the audit says the user did it. After the fact, there is no way to ask "what did the lease agent touch this week," because the lease agent does not exist as a distinct actor in the log. ## The protocol layer and the governance layer [Model Context Protocol](https://dhino.io/glossary/model-context-protocol) (MCP) is the connectivity standard that lets any agent talk to any tool. It defines how the agent discovers a tool, calls it with parameters, and reads the result back. MCP solves the integration problem. MCP does not, on its own, decide who can call which tool, what data that tool can reach, or how the call is audited. Those are governance questions. They live in the layer above the protocol, in whatever serves the tool. An enterprise AI agent is one whose tools are served by a governance layer that enforces per-agent scoping, deterministic execution, durable context, and per-call audit. The protocol is the same as in a demo. The layer above it is what makes the agent fit for production. ## How dhino delivers an enterprise AI agent [dhino Trust](https://dhino.io/product/trust) is the governance layer above MCP. Agents authenticate with their own credentials. Each agent has its own per-table, per-action scope. Tools are named operations carrying tested business logic, not raw CRUD. Every call is logged with inputs and outcome against the agent itself. For a concrete capability comparison against Microsoft's standard offering, see [dhino's Dataverse MCP server vs Microsoft's](https://dhino.io/compare/dataverse-mcp). For the architectural case, read [how AI agents should access enterprise data](https://dhino.io/blog/ai-agents-and-enterprise-data). ## Related terms [ ### Model Context Protocol The connectivity standard that lets any agent talk to any tool. dhino sits above it as the governance layer. ](https://dhino.io/glossary/model-context-protocol)[ ### Deterministic execution The property that separates an enterprise-ready agent from one that hallucinates SQL. ](https://dhino.io/glossary/deterministic-execution)[ ### Data governance What the access layer above MCP enforces per agent, beyond what the protocol itself defines. ](https://dhino.io/glossary/data-governance) ## See a governed agent against your own data Bring one agent you are trying to build or have already shipped. We will walk through the per-agent scope, the tested operations, and the audit trail against your data, not a demo tenant. --- title: What is governed self-service data access? | dhino Glossary description: Governed self-service is the access layer below BI: business users get data directly, while access rules, business definitions, and audit trails are enforced by the platform. url: https://dhino.io/glossary/governed-self-service/ --- Glossary # What is governed self-service data access? Governed self-service data access is a pattern where business users reach enterprise data directly, without writing queries or waiting on IT, while access rules, business definitions, and audit trails are enforced by the platform serving the data. The self-service part means the user picks an operation and runs it. The governed part means the rules around that operation are not optional. The distinction that matters is between self-service BI and governed self-service for data access. Self-service BI tools like Power BI and Tableau put dashboards in the hands of business users. Governed self-service for data access sits one layer down: it governs how the BI tool, the AI agent, and the partner API all reach the underlying data through one shared path. ## Why self-service alone is not enough Most enterprises already practice self-service. Excel exports run from CRM into a shared folder. Ungoverned BI workspaces let analysts build their own datasets. Departmental "data marts" hold copies of production data with definitions that drift over time. People get answers; the question is what those answers cost. Two costs recur. The first is the cross-department-consistency problem: when every department maintains its own copy of the data with its own definitions, Sales, Marketing, and Finance report different numbers for the same metric. Leadership cannot tell which is right. The second is the audit problem. When data leaves the system into Excel files, into personal BI workspaces, into copies that nobody tracks, there is no log of who saw what. For any data subject to compliance, the gap is no longer a convenience problem; it is a defensibility problem. ## What governed self-service requires Three properties move the pattern from convenient to defensible. ### Pre-defined operations with typed parameters The user picks an operation IT has approved and supplies parameters. No hand-written SQL, no runtime query generation. The business logic is fixed; only the parameters change. ### Role-based access enforced at the layer Who can call which operation and which rows they see are decided once, in the access layer. The same rules apply whether the user is in BI, in a Power App, or in an AI assistant. ### Audit and lineage automatic Every call is logged with who asked, which operation, which parameters, and what came back. The log is a property of the platform, not something each consumer has to build. ## The access-layer-below-BI distinction Self-service BI tools are visualization. They turn a dataset into a dashboard a user can read. They are excellent at what they do, and they keep doing it. Governed self-service is the access layer below the BI tool. It governs what data the BI tool reads in the first place, applies the access rules and metric definitions once, and serves the same governed operations to other consumers: the AI agent answering a sales question, the partner API reading a customer's own data, the Power App showing a record to a service rep. The BI tool, the AI agent, and the partner API all see the same definition of "active customer" because they all read it from the same place. The user does not pick which definition to trust; there is only one. ## How dhino delivers governed self-service [dhino Fetch](https://dhino.io/product/fetch) is governed self-service for data access. IT defines templates that carry the operation, its access rules, and its business definitions. Business users pick a template, supply parameters, and get the result. The [marketing segmentation scenario](https://dhino.io/product/fetch/marketing-segmentation) walks through this end to end. For a longer treatment of the pattern, see [how to build governed data segments without waiting on IT](https://dhino.io/blog/governed-data-segments-without-it). ## Related terms [ ### Data governance The rules governed self-service is built to honor automatically. ](https://dhino.io/glossary/data-governance)[ ### Data access templates The reusable unit that makes self-service safe at scale. ](https://dhino.io/glossary/data-access-templates)[ ### Semantic data layer The architectural place where self-service stops being risky. ](https://dhino.io/glossary/semantic-data-layer) ## Give your business users a governed path Tell us where self-service is leaking today: Excel exports, drifting BI definitions, ungoverned data marts. We will show you what a governed access layer changes. --- title: What is a metric definition? | dhino Glossary description: A metric definition is a documented, executable specification of a business metric that every department reads the same way, so cross-department reports agree. url: https://dhino.io/glossary/metric-definition/ --- Glossary # What is a metric definition? A metric definition is a documented, executable specification of a business metric. It establishes how the metric is calculated, which records qualify, what the time boundaries are, and who owns it. The same definition is read by every report, integration, and AI tool that uses the metric. Take "active customer." A useful metric definition for this term names the qualifying conditions explicitly: account status equals active, a purchase has occurred in the last twelve months, no termination notice is on file. It names the time window. It names an owner. Without that specification, Sales counts active customers one way, Marketing another, and Finance a third. ## Why metric definitions matter When teams calculate the same metric differently, Sales, Marketing, and Finance each report different numbers to leadership for what is supposedly the same question. The argument that follows is rarely about the data. The data is fine. The argument is about whose definition counts. The cost shows up in three places. Decisions stall because nobody agrees which number is the right one. AI assistants give conflicting answers when asked the same question in different parts of the business. Audit conversations get stuck on which calculation applied at which point in time. A captured metric definition removes the argument. The number is the number because the definition is the definition, written down, owned, versioned. ## What a good metric definition includes Three properties make a definition something every consumer can rely on. ### Name and scope A clear name and a plain-language description of what the metric counts. The business meaning sits next to the calculation, so a reader does not need to reverse engineer the SQL to understand the intent. ### Qualifying conditions and time window The exact criteria a record must meet. The time window the metric applies to. Edge-case decisions named, not left to the reader: how renewals count, how cancellations within the window behave, how partial periods are handled. ### Ownership and version history A named owner who can answer questions and approve changes. A version history that records when the definition changed and why, so reports from different periods can be compared against the right rule set. ## Where metric definitions live Historically, metric definitions are scattered. The most rigorous ones live in individual Excel models built by a finance analyst who knows the rules by heart. Others live in BI report filters, where a Power BI developer encoded the qualifying conditions inside a measure. Others live in ad-hoc SQL on someone's laptop. Most live nowhere at all and get reinvented on every request. Effective governance puts metric definitions in one shared layer that every consumer reads. The same definition feeds the Power BI dashboard, the AI assistant, the partner API, and the marketing segmentation tool. There is one place to change a definition, and the change reaches every consumer at the same time. That shared layer is the semantic data layer for the organisation. Metric definitions are one of the most important things it captures. ## How dhino captures metric definitions In dhino, a metric definition is captured as part of a data access template. The template names the metric, encodes the qualifying conditions and time window, and binds them to the underlying tables. Every consumer that wants the metric calls the template by name and gets the same answer. A business user pulling a segment through [Fetch](https://dhino.io/product/fetch), a Copilot agent asking through [Trust](https://dhino.io/product/trust), and a partner system reading the same metric through an API all read the same definition. The [cross-department consistency](https://dhino.io/product/trust/cross-department-consistency) scenario walks through this end to end. ## Related terms [ ### Semantic data layer Where metric definitions live so every consumer reads the same one. ](https://dhino.io/glossary/semantic-data-layer)[ ### Data governance What metric definitions are part of: encoded business meaning, not just access rules. ](https://dhino.io/glossary/data-governance)[ ### Data access templates The unit that carries a metric definition into every request. ](https://dhino.io/glossary/data-access-templates) ## Stop arguing about whose number is right Bring us the metric your teams disagree on. We will walk through capturing one definition that every consumer reads. --- title: What is Microsoft Fabric? | dhino Glossary description: Microsoft Fabric is Microsoft's unified analytics platform: OneLake, compute engines, Power BI. Learn what it does and where a governed access layer fits above it. url: https://dhino.io/glossary/microsoft-fabric/ --- Glossary # What is Microsoft Fabric? Microsoft Fabric is Microsoft's unified analytics platform. It combines data engineering, integration, real-time analytics, data science, and business intelligence into a single SaaS environment, built around OneLake, a centralized data lake. Fabric is Microsoft's answer to multi-vendor stacks like Databricks plus Snowflake plus Power BI, packaged into one product. Where Fabric stops is also useful to know. Fabric stores data, prepares data, and analyzes data. It does not, on its own, govern how downstream consumers reach that data per person, per agent, or per application. That is a different layer. ## Why Microsoft Fabric exists Enterprises running on Microsoft typically end up with analytical data scattered across Azure SQL, Dataverse, Synapse, and individual Power BI workspaces. Each lives in its own format with its own access model. Building anything cross-system means stitching pipelines together, copying data into intermediate locations, and reconciling definitions across tools. Fabric collapses that into one platform. OneLake holds all the data in a single open format. Compute engines (Spark notebooks, SQL endpoints, Power BI semantic models) run against the same storage. Data pipelines move data into and around Fabric without exporting to side systems. The result is a unified analytical foundation, particularly attractive to Microsoft-aligned enterprises that already have Power BI and Dataverse. ## What Fabric includes One SaaS environment, many workloads, one shared storage layer. ### OneLake A unified storage layer built on Delta Lake. Every Fabric workload reads and writes here, so the same data is available to engineers, analysts, and BI without duplication. ### Compute engines Spark notebooks for data engineering, SQL endpoints for warehousing, KQL queries for real-time analytics, and Power BI semantic models for reporting, all running over OneLake. ### Pipelines and BI Data Factory moves data into and around Fabric. Power BI sits on top of the semantic models for dashboards, reports, and ad-hoc analysis. ## Where Fabric ends and the access layer begins Fabric is the data platform. It stores data, computes over data, and visualizes data. What it does not do is govern how every downstream consumer reaches that data once it leaves Fabric or Dataverse. Questions Fabric does not answer on its own: - When a Copilot agent asks for "active customers," whose definition wins, and how is it enforced consistently across every consumer that asks? - How does one AI agent get read access to LeaseAgreements while another agent has full CRUD, without duplicating Dataverse security roles? - When a partner-facing app queries data, does it inherit the same business rules and audit trail the internal BI report does? - How do you log per-agent activity separately from per-user activity for compliance? These are access-layer questions. A governed access layer like dhino is a strong fit on top of Fabric: Fabric gives you the data; the access layer gives every consumer a governed path to it. ## How dhino fits with Microsoft Fabric A typical Fabric customer uses dhino above Fabric and Dataverse to expose templates that downstream consumers (people, AI agents, applications, partner APIs) can call. The templates carry business definitions, access rules, and audit. Fabric carries the data and compute. They are complementary, not competing. The same dhino template can serve a business user through [Fetch](https://dhino.io/product/fetch), a Copilot agent through [dhino Trust](https://dhino.io/product/trust), and a partner system through [Publish](https://dhino.io/product/publish), all reading from data that lives in Fabric or Dataverse underneath. For a side-by-side view of where dhino sits relative to Fabric and other tools, see [how dhino compares](https://dhino.io/compare). ## Related terms [ ### Semantic data layer The access-layer pattern that sits above Fabric to serve governed data to every consumer. ](https://dhino.io/glossary/semantic-data-layer)[ ### Data governance What the access layer above Fabric enforces per consumer, beyond what Fabric storage provides on its own. ](https://dhino.io/glossary/data-governance)[ ### Microsoft Power Platform Where most Fabric consumers live: Power BI, Power Apps, Copilot Studio, and Power Automate, all reading from OneLake or Dataverse. ](https://dhino.io/glossary/power-platform) ## See a governed access layer on top of Fabric Tell us what your Fabric and Dataverse setup looks like. We will show you where a governed access layer changes what your downstream consumers can do safely. --- title: What is Model Context Protocol (MCP)? | dhino Glossary description: Model Context Protocol is an open standard for connecting AI systems to data sources. Learn what MCP is, why it matters, and how dhino uses it. url: https://dhino.io/glossary/model-context-protocol/ --- Glossary # What is Model Context Protocol (MCP)? Model Context Protocol (MCP) is an open standard for connecting AI systems to external data sources, tools, and services. Instead of each AI assistant building its own proprietary connectors, MCP defines a shared interface that any AI tool can use to access any compatible data source. Think of MCP as USB for AI. Before USB, every device had its own connector. MCP does the same for AI-to-data connections: one standard protocol instead of dozens of custom integrations. ## Why MCP exists AI assistants like Microsoft Copilot, ChatGPT, and Claude are powerful at understanding questions. But understanding is only half the problem. The other half is getting accurate data to answer those questions. Without a standard protocol, every AI tool needs its own connector to every data source. This creates an explosion of point-to-point integrations, each with its own security model, authentication flow, and data format. MCP replaces this with a single, open interface. MCP is an emerging standard with growing adoption across the AI ecosystem. As more AI tools and data platforms support MCP, the protocol becomes more valuable for enterprises looking to connect AI to their data. ## How MCP works A standard interface between AI systems and data sources. ### Standard interface MCP defines how AI tools request data and how data sources respond. Both sides speak the same language, regardless of vendor or platform. ### Tool discovery AI systems can discover what data and tools are available through an MCP-compatible source. No hardcoded connections. The AI learns what it can access at connection time. ### Vendor-neutral MCP is an open standard. It is not tied to any specific AI vendor, cloud provider, or database. Any AI tool or data source that implements MCP can connect to any other. ## MCP and enterprise data access MCP solves the connectivity problem: how does an AI tool talk to a data source? But it does not solve the governance problem: should this AI tool have access to this data? What business rules apply? Who audits the access? This is where platforms built on MCP add value. dhino is MCP-native, meaning it speaks the protocol natively while adding the governance layer enterprises require: templates that carry business logic, access controls that determine who sees what, and audit trails that record every request. **MCP provides:** standard connectivity between AI tools and data sources. **dhino adds:** governed, template-based execution so AI gets accurate answers without direct database access. [See how dhino Trust uses MCP for governed Copilot access to enterprise data.](https://dhino.io/product/trust) For a side-by-side look at the Microsoft Dataverse MCP server alongside a governed alternative, see [how dhino's Dataverse MCP server compares to Microsoft's](https://dhino.io/compare/dataverse-mcp). ## Related terms [ ### Deterministic execution What turns MCP connectivity into trustworthy answers for business-critical data. ](https://dhino.io/glossary/deterministic-execution)[ ### Data access templates The governed operations an MCP server can expose instead of raw tables. ](https://dhino.io/glossary/data-access-templates)[ ### Semantic data layer The governance layer that sits behind an enterprise-ready MCP server. ](https://dhino.io/glossary/semantic-data-layer) ## See MCP-native data access in action Learn how dhino uses Model Context Protocol to give AI tools governed access to enterprise data. --- title: What is a parameterized data operation? | dhino Glossary description: A parameterized data operation is a pre-defined query or business logic that accepts typed parameters and returns consistent results, in contrast to runtime SQL generation. url: https://dhino.io/glossary/parameterized-data-operation/ --- Glossary # What is a parameterized data operation? A parameterized data operation is a pre-defined data operation that accepts typed parameters and runs the same tested query or business logic every time. The operation is fixed at design time. Only the parameter values change at runtime. This is distinct from runtime-generated queries, such as text-to-SQL output, where the model writes a new query for each request. A parameterized data operation substitutes values into a tested operation; a runtime-generated query writes a new operation. The difference shows up the first time two consumers ask the same question and get different answers. ## What parameterized means in practice Parameterization is runtime substitution of typed values into a tested operation, not runtime generation of new operations. An operation might accept a customer identifier, a date range, and a status filter. Those three parameters are typed: identifier is a string of a defined shape, the date range is a pair of dates, the status is one of an enumerated set. Anything outside those types is rejected before execution. What does not change between calls is the operation itself. The joins, the filters, the calculations, the column projections, all sit in the operation as authored, tested, and reviewed. Two consumers asking the same question with the same parameters get the same answer because the operation is fixed. Failures, when they happen, are predictable. A parameter is out of range, a record is missing, a connection drops. They are not silent semantic drift in the query itself. ## How it differs from text-to-SQL [Text-to-SQL](https://dhino.io/glossary/text-to-sql) converts a natural-language question into a SQL query at runtime. The model decides which tables to read, how to join them, which filters apply, and how to aggregate. The query is new every time. A parameterized data operation reverses the order. The query is written and tested ahead of time by people who know the schema. The model, or the user, picks which operation to call and supplies parameters. The model never writes the query. That distinction is the foundation of [deterministic execution](https://dhino.io/glossary/deterministic-execution). Same input, same output. Reviewable, auditable, repeatable. ## How it differs from a stored procedure Stored procedures are also tested operations with parameters. The shared shape is real. What differs is scope and reach. A stored procedure lives in one database and serves whichever client connects to that database. The client needs database credentials. The procedure executes under the permissions of the connecting login. Access control sits in the database, audit sits in the database, and reuse outside the database means rebuilding the procedure in whatever the next system speaks. A parameterized data operation in a governed access layer serves every consumer through one path: a business user in a self-service tool, an AI agent over Model Context Protocol, an application reading through an API, a partner system through a published endpoint. Access control, business definitions, and audit live in the access layer, not duplicated per consumer. The same operation reaches all of them. For the contrast applied to AI agents specifically, see [dhino's Dataverse MCP server vs Microsoft's](https://dhino.io/compare/dataverse-mcp). ## How dhino runs parameterized data operations In dhino, parameterized data operations are packaged as data access templates. The template carries the operation, the typed parameter list, the access rules, and the business definitions. Consumers supply parameters; the platform runs the operation. The same template feeds [Fetch](https://dhino.io/product/fetch) for business users and [Trust](https://dhino.io/product/trust) for AI agents. The operation is defined once. Every consumer reads from it. ## Related terms [ ### Data access templates The dhino term for parameterized data operations packaged with their business logic. ](https://dhino.io/glossary/data-access-templates)[ ### Deterministic execution The property a parameterized operation guarantees by construction. ](https://dhino.io/glossary/deterministic-execution)[ ### Semantic data layer The architectural place where parameterized operations are defined and reused. ](https://dhino.io/glossary/semantic-data-layer) ## See parameterized data operations in practice Tell us what your consumers are asking for: a report, an AI agent, a partner API. We will show you what one tested operation, parameterized once, looks like across all of them. --- title: What is policy enforcement for LLM tools? | dhino Glossary description: Policy enforcement for LLM tools is a deterministic layer between an AI agent and the system of record. It reads typed parameters, evaluates rules in code or platform configuration, and decides per call whether the action executes. url: https://dhino.io/glossary/policy-enforcement/ --- Glossary # What is policy enforcement for LLM tools? Policy enforcement for LLM tools is a deterministic layer between an AI agent and the system of record. When the agent calls a tool, this layer reads the typed parameters of the call, evaluates them against rules in code or platform configuration, and either executes the call or refuses it. The defining property is independence from the prompt. The layer does not read the chat, does not see the system prompt, and is not asked to make a judgement. It runs the same checks every time, on the same typed inputs, with the same outcome. The conversation can be jailbroken without changing what the policy decides. ## Where the policy lives There are three places a rule can sit in an LLM-based system: in the prompt (model layer), in the tool definition the model is shown (description layer), or in the code or platform configuration that runs deterministically when the tool is called (action layer). Only the third is enforceable in the strict sense. A rule in the prompt is a request to the model. The model usually complies. A sufficiently creative prompt can change that. A rule in the tool description is even weaker: it is documentation, not enforcement. The model is meant to read and respect it, and often does, but nothing stops it from calling the tool with violating parameters anyway. A rule in the action layer is code that runs on each call. The model cannot influence it. The user cannot influence it. The only thing that influences it is whether the parameters and the call context satisfy the rule. ## What makes a policy enforceable Three properties. **Deterministic.** The check produces the same result for the same input, every time. This is what [deterministic execution](https://dhino.io/glossary/deterministic-execution) gives you. The opposite of asking a model to grade itself. **Out of band.** The check runs in code the model does not control, on inputs the prompt cannot rewrite. The tool call carries typed parameters; the policy evaluates those parameters, not the chat that led to them. **Auditable.** The check has an input, an output, and a record. Each call, each decision, each refusal can be read back later. A policy that runs but cannot be inspected is not a policy a business can defend. ## What a policy looks like in practice Take a discount-code tool with two typed parameters: a customer identifier and a discount percentage. The agent can be talked into calling it with any value the user proposes. The policy is enforced when the tool is called: either by a few lines of code in the tool itself, or by a parameter guardrail configured on the tool in the agent platform. Either form produces the same property: the discount percentage is read; if it is greater than 30, the call returns a refusal. Both the input and the outcome are written to an audit log. The same layer can carry other rules, an allowed customer scope or a daily issue limit for instance, each evaluated on typed parameters the same way. No prompt can change those checks, because no prompt reaches them. The agent can be persuaded to ask. The policy decides. ## How dhino runs policy enforcement In dhino, agents talk to enterprise data through [Model Context Protocol](https://dhino.io/glossary/model-context-protocol) tools that map to named actions: read a record, run a parameterised query, call a business operation. There is no path to the underlying database; the agent can only invoke the actions the platform has exposed. Above each action sits the policy layer. Per-agent scoping decides which tools an agent is allowed to call. Per-call rules check parameters: ranges, allow-lists, business constraints. Per-call audit records the input parameters and the result. None of this sits in the prompt. See [dhino Trust](https://dhino.io/product/trust) for the product overview and the [agent guardrails](https://dhino.io/glossary/agent-guardrails) entry for where this layer fits in a defence-in-depth stack. ## Common questions about policy enforcement ### What does policy enforcement mean for an LLM agent? A deterministic layer between the agent and the system of record. When the agent calls a tool, this layer reads the typed parameters of the call, evaluates them against rules in code or platform configuration, and either executes or refuses. The layer does not read the prompt and is not influenced by it. ### How is policy enforcement different from a system prompt rule? A system prompt rule asks the model to behave a certain way. The model usually complies. A determined prompt can talk it out of complying. A policy in the action layer is not asked, it runs. The model can be persuaded to call an action with parameters that violate the policy; the call still does not execute. ### Can a policy layer be bypassed by prompt injection? Not at the policy layer itself, by design. Prompt injection acts on the model. The policy layer sits below the model and evaluates the action, not the conversation. What an injection can do is persuade the model to call an allowed action with parameters the user did not intend. The policy decides whether those parameters are allowed; the prompt cannot change that decision. ### Where should LLM policy enforcement run? Outside the model. In code or platform configuration, on infrastructure the model does not control, before the action reaches the system of record. The two usable places are inside the tool implementation itself or in a layer above it shared across tools. The wrong places are inside the system prompt, inside the model’s training, or in a wrapper that asks the model to check its own work. ## Related terms [ ### Agent guardrails The four layers of defence an LLM agent can have. Policy enforcement is the one that holds when the prompt is broken. ](https://dhino.io/glossary/agent-guardrails)[ ### Prompt injection The attack class a policy layer is designed to bound. The prompt is what the model reads; the policy reads the call. ](https://dhino.io/glossary/prompt-injection)[ ### Deterministic execution The property that lets a policy decide the same way every time. Without it, enforcement collapses back into another probabilistic layer. ](https://dhino.io/glossary/deterministic-execution) ## See policy enforcement on a real action Tell us which action an AI agent of yours needs to call. We will show you what a policy layer above it looks like, and what it refuses when the prompt is broken. --- title: What is Microsoft Power Platform? | dhino description: Microsoft Power Platform combines Power Apps, Power BI, Power Automate, and Copilot Studio on Dataverse. Learn what it is, how it works, and where governance fits. url: https://dhino.io/glossary/power-platform/ --- Glossary # What is Microsoft Power Platform? Microsoft Power Platform is a suite of low-code tools that lets organizations build apps, automate workflows, analyze data, and deploy AI agents without heavy custom development. It includes Power Apps, Power BI, Power Automate, Power Pages, and Copilot Studio, all built on top of a shared data store called [Microsoft Dataverse](https://dhino.io/blog/what-is-dataverse). Power Platform makes building fast. What it does not do well is govern what gets built. As adoption grows, so does the number of apps, flows, reports, and agents accessing enterprise data with limited oversight. That gap between creation speed and [data governance](https://dhino.io/glossary/data-governance) is where most Power Platform challenges begin. ## What Power Platform includes Power Platform is not a single product. It is five tools that share a common data layer and work together as a platform. ### Power Apps Build custom business applications with drag-and-drop interfaces and low-code logic. Used for everything from simple forms to complex process apps. ### Power BI Create reports, dashboards, and analytics from data across multiple sources. The primary way most organizations visualize Dataverse data. ### Power Automate Automate repetitive workflows between systems. Triggers, actions, and conditions connect hundreds of services without writing code. ### Power Pages Build external-facing websites backed by Dataverse data. Used for customer portals, partner sites, and public data publishing. ### Copilot Studio Build and deploy AI agents that can answer questions, trigger actions, and interact with enterprise data through natural language. ## Dataverse: the data backbone Every Power Platform tool reads from and writes to [Dataverse](https://dhino.io/blog/what-is-dataverse). It is a relational data store with built-in security roles, business rules, and a standard data model that Microsoft calls the Common Data Model. Dataverse handles the basics well: row-level security, table permissions, and environment isolation. For a single app or a small deployment, this is often enough. The problem surfaces at scale. When dozens of Power Apps, hundreds of Power Automate flows, and multiple Copilot agents all access the same Dataverse tables, the built-in controls start to show their limits. There is no single view of who is accessing what data, no way to enforce consistent business definitions across tools, and no audit trail that spans the full platform. ## The governance gap in Power Platform Power Platform solves the building problem. It does not solve the governing problem. ### Inconsistent definitions Each Power BI report, Power App, and Copilot agent defines "active customer" or "quarterly revenue" independently. No shared business logic layer exists across tools. ### Fragmented access control Dataverse security roles control table and row access. But they do not govern what data a Power Automate flow exports, what a Copilot agent can surface, or what a Power Pages site exposes. ### No cross-tool audit trail Each tool logs its own activity. There is no unified view of data access across Power Apps, Power Automate, Power BI, and Copilot Studio. Compliance teams cannot answer "who accessed this data?" without checking multiple systems. ## How a governed data layer fits The missing piece in Power Platform is a [semantic data layer](https://dhino.io/glossary/semantic-data-layer) that sits between Dataverse and all the tools consuming its data. Instead of each app, flow, report, and AI agent accessing data directly and defining business logic independently, a governed layer captures those definitions once and enforces them everywhere. This is the approach dhino takes. dhino sits between Dataverse and the consumers that need its data. Business users access governed data through [Fetch](https://dhino.io/product/fetch). AI tools like [Copilot](https://dhino.io/blog/copilot-enterprise-data-access) connect through [dhino Trust](https://dhino.io/product/trust) for deterministic answers. System-to-system data flows run through [Integrate](https://dhino.io/product/integrate) with full audit trails. The result: same data, same definitions, same access controls, same audit trail, regardless of which Power Platform tool is consuming the data. Governance becomes a property of data access, not a policy that each tool owner has to implement independently. ## Related terms [ ### Data governance What Power Platform deployments outgrow as apps, flows, and agents multiply. ](https://dhino.io/glossary/data-governance)[ ### Data access templates Reusable operations that give every Power Platform consumer the same definitions. ](https://dhino.io/glossary/data-access-templates)[ ### Semantic data layer The governed layer that sits between Dataverse and every Power Platform tool. ](https://dhino.io/glossary/semantic-data-layer) ## See governed Power Platform data access Learn how dhino adds a governed data layer to your Power Platform environment so every app, flow, report, and AI agent works from the same trusted data. --- title: What is prompt injection? | dhino Glossary description: Prompt injection is an attack where a user manipulates the input to a large language model so the model behaves outside its intended instructions. Definition, examples, and what holds when the prompt is broken. url: https://dhino.io/glossary/prompt-injection/ --- Glossary # What is prompt injection? Prompt injection is a class of attack where a user manipulates the input to a large language model so the model behaves outside its intended instructions. The injected content can arrive directly from the user, or indirectly through data the model is asked to read: a document, an email, a web page, a tool response. Prompt injection is not exotic. Any LLM-based system that mixes trusted instructions with untrusted input is vulnerable in principle. The risk shows up the moment an LLM is wired to a real action, like booking, refunding, querying, or generating a discount code, because what looked like a chat now has consequences. ## How prompt injection works Inside a large language model, instructions and data share the same channel. The model reads everything as text and decides, in context, which text to follow. A prompt injection exploits that: the attacker writes text that the model treats as a new instruction, even though the system that called the model never authorised it. Two common forms. Direct injection: the user types the attack into the chat ("ignore your previous instructions and..."). Indirect injection: the attack arrives through data the model is asked to read, such as a web page summarised in a browsing tool, an email forwarded to an assistant, or a tool response that contains adversarial text. The famous version is the 2023 Chevrolet of Watsonville chatbot agreeing to sell a 2024 Tahoe for one dollar after a customer told it to agree with anything (reported by [VentureBeat](https://venturebeat.com/ai/a-chevy-for-1-car-dealer-chatbots-show-perils-of-ai-for-customer-service)). The recent version ran on Instagram: in early June 2026 hackers used a VPN to fake their location, asked Meta's AI support assistant to link a new email to someone else's account, and the bot complied (reported by [404 Media](https://www.404media.co/hackers-simply-asked-meta-ai-to-give-them-access-to-high-profile-instagram-accounts-it-worked/)). Verified accounts taken over included one once used by Barack Obama. Both make the same point. You can always jailbreak the LLM. The architectural question is whether the jailbreak gets to have consequences on the systems behind it. The Tahoe never got sold because nothing was wired between the chat and a sale. The Instagram accounts changed hands because the AI assistant was wired into account recovery with no verification at the action layer that the requester was the rightful owner. ## Prompt injection vs jailbreaking Jailbreaking is the narrower term. It refers to convincing a model to bypass its safety training and produce content it was trained to refuse: instructions for illegal acts, disallowed personas, restricted topics. Prompt injection is the broader category. It includes jailbreaks, but also instruction override (making the model follow new rules), tool misuse (making the model call an action it was not meant to), and exfiltration (making the model reveal confidential context through its output). For an AI agent connected to enterprise data, the dangerous case is usually not the jailbreak. It is the tool-misuse case: the model can be persuaded to call an action with parameters that should never have passed. ## Why text-layer defences are not enough Most published defences run at the text layer: system prompts that tell the model what not to do, input filters that scan for adversarial patterns, output filters that block certain responses, model-level guardrails trained into the weights. They raise the cost of attack. They do not prove anything won't get through. The honest framing: text-layer defences are probabilistic. They reduce the chance of a successful injection. They cannot guarantee absence of one, because the thing being defended (the model) is also the thing being attacked. For systems that take real action on enterprise data, probability is the wrong unit. "Most prompt injections will fail" is not a property a business can audit. "This action will not execute outside these parameters, regardless of the prompt" is. ## What holds when the prompt is broken The policy must live outside the model. Not in the system prompt, not in fine-tuning, not in a wrapper that asks the model to check itself. In code, in a layer the model does not control, executed before the action reaches the system of record. This is the role of [policy enforcement for LLM tools](https://dhino.io/glossary/policy-enforcement): between the agent and the data, a deterministic layer evaluates every tool call against the rules, accepts or rejects, and writes the result to an audit log. The model can be persuaded to ask. The layer decides whether the ask is allowed. In dhino, that layer sits on top of [deterministic execution](https://dhino.io/glossary/deterministic-execution) over [Model Context Protocol](https://dhino.io/glossary/model-context-protocol) tools. The agent calls named actions with typed parameters. Rules on parameters, rules on which actions which agents may call, and per-call audit live in the layer, not in the prompt. See [dhino Trust](https://dhino.io/product/trust) for how this works in practice. ## Common questions about prompt injection ### What is the difference between prompt injection and jailbreaking? Jailbreaking is one specific outcome of prompt injection: convincing a model to bypass its safety training. Prompt injection is the broader category, covering instruction override, tool misuse, and exfiltration of confidential context via the output channel. All jailbreaks are prompt injections; not all prompt injections are jailbreaks. ### Can prompt injection be prevented entirely? Not at the model layer. Any defence that runs inside the LLM, such as system prompts, model guardrails, or output filters, can in principle be defeated by a sufficiently creative prompt. The realistic goal is not to make prompt injection impossible, but to ensure the consequences of a successful injection are bounded by a deterministic policy layer that the model cannot influence. ### What is an example of prompt injection in production? In December 2023 a Chevrolet of Watsonville dealership chatbot agreed to sell a 2024 Tahoe for one dollar after a user instructed it to agree with anything and end every reply with "no takesies backsies." The clip hit 20 million views overnight. Any AI agent connected to a real action inherits that failure mode unless the policy lives somewhere the prompt cannot reach. ### How do you protect an LLM agent from prompt injection in production? Treat the model as untrusted. The model decides what to ask for; a deterministic policy layer decides what is allowed. Keep the agent’s permissions narrow, expose only named tools rather than direct database access, and enforce business rules in code, not in the system prompt. This is the pattern behind policy enforcement for LLM tools. ## Related terms [ ### Agent guardrails The categories of defence that try to constrain LLM behaviour, and which kind holds under a broken prompt. ](https://dhino.io/glossary/agent-guardrails)[ ### Policy enforcement The pattern of placing rules in a deterministic layer between the agent and the system of record. ](https://dhino.io/glossary/policy-enforcement)[ ### Deterministic execution Same input, same output. The property that lets a policy layer decide the same way every time, regardless of how the model was prompted. ](https://dhino.io/glossary/deterministic-execution) ## See a policy layer in practice Tell us where one of your AI agents calls a real action. We will show you what a deterministic policy layer above that action looks like, and what it refuses when the prompt is broken. --- title: What is a semantic data layer? | dhino Glossary description: A semantic data layer sits between enterprise data and its consumers. It translates database complexity into business terms with built-in governance. url: https://dhino.io/glossary/semantic-data-layer/ --- Glossary # What is a semantic data layer? A semantic data layer is an abstraction layer between enterprise data sources and the consumers that use them. Instead of giving people, systems, or AI direct access to databases, a semantic data layer translates database complexity into business terms, applies governance rules, and provides consistent, trusted answers. Think of it as a contract. The data layer promises: "Ask me for active customers and you will always get the same definition, the same logic, and the same access controls, regardless of who or what is asking." ## Why enterprises need a semantic data layer Without a semantic data layer, every consumer of enterprise data has to solve the same problems independently. The marketing team writes one query to count active customers. Finance writes a different one. The AI copilot generates a third. All three return different numbers. This is not a data quality problem. The data is fine. The problem is that business logic, access rules, and definitions are scattered across individual queries, reports, and integrations instead of being encoded in a single shared layer. A semantic data layer solves this by establishing business definitions once and enforcing them everywhere. "Active customer" means the same thing whether a person asks in a report, a system requests it via API, or an AI assistant surfaces it in a conversation. ## How a semantic data layer works Three principles that make a semantic data layer work in practice. ### Abstraction Consumers interact with business concepts ("quarterly revenue," "active accounts") rather than database tables, joins, and SQL. The complexity stays hidden. ### Governance Access controls, audit trails, and business rules are applied at the layer, not reimplemented by each consumer. Security is a property of the data access, not an afterthought. ### Consistency Business definitions are established once and shared across all consumers. Whether a person, system, or AI asks the same question, they get the same answer. ## How dhino implements a semantic data layer dhino is a semantic data layer built for enterprises using Microsoft Dataverse and the broader Power Platform ecosystem. It uses templates to define business logic, relationships, and guardrails, then serves that data to any consumer through deterministic execution. This architecture separates understanding from execution. An AI assistant or business user interprets what is being asked (non-deterministic). dhino executes the predefined, governed logic to deliver the answer (deterministic). The result: no hallucinations on business-critical data. [Fetch](https://dhino.io/product/fetch) gives business users direct access to the semantic layer for segmentation, reports, and data exports. [dhino Trust](https://dhino.io/product/trust) connects AI tools like Microsoft Copilot to the semantic layer for trusted, deterministic answers. [Integrate](https://dhino.io/product/integrate) routes system-to-system data flows through the semantic layer with full governance. [Publish](https://dhino.io/product/publish) exposes the semantic layer to external audiences through governed API endpoints. For a side-by-side view of how dhino fits alongside other approaches to enterprise data access, see [how dhino compares](https://dhino.io/compare). ## Related terms [ ### Data governance The policies and controls a semantic layer enforces across every consumer. ](https://dhino.io/glossary/data-governance)[ ### Data access templates The reusable units that carry business logic inside a semantic data layer. ](https://dhino.io/glossary/data-access-templates)[ ### Deterministic execution How a semantic layer returns the same answer every time, regardless of consumer. ](https://dhino.io/glossary/deterministic-execution) ## See a semantic data layer in action Learn how dhino gives enterprises a single governed layer for all data consumers: people, systems, and AI. --- title: What is text-to-SQL? | dhino Glossary description: Text-to-SQL uses AI to convert natural language into database queries. Learn how it works, where it excels, and where it struggles with enterprise data. url: https://dhino.io/glossary/text-to-sql/ --- Glossary # What is text-to-SQL? Text-to-SQL is an AI approach that converts natural language questions into SQL database queries. You ask "How many active customers do we have?" and the AI generates the SQL to answer it. The appeal is obvious: anyone can query a database without knowing SQL. The challenge is equally obvious. The AI has to guess which tables to query, how to join them, and what "active customer" means in your specific database. Get any of these wrong and the answer looks right but is not. ## How text-to-SQL works A large language model receives your question along with a description of the database schema (table names, column names, relationships). It uses this context to generate a SQL query that should answer your question. The query runs against the database and returns results. This works well for simple questions against simple schemas. "Show me all orders from last month" on a database with a single orders table is straightforward. The difficulty scales with complexity: many tables, implicit joins, business-specific definitions, and access control requirements. For a deeper look at why this matters, [read why AI gets enterprise data wrong](https://dhino.io/blog/why-ai-gets-enterprise-data-wrong). ## Where text-to-SQL excels and struggles An honest look at the approach, not a dismissal. ### Where it works well - Simple schemas with clear table and column names - Ad-hoc exploration and data discovery - Questions that map to a single table or simple join - Environments where approximate answers are acceptable ### Where it struggles - Complex schemas with hundreds of tables - Business-specific definitions the AI has not seen - Multi-step queries requiring specific join logic - Situations requiring access control or audit trails - Business-critical data where accuracy must be 100% ## The alternative: template-based data access Template-based data access takes a different approach. Instead of having AI generate queries, business logic is captured once in predefined templates by people who know the data. AI then selects and calls the right template rather than generating SQL. This is the approach dhino uses. The AI understands the question (non-deterministic). dhino executes the predefined logic to get the answer ([deterministic execution](https://dhino.io/glossary/deterministic-execution)). The result is accurate, governed, and auditable, because the query logic was written and tested by experts, not generated on the fly. Neither approach is universally better. Text-to-SQL excels at ad-hoc exploration. Template-based access excels at business-critical operations. Many enterprises will use both, for different purposes. [Read the full comparison](https://dhino.io/blog/template-based-vs-text-to-sql), or [see how dhino compares overall](https://dhino.io/compare). [See how dhino Trust uses template-based access for governed Copilot data queries.](https://dhino.io/product/trust) ## Related terms [ ### Deterministic execution The alternative to generated SQL: same input, same output, every time. ](https://dhino.io/glossary/deterministic-execution)[ ### Data access templates Reusable, governed operations that replace per-request query generation. ](https://dhino.io/glossary/data-access-templates)[ ### Semantic data layer The layer that gives AI tools accurate business definitions instead of raw schemas. ](https://dhino.io/glossary/semantic-data-layer) ## Want accurate AI data access without text-to-SQL risks? See how dhino combines AI understanding with deterministic execution for trusted enterprise data answers. --- title: Imprint - dhino description: Legal imprint for dhino. url: https://dhino.io/imprint/ --- # Imprint Information according to § 5 TMG (German Telemedia Act) ## Company information dhino GmbH Eschelsweg 4 22767 Hamburg Germany ## Contact Email: hello@dhino.io ## Represented by Mats Necker, Tim Thedens ## Registration Commercial register: Hamburg, HRB 197867 ## VAT ID VAT identification number according to § 27a of the German VAT Act: DE462209814 ## Responsible for Content According to § 18 Abs. 2 MStV: Mats Necker, Tim Thedens Eschelsweg 4 22767 Hamburg ## Dispute resolution The European Commission provides a platform for online dispute resolution (OS): [https://ec.europa.eu/consumers/odr](https://ec.europa.eu/consumers/odr) We are not willing or obliged to participate in dispute resolution proceedings before a consumer arbitration board. --- title: Privacy policy - dhino description: Privacy policy for dhino. Learn how we collect, use, and protect your data. url: https://dhino.io/privacy/ --- # Privacy policy Last updated: January 2026 ## 1\. Data Controller dhino GmbH Eschelsweg 4 22767 Hamburg Germany Email: hello@dhino.io ## 2\. Scope of Data Processing This Privacy Policy applies to the dhino website and related services, including contact form submissions and feedback submissions. ## 3\. Data We Collect When you contact us, submit an inquiry, or submit feedback, we may process the following personal data: - Name - Email address - Company name - Any information voluntarily provided in form fields ## 4\. Purpose of Processing We process personal data for the following purposes: - To respond to inquiries and communicate with users - To manage inquiries, product demonstrations, and product updates - To understand user needs and improve our product and services - To operate and secure our website ## 5\. Legal Basis Personal data is processed on the following legal bases under Article 6 GDPR: - Article 6(1)(b) GDPR (performance of a contract or pre-contractual measures), where processing is necessary to respond to requests or manage service inquiries - Article 6(1)(f) GDPR (legitimate interests), where processing is necessary to operate, secure, and improve our website and services - Article 6(1)(a) GDPR (consent), where users voluntarily provide information and explicitly consent to specific processing activities Consent can be withdrawn at any time with effect for the future by contacting us. ## 6\. Hosting, Infrastructure, and Security Our website is built using Astro and is hosted via Cloudflare. Cloudflare acts as a data processor and provides content delivery, security, and protection against abuse. In this context, Cloudflare automatically collects and stores information in so-called server log files, which your browser transmits automatically. This technical data includes: - IP address - Browser type and version - Operating system - Referrer URL and host name of the accessing computer - Date and time of access - Other similar data and information that serve to prevent attacks on our IT systems This processing is strictly limited to what is technically necessary to ensure the reliable, stable, and secure operation of the website (e.g., defense against DDoS attacks). The legal basis for this processing is our legitimate interest pursuant to Article 6(1)(f) GDPR. ## 7\. Forms, API, and CRM Processing When users submit forms on our website, the data is transmitted via our own API and stored in our customer relationship management system built on Microsoft Power Platform (including Dataverse). Microsoft acts as a data processor on our behalf and processes personal data solely in accordance with our instructions and applicable data protection agreements. ## 8\. Data Transfers Outside the EU Where personal data is processed or stored outside the European Union or the European Economic Area, such transfers are safeguarded by appropriate data protection mechanisms, including the European Commissions Standard Contractual Clauses and the EU-U.S. Data Privacy Framework. ## 9\. Cookies and Technical Data Cookies and similar technologies are used only to the extent necessary to operate and secure our website. This may include essential technical cookies or comparable mechanisms provided by our hosting and security providers (e.g., Cloudflare) for purposes such as load balancing, abuse prevention, and system security. We do not use cookies or similar technologies for tracking, analytics, advertising, or profiling purposes. ## 10\. Data Retention We retain personal data only for as long as necessary to fulfill the purposes described in this Privacy Policy or as required by applicable law. Users may request deletion of their data at any time. ## 11\. Your Rights Under the GDPR, you have the right to: - Access your personal data - Rectify inaccurate or incomplete data - Request erasure of your data - Restrict processing - Object to processing - Receive your data in a structured, commonly used format - Withdraw consent at any time ## 12\. Supervisory Authority You have the right to lodge a complaint with a data protection supervisory authority, in particular in the Member State of your habitual residence, place of work, or the place of the alleged infringement. --- title: How dhino works - Enterprise data access and governance description: See how dhino's template-based architecture delivers reliable data access for people, systems, and AI. No guesswork, no hallucinations. url: https://dhino.io/product/ --- # How dhino works A governed data layer for everyone who needs your data: business users, applications, and AI. Reliable access. Consistent results. Full control. ## Four ways to use dhino Whether you need reliable agents, self-service data access, unified systems, or secure public interfaces, dhino provides one governed layer for all of them. ![](https://dhino.io/images/fetch-dino-visual.webp) ### Fetch Self-service data access for business users. No SQL required, no IT bottlenecks. Pre-defined templates let anyone get the data they need, reliably. Cross-system reports in days, not 6-week projects. ### Fetch The Problem Business users rely on IT for lists and reports. Manual exports are slow and error-prone. Who It's For Marketing, Sales, Operations, Finance The Outcome Fast, standardized, error-free data segments Create complex data segments without knowing the database. [Learn More](https://dhino.io/product/fetch) ![](https://dhino.io/images/trust-dino-visual.webp) ### Trust Make Copilot and custom agents work with your real data. No more hallucinations, no more guessing. Pre-defined templates ensure agents deliver exact results every time. Get exact Q4 pipeline figures instead of confident nonsense. ### Trust The Problem Agents give inconsistent answers. Direct database access is risky. Who It's For Organizations using Copilot, custom agents, or agentic workflows The Outcome Deterministic, trusted agent responses Agents that understand your data, without guessing. [Learn More](https://dhino.io/product/trust) ![](https://dhino.io/images/integrate-dino-visual.webp) ### Integrate One source of truth across all your systems. No more silos, no more sync issues. Updates flow instantly everywhere they need to go. Change an address once, update it everywhere instantly. ### Integrate The Problem Integrations are expensive, fragile, and hard to monitor. Who It's For IT teams, consultants, developers The Outcome Scalable, observable, secure integrations Enterprise integrations without enterprise complexity. [Learn More](https://dhino.io/product/integrate) ![](https://dhino.io/images/publish-dino-visual.webp) ### Publish Safe path from internal data to public frontends. Built-in access controls, audit trails, and governance. Publish confidently. Customer portals with real-time data, properly secured. ### Publish The Problem Exposing internal data externally is risky and slow. Who It's For Digital teams, platform owners The Outcome Secure, cached, always-up-to-date public data Publish enterprise data to the web, safely. [Learn More](https://dhino.io/product/publish) ## Two stages. Zero guesswork. 1 ### Understanding dhino interprets what you need. Whether a business user asks a question, an application makes a request, or an AI agent queries data, dhino translates intent into the right operation. 2 ### Execution The database delivers precise results. Pre-defined templates ensure accuracy and consistency. No guessing, no conflicting numbers. Just the right answer, every time. Your data Dataverse, SQL, APIs dhino Integration · Context · Control AI & apps Copilot, Power Apps Data without context is worthless. dhino defines your business logic once and enforces it everywhere. Business users get answers without waiting on IT. AI gets context without guessing. Everyone gets results they can trust. ## Built on modern standards dhino is built on the Model Context Protocol (MCP) for open-standard compatibility with the evolving AI ecosystem. We run natively on Microsoft Azure, using enterprise-grade security and deterministic logic to keep your operations visible. From role-based access to full audit trails, we provide the governance required to keep your data protected from day one. Azure Functions • Cosmos DB • API Management • MCP ## Frequently asked questions How do the four products fit together? All four sit on the same governed data layer. Fetch is for people, Trust is for AI agents, Integrate is for systems, and Publish is for public-facing apps. The same templates, definitions, and access controls are reused across all four. You define "active customer" or "Q4 pipeline" once, and every consumer sees the same answer. Do I need all four to get value? No. Most teams start with one product that matches their first pain point: Fetch for business self-service, Trust for Copilot accuracy, Integrate for Dataverse-to-external sync, or Publish for partner APIs. The architecture is shared, so adding a second product later reuses the templates you already built. How does dhino sit alongside Microsoft Fabric? Fabric is a data platform. dhino is the access layer above it. Fabric stores and prepares your data. dhino governs how people, systems, and AI consume that data, with deterministic templates, role-based access, and audit trails. They are complementary, not competing. How does dhino fit with Power Platform? Power Platform builds apps and automations on top of Dataverse. dhino governs how those apps, Copilot agents, and external systems reach Dataverse data, and lets the same template be reused across Power Apps, Copilot, and partner APIs. dhino does not replace Power Automate. It handles governed data access, not workflow orchestration. What is the difference between Fetch and Trust? Fetch serves data to people through a UI. Trust serves data to AI agents through the Model Context Protocol. The templates and governance underneath are identical. If a business user runs the same "active customer" query through Fetch that Copilot runs through Trust, they both get the same answer. Is Publish a CMS or a website builder? No. Publish exposes governed data through APIs, feeds, and embeddable data for your own frontend, CMS, or partner systems. The frontend is yours. dhino handles the secure, audited, performant data layer behind it. ## Ready to see it in action? Tell us about your data setup and we will walk you through exactly how dhino fits in. No generic pitch. Your data, your scenarios. --- title: dhino Fetch - Governed Self-Service Data Access | dhino description: Create complex data segments, lists, and visual reports from enterprise data. No database knowledge required, no IT bottlenecks, always accurate. url: https://dhino.io/product/fetch/ --- ![dhino Fetch mascot](https://dhino.io/images/fetch-dino-visual.webp) # dhino Fetch: Governed self-service access to enterprise data Business teams create complex data segments and visual reports without knowing the database or waiting on IT. ## How data flows through dhino Connect any enterprise data source. Get governed, consistent outputs for business users. CRM ERP Database Billing Power Apps / Dynamics 365 New Segment INCLUDEActive customer = Yes approved template EXCLUDELast touch ≤ 7 days on Dynamics 365 Sales, Marketing \+ Add custom criteria ## What dhino FETCH gives you Templates defined by your organization, carrying your logic. Created once by experts, used safely by everyone. ### Segment Anything No artificial limits. Segment on any table, any entity. Combine, subtract, and intersect datasets in multi-step operations. ### Consistent Results The right fields are predefined in templates. Same question, same answer, every time. No conflicting numbers. ### Governed Self-Service Role-based access control, field-level permissions, controlled execution. Safe self-service without raw database exposure. ### Visual Reports Not just lists. Visual reports with charts, trends, and dashboards. Ready for email delivery or API consumption. ## Usage scenarios ### Multi-step campaign segmentation Marketing needs a target audience: all contacts matching criteria X, minus everyone contacted this quarter, plus newsletter subscribers, intersected with a regional filter. A multi-step segment that would take hours in Excel. No manual Excel combining. No waiting for IT. Each step builds on the previous one, governed and repeatable. Result: Complex campaigns ready in minutes, not days. [Learn more](https://dhino.io/product/fetch/marketing-segmentation) ### Visual pipeline reporting Teams need visual reports from live data: KPI tiles, bar charts, trend lines. Assembled and delivered automatically, no separate BI tool required. - • Templates define the visual output format - • Reports delivered via email, Slack, Teams, or PDF - • Can be surfaced through AI agents on demand Result: Visual reports that deliver themselves, always fresh. [Learn more](https://dhino.io/product/fetch/visual-reporting) ### Cross-system financial reporting Finance reconciles data from ERP, CRM, and billing. Each system has different schemas. Someone spends half a day stitching it together every month. - • Multiple sources, unified through one template - • Consistent definitions across systems - • One report, one truth Result: Month-end close without the spreadsheet chaos. [Learn more](https://dhino.io/product/fetch/financial-reporting) ### API-based external use Segments and data aren't just for internal reports. Fetch outputs can power external systems too. - • Segments exposed via API - • Embedded in websites - • Served to AI agents - • Powers dynamic event agendas and landing pages Result: Fetch defines the segment. Other systems consume it. [Learn more](https://dhino.io/product/fetch/api-access) ## How dhino Fetch works Experts build templates once, capturing the correct logic and access rules. Business users run them with simple parameters, get reliable results in any format, and take action directly from the output. ![How dhino FETCH works: Stage 0 shows the problem of scattered data, Stage 1 shows an expert building a template, Stage 2 shows anyone running it, Stage 3 shows clean results as visual reports, data lists, or JSON/API](https://dhino.io/images/dhino-fetch-graphic.webp) ### Segmentation actions Export CSV, tag records, push to marketing tools, save counts for tracking. ### Reporting actions Email reports, post to Slack or Teams, embed in dashboards, export as PDF. ## Why standard tools aren't enough - ✕ Dynamics 365 only segments on Account, Contact, Lead. Nothing else. - ✕ Power Apps has no real segmentation, just temporary views - ✕ Excel workarounds everywhere. Manual, error-prone, inconsistent. - ✕ Logic lives in people's heads, lost when they leave - ✕ IT becomes a bottleneck for routine data requests Standard Tools dhino FETCH Segment only on Account, Contact, Lead Segment on any table, any entity Flat list output only Lists + visual reports Logic lives in someone's head Logic defined in templates Every request goes through IT Self-service for business users ## Who benefits from dhino FETCH ### Primary users They want reliable segments, fast turnaround, and independence from IT. - • Marketing teams - • Sales teams - • Operations & Finance - • Event managers ### Enabling users They create the foundation. Everyone else builds on it. They save significant time by defining logic once, and gain trust in the solution through built-in guardrails. - • IT teams - • Data teams & power users - • Consultants & partners ## Frequently asked questions about dhino Fetch How is dhino Fetch different from Dynamics 365 segmentation? Dynamics 365 only segments on Account, Contact, and Lead. Nothing else. dhino Fetch segments on any table, any entity in your data. It supports multi-step operations: combine, subtract, and intersect datasets in a single workflow. Standard tools produce flat lists. Fetch produces lists and visual reports with charts and trends. Can Fetch segment on any table or just Account, Contact, and Lead? Any table, any entity. There are no artificial limits. Fetch supports multi-step segmentation: combine datasets, subtract exclusions, intersect with filters. All in one workflow, governed by templates. What are dhino templates and how do they work in Fetch? Templates are pre-defined data operations created by IT or domain experts. They specify which tables, fields, relationships, and business rules apply. Business users select a template, set parameters, and get results. No SQL. No schema knowledge. The template carries the logic, so every user gets the same correct answer. Does dhino Fetch replace Excel for data reporting? Fetch eliminates the need for manual Excel workarounds. Instead of exporting data, combining spreadsheets, and rebuilding reports manually, Fetch captures that logic in a template once. Business users run the template and get the result directly. No more inconsistent numbers. No more manual stitching across systems. How does Fetch handle data governance and access control? Fetch separates what users want from how it is retrieved. Role-based access control and field-level permissions govern every request. Users interact through templates, never through raw database access. This means safe self-service without accidental data leaks or uncontrolled exports. Can Fetch generate visual reports or just flat lists? Both. Fetch produces flat lists when you need them and visual reports with charts, trend comparisons, and KPI tiles when you need those. Reports are rendered as lightweight HTML, ready for email delivery, Slack, Teams, PDF export, or API consumption. AI agents can also request Fetch reports on demand. How does Fetch work with AI agents? AI agents can request Fetch results through templates. Instead of teaching an agent how to build a report, the report logic lives in a Fetch template. The agent calls the template and gets governed, deterministic data. This is part of the broader dhino platform where Fetch, Trust, Integrate, and Publish share the same data layer. Is dhino Fetch a BI tool or reporting dashboard? No. BI tools show you data. dhino Fetch captures how your organization thinks about its data and makes that thinking available to everyone, safely and consistently. The report or list is one possible output. The real value is that templates capture institutional knowledge: which fields, which logic, which relationships. Built once by experts, used safely by everyone. ## Ready to stop waiting for data? See how dhino FETCH can give your teams governed self-service data access. Complex segments without complexity. --- title: API-based external access | dhino Fetch description: Expose data segments via API for external systems. Fetch defines the segment, other systems consume it. url: https://dhino.io/product/fetch/api-access/ --- # API-Based External Access Fetch defines it. Other systems consume it. Expose governed data segments via API. Power external websites, AI agents, and applications with consistent data. ## The integration challenge ### Without dhino - ✕ Custom integrations built per system - ✕ Data access siloed and inconsistent - ✕ Manual maintenance for every connection - ✕ External apps get stale or incorrect data ### With dhino Fetch - ✓ Segments exposed via API - ✓ External systems consume governed data - ✓ Fetch defines the logic once, others use it - ✓ Powers websites, AI agents, and applications ## How it works From internal segments to external consumption. 1 ### Build your segment Create a governed data segment using Fetch templates with the logic you need. 2 ### Expose via API Make the segment available through a secure API endpoint for external access. 3 ### Consume anywhere Websites, AI agents, event pages, and external apps all get consistent data. ### What you can power with Fetch APIs - • Dynamic event agendas - • Website data feeds - • AI agent data requests - • External application integrations - • Public landing pages - • Partner portals ## Ready to expose data to external systems? See how dhino Fetch can turn your internal segments into governed API endpoints. --- title: Cross-system financial reporting | dhino Fetch description: Unify cost data from CRM, ERP, and billing systems. One report, one truth, no spreadsheet reconciliation. url: https://dhino.io/product/fetch/financial-reporting/ --- # Cross-System Financial Reporting One report, one truth, no spreadsheet chaos Unify cost data from CRM, ERP, and third-party systems. Stop spending half a day stitching spreadsheets together. ## The reconciliation challenge ### Without dhino - ✕ Manual data pulls from multiple systems - ✕ Reconciliation happens in spreadsheets - ✕ Nobody trusts the final number - ✕ Half a day spent every month on manual stitching ### With dhino Fetch - ✓ Multiple sources unified through one template - ✓ Consistent definitions across systems - ✓ One report, one truth, no manual stitching - ✓ Month-end close without the spreadsheet chaos ## How it works From scattered systems to unified financial truth. 1 ### Connect your sources Link CRM, ERP, billing, and any other systems that hold financial data. 2 ### Define your logic Build a template that specifies how data should be unified and reconciled. 3 ### Get trusted numbers Generate consistent, auditable financial reports that everyone can trust. ## Ready to end the reconciliation chaos? See how dhino Fetch can unify your financial data into one trusted source of truth. --- title: Marketing campaign segmentation | dhino Fetch description: Create complex multi-step marketing segments without Excel exports. Combine, subtract, and intersect datasets in one governed workflow. url: https://dhino.io/product/fetch/marketing-segmentation/ --- # Marketing campaign segmentation Multi-step segments without the spreadsheet chaos Create complex target audiences by combining, subtracting, and intersecting datasets. All in one governed workflow. CRM ERP Database Billing Power Apps / Dynamics 365 New Segment INCLUDEActive customer = Yes approved template EXCLUDELast touch ≤ 7 days on Dynamics 365 Sales, Marketing \+ Add custom criteria ## 80% of your team is locked out of the data they need Marketing needs a list that joins event registrations, contacts, and opt-in records. The CRM has hundreds of tables. Most people don't know they exist, let alone how they connect. "Only 21% of employees feel confident working with complex data models, especially join-logic of relational databases." [Dataversity & Accenture, 2026](https://www.dataversity.net/articles/data-management-trends/) ## The segmentation challenge Standard tools weren't built for the kind of targeting modern marketing requires. ### Without dhino - ✕ Standard tools only segment on Account, Contact, Lead - ✕ Export multiple lists to Excel, combine manually - ✕ Results are inconsistent and error-prone - ✕ Process takes days, not minutes ### With dhino Fetch - ✓ Combine, subtract, intersect within one workflow - ✓ Segment on any entity, not just the standard three - ✓ Results are immediate and governed - ✓ Segments are reusable for future campaigns ## How it works An expert builds the template once. Anyone can use it from that point on. Done once by the expert 1 ### Build templates A data expert turns business logic into reusable building blocks. Each template specifies which tables to join, which fields to expose, and what parameters users can set. #### Active event participants Joins: event registration + contact + opt-in tables Parameters: event, ticket category, industry, opt-in type #### Active customers Joins: orders + product metadata + customer Parameters: product category, revenue threshold (>EUR 10,000), time period (last 3 months) Run by anyone, anytime 2 ### Select your template Need event participants? Choose "Active event participants." Need high-value customers? Choose "Active customers." Just pick the template that matches your goal. 3 ### Fill in your criteria Dropdowns, toggles, and date ranges. Select event "Annual Summit 2026," set industry to "Manufacturing," choose opt-in type "Marketing." No SQL. The template guides every choice. 4 ### Take action The segment is a waypoint, not the destination. Act on it directly from Fetch. Export CSV Send to email tool Tag records Push to systems Segmentation is one of several ways teams use dhino Fetch. [See all Fetch capabilities](https://dhino.io/product/fetch) ## Ready to simplify campaign segmentation? See how dhino Fetch can turn complex targeting requirements into governed, repeatable segments. --- title: Visual pipeline reporting | dhino Fetch description: Sales leadership wants pipeline reports every Monday. Fetch pulls live data and turns it into visual reports with charts and KPI tiles. No separate BI tool required. url: https://dhino.io/product/fetch/visual-reporting/ --- # Visual pipeline reporting Data assembly and visualization in one step Sales leadership wants a pipeline report every Monday morning. Fetch pulls live data and turns it into charts and KPI tiles. No separate BI tool required. ## From scattered data to finished visuals ### Data assembly Fetch pulls the right data from the right sources. Multiple systems, multiple schemas, unified through one template. The same governed approach used for segmentation. ### Visualization The template defines the output format: KPI tiles, bar charts, line graphs. No Power BI licenses. No Tableau setup. The visual report is the output, not a separate step. ## The visualization challenge Sales teams need pipeline charts, not raw data exports. But building those visuals is a separate job today. ### Without dhino - ✕ Manual chart building in Excel or Power BI every cycle - ✕ Separate BI tool licenses for each team that needs visuals - ✕ Data is stale by the time the report is shared - ✕ Format varies depending on who built it ### With dhino Fetch - ✓ Template defines the visual output: chart type, layout, formatting - ✓ Reports auto-generated from live data every cycle - ✓ Always fresh, always consistent, always governed - ✓ No separate BI tool needed for standard reporting ## How reporting works in Fetch Same template model as segmentation, with one difference: **templates also define the output format**. A bar chart, a KPI tile, a trend line. The visual is part of the template, not a separate tool. [See how Fetch templates work](https://dhino.io/product/fetch) ## What it looks like in practice Two examples of how Fetch visual reports look when delivered. ### KPI tile A single number with trend, delivered weekly to Teams and email. ### Bar chart with trend line Pipeline by stage, week-over-week, delivered to the sales channel. ## Deliver, don't export Segmentation actions are about doing: tag records, export lists, push to tools. Reporting actions are about delivering: send the finished report to the people who need it. Email Slack / Teams Embed in dashboards PDF export Surface via AI agents ## Ready for visual reports that deliver themselves? See how dhino Fetch can turn raw data into finished visual reports, delivered automatically to the people who need them. --- title: dhino Integrate - Enterprise integrations without complexity | dhino description: Enterprise integrations without enterprise complexity. One source of truth across all your systems. A SaaS platform, no self-hosting, no infrastructure burden. url: https://dhino.io/product/integrate/ --- ![dhino Integrate mascot](https://dhino.io/images/integrate-dino-visual.webp) # dhino Integrate: Enterprise integrations without enterprise complexity One source of truth across all your systems. A SaaS platform, no self-hosting, no infrastructure burden. Updates flow instantly everywhere they need to go. ## What dhino INTEGRATE gives you Focus on your business rules. Let dhino handle the infrastructure. ### No infrastructure to manage dhino is a SaaS platform hosted on Azure. No servers to maintain, no updates to schedule, no capacity planning. ### No on-call requirements dhino handles monitoring, retries, and error recovery. Your team doesn't get paged for integration failures. ### No scaling headaches Volume grows? dhino scales. No rewriting integrations as your data needs increase. ### Observable by default Every data flow is logged. See what moved, when, and whether it succeeded. Debug issues before users notice. ## Usage scenarios ### Address sync across systems Customer updates their address in the CRM. dhino picks up the change and propagates it to billing, support ticketing, and the shipping platform. - • Change once, update everywhere - • No manual intervention required - • All systems stay in sync Result: One update, all systems current. ### Rapid CRM integration A new sales tool needs access to customer data from Dynamics 365. Instead of building a custom connector, the team connects through dhino. - • Pre-defined templates handle field mapping - • Access controls built in - • Data transformation handled Result: New integration live in days, not months. [Explore the full Dataverse sync scenario →](https://dhino.io/product/integrate/dataverse-sync) ### Warehouse-to-ecommerce inventory sync Inventory levels in the warehouse system need to reflect on the website in near real-time. dhino handles the sync, applies stock buffer rules, and logs every update. - • Near real-time inventory updates - • Business rules applied automatically - • Alerts when something fails Result: Accurate stock levels without overnight batch jobs. [Explore observable data flows →](https://dhino.io/product/integrate/observable-data-flows) ## What dhino handles Focus on your business rules. Let dhino handle the infrastructure. #### dhino handles - Azure hosting and scaling - Monitoring and logging - Retry logic and error handling - Security and compliance - Infrastructure maintenance #### You focus on - Business rules - Template design - Access policies ## Integration projects are expensive because of infrastructure, not logic - ✕ Point-to-point connections multiply and become fragile - ✕ Who handles when it breaks at 2am? - ✕ Who monitors throughput, retries, and failures? - ✕ Failures discovered days later when users complain - ✕ Each system has its own sync schedule and format ## Who benefits from dhino INTEGRATE IT Teams Stop maintaining fragile custom integrations Consultants & Partners Deliver integration projects faster with less risk Developers Build on a reliable data layer, not spaghetti APIs Platform Teams Standardize how data moves across the organization ## Frequently asked questions about dhino Integrate What is dhino Integrate? dhino Integrate is the governed data flow layer that makes system-to-system connections reliable, observable, and secure. It uses templates to define data flow logic once and applies governance rules to every connection automatically. It is a SaaS platform hosted on Azure with no self-hosting required. How is dhino Integrate different from Power Automate or Logic Apps? dhino Integrate is not a replacement for Power Automate or Logic Apps. Those tools handle workflow automation and triggered actions. dhino Integrate focuses on governed, template-based data flows between systems. Every integration inherits platform governance rules, is fully observable, and produces deterministic results. The focus is on data movement with built-in security, auditability, and consistency. What does governed data flow mean? Every data flow in dhino Integrate inherits governance rules from the platform. Security, access control, and business rules are applied consistently across all connections. You do not need to reimplement security for each integration. Governance is built in, not bolted on. Do I need to manage infrastructure for dhino Integrate? No. dhino is a SaaS platform hosted on Azure. There are no servers to maintain, no updates to schedule, and no capacity planning. dhino handles monitoring, retries, and error recovery. Your team focuses on business rules, not infrastructure. How does dhino handle integration failures? dhino handles monitoring, retries, and error recovery automatically. Every data flow is logged, so you can see what moved, when, and whether it succeeded. Issues are visible before users notice them. Your team does not get paged for integration failures. What does observable by default mean? Every data flow in dhino Integrate is logged. You get full visibility into what data moves between systems, when it moves, and whether it succeeds. This is not an add-on. Observability is built into every integration from the start. Can dhino Integrate work with systems outside Microsoft? dhino Integrate connects Dataverse with external systems. The platform provides governed, template-based data flows between your Microsoft environment and other systems your organization uses. What are templates in dhino Integrate? Templates are reusable, auditable definitions for data flows. They specify which data moves where, what transformations apply, and which governance rules are enforced. Templates are created once by IT or data teams and reused across integrations. This makes every data flow consistent and predictable. ## Ready to simplify your integrations? See how dhino INTEGRATE can replace fragile point-to-point connections with a governed, observable data layer. No infrastructure to manage. --- title: Dataverse to external system sync | dhino Integrate description: Move data between Dataverse and external systems with governed, template-based data flows. No brittle point-to-point connections, no reimplemented security rules. url: https://dhino.io/product/integrate/dataverse-sync/ --- # Dataverse to external system sync Template-based, not point-to-point A new sales tool needs Dynamics 365 customer data. A warehouse system needs inventory updates. Each integration starts from scratch: field mapping, security rules, error handling. dhino Integrate makes every connection governed from the start. New to Dataverse? [Learn what Dataverse is and why it matters](https://dhino.io/blog/what-is-dataverse). ## Why integrations keep breaking Enterprise integrations are expensive because of infrastructure, not logic. Every point-to-point connection reimplements security, business rules, and error handling. When one system changes, dependent connections break silently. IT discovers the failure when users start complaining. "Nobody knows what data flows where until something breaks. Changes in one system cascade unpredictably to others." The reality for most enterprise integration landscapes ## The integration challenge Point-to-point connections work until they don't. Every enterprise hits this wall. ### Without dhino - ✕ Each connection built from scratch - ✕ Security reimplemented per integration - ✕ Failures discovered after the damage is done - ✕ Changes in one system cascade to others ### With dhino Integrate - ✓ Template-based connections, created once - ✓ Security inherited from the platform - ✓ Observable data flows with full logging - ✓ Changes isolated by governed templates ## How it works Governed data flows between Dataverse and external systems, without the infrastructure burden. 1 ### Define templates IT captures field mappings, transformations, and business rules in reusable templates. Created once, applied to every connection between Dataverse and external systems. 2 ### Connect through dhino Point Dataverse at external systems through dhino. Every connection inherits governance, logging, and error handling from the platform. No custom connectors needed. 3 ### Monitor and audit Full visibility into what data flows where and when. dhino handles monitoring, retries, and error recovery. No more discovering failures after users complain. ## What changes for your data platform ### Consistent security across connections Every data flow inherits platform governance rules. You do not need to reimplement access control, audit trails, or business rules for each integration. ### Integration delivery in days, not months Pre-defined templates handle field mapping and data transformation. New connections reuse existing templates instead of starting from scratch. ### Full audit trail on every data flow Every data movement is logged. See what moved, when, and whether it succeeded. Debug issues before users notice them. Dataverse sync is one of several integration challenges dhino solves. [See all Integrate capabilities](https://dhino.io/product/integrate) ## Ready to simplify your Dataverse integrations? See how dhino Integrate replaces brittle point-to-point connections with governed, observable data flows. No infrastructure to manage. --- title: Observable, auditable data flows | dhino Integrate description: Every data flow logged, every failure visible, every integration auditable. dhino Integrate builds observability into every connection by default. url: https://dhino.io/product/integrate/observable-data-flows/ --- # Observable, auditable data flows See everything. Miss nothing. Most integration failures are discovered after the damage is done. A customer gets the wrong invoice. Inventory shows out of stock when it isn't. dhino Integrate logs every data flow so you see problems before users do. ## Why integration failures go unnoticed Traditional integrations are black boxes. Data enters one system and is supposed to arrive in another. When it doesn't, nobody knows until a user reports something wrong. By then, the damage has spread: incorrect records, missing updates, broken downstream processes. "Integration failures discovered after the damage is done. Business teams have no visibility into what data moves between systems." The default state of most enterprise integration landscapes ## The observability challenge You can't fix what you can't see. Most integration tools don't show you what's happening. ### Without dhino - ✕ Failures discovered when users complain - ✕ No record of what data moved or when - ✕ Debugging requires checking each system individually - ✕ Audit requests mean weeks of manual investigation ### With dhino Integrate - ✓ Issues visible before users notice them - ✓ Every data movement logged automatically - ✓ One place to see all data flows across systems - ✓ Audit trails built into every integration ## How it works Observability is not an add-on. It is built into every data flow from the start. 1 ### Every flow is logged Every data movement between Dataverse and external systems is automatically recorded. What moved, when, where it went, and whether it succeeded. 2 ### Failures surface automatically dhino handles monitoring, retries, and error recovery. When something fails, it is visible immediately. No waiting for users to report problems days later. 3 ### Audit trails are automatic Every data flow inherits platform governance. Audit trails are part of every integration, not something you build separately for compliance reviews. ## What changes for your operations ### Problems found before users notice Integration issues are visible in dhino before they affect downstream systems or end users. Your team investigates proactively instead of reactively. ### Compliance without manual effort Audit trails are built into every data flow. When compliance asks "what data moved where and when," the answer is already recorded. ### No more 2am pages dhino handles retries and error recovery automatically. Your team does not get paged for integration failures. Observability is one of several ways dhino transforms enterprise integrations. [See all Integrate capabilities](https://dhino.io/product/integrate) ## Ready to see what's happening in your integrations? See how dhino Integrate gives you full visibility into every data flow, with audit trails and error recovery built in. --- title: dhino Publish - Safe data publishing to the web | dhino description: Publish enterprise data to the web, safely. Built-in access controls, audit trails, and governance. Customer portals, partner APIs, and public dashboards done right. url: https://dhino.io/product/publish/ --- ![dhino Publish mascot](https://dhino.io/images/publish-dino-visual.webp) # dhino Publish: Enterprise data to the web, safely Safe path from internal data to public frontends. No custom API development. No waiting for external agencies. Publish in days, not months. ## What dhino PUBLISH gives you A secure bridge between internal data and external consumers. Templates define what's accessible. Governance is built in. ### Internal-to-external security Only expose what you intend to expose. Field-level access controls ensure sensitive data stays internal. ### Built-in caching External traffic doesn't hit your databases directly. dhino caches responses intelligently to protect backend performance. ### Complete audit trails Know exactly who accessed what data, when. Meet compliance requirements without building custom logging. ### Governance at the edge Rate limiting, access policies, and monitoring apply automatically. No separate API gateway needed. ## Usage scenarios ### Auto-generated product pages Product data lives in your ERP or PIM. Instead of manually copying specs to the website, dhino serves the data via API. Pages update automatically when source data changes. - • Data from ERP/PIM, served to any frontend - • Pages update automatically with source changes - • No developer required for content updates Result: Product pages always match your systems. ### Event and webinar pages Event details live in your CRM or event system. Speakers, sessions, and agendas are managed there. dhino makes that data available to your website in real-time. - • Event details from CRM, live on website - • Dynamic agenda updates - • Speaker bios pulled from your database Result: One source of truth for event data everywhere. [Explore the full event pages scenario →](https://dhino.io/product/publish/event-pages) ### Customer portal with real-time data Customers log in and see their order history, shipping status, and invoices. dhino serves this data from your ERP with proper authentication. Each customer only sees their own data. - • Self-service order and invoice access - • Customer-scoped data security - • No direct database access required Result: Self-service portal that reduces support tickets. ### Partner API without database exposure Partners need product availability data. Instead of giving them database credentials, you expose a dhino endpoint. Rate limits prevent abuse. Field-level controls hide cost data. - • Controlled API endpoints for partners - • Rate limiting and access policies built in - • Every request logged for compliance Result: Partner integration without security risk. [Explore the full partner API scenario →](https://dhino.io/product/publish/partner-api) ## Why publishing internal data is hard - ✕ Security blocks direct database access - ✕ Building a proper API takes months - ✕ External traffic hammers internal systems without caching - ✕ Waiting for external agencies to connect data - ✕ Custom API development for each use case ## Who benefits from dhino PUBLISH Digital Teams Build customer portals with real-time data Platform Owners Create partner APIs without exposing databases Product Teams Embed live data in public-facing features Marketing Teams Data-driven landing pages and event pages ## Frequently asked questions about dhino Publish What is dhino Publish? dhino Publish is the governed data exposure layer that makes internal data safe to share externally. It uses templates to define what data is accessible, applies governance rules automatically, and ensures external-facing data stays consistent with internal sources. It is not a CMS or website builder. Is dhino Publish a CMS or website builder? No. dhino Publish is not a CMS or website builder. It is a data exposure layer. Publish provides the governed API that serves data to your frontend. You build the website or portal with whatever tools you prefer. Publish handles the data, security, and caching. Your frontend handles the presentation. How does dhino Publish protect sensitive data? Publish uses field-level access controls to ensure you only expose what you intend to expose. Governance rules are applied automatically to every external-facing data point. Complete audit trails track who accessed what data and when. Rate limiting and access policies protect against abuse. Does external traffic hit my databases directly? No. dhino Publish includes built-in caching. External requests are served from the cache, protecting your backend systems from direct traffic. This means consistent performance for external consumers without impacting internal database operations. What can I build with dhino Publish? Common use cases include customer portals with order history and invoice access, partner APIs with controlled data access, auto-generated product pages from ERP or PIM data, and event pages powered by CRM data. Publish provides the data layer. You decide how to present it. How does Publish handle compliance and auditing? Every request through dhino Publish is logged. You get complete audit trails showing who accessed what data and when. Access policies and rate limiting are applied automatically. This helps meet compliance requirements without building custom logging infrastructure. How does Publish relate to the other dhino products? Publish shares the same platform as Fetch, Integrate, and Trust. Fetch provides the data segments and reports. Integrate handles system-to-system data flows. Publish takes that governed data and makes it safe for external audiences. All four products use the same templates, governance, and deterministic execution. Do I need a separate API gateway with dhino Publish? No. dhino Publish includes rate limiting, access policies, and monitoring by default. Governance happens at the edge, so there is no need for a separate API gateway layer. Everything is built into the platform. ## Ready to publish data safely? See how dhino PUBLISH can give you a secure, governed path from internal data to external consumers. Publish in days, not months. --- title: Dynamic event pages from CRM data | dhino Publish description: Keep event pages in sync with your CRM automatically. Speakers, sessions, and agendas update on the website when source data changes. No manual content updates. url: https://dhino.io/product/publish/event-pages/ --- # Dynamic event pages from CRM data Update the CRM. The website follows. Event details live in your CRM. Speakers, sessions, agendas, and logistics are managed there. But the website still needs manual updates every time something changes. dhino Publish serves that data directly to your frontend. ## Why event pages go stale A speaker cancels. A session time changes. The event team updates the CRM, but the website still shows the old information. Someone has to manually update the page, or worse, email the web team and wait. The result: event pages that don't match reality. "External portals showing stale or inconsistent data. IT teams rebuilding external data access for every new requirement." The default when internal and external data are managed separately ## The event data challenge Event data changes constantly. Your website should keep up without manual intervention. ### Without dhino - ✕ Manual updates every time event details change - ✕ Website and CRM show different information - ✕ Developer needed for every content change - ✕ Custom API built for each event from scratch ### With dhino Publish - ✓ Website updates when CRM data changes - ✓ One source of truth for event data - ✓ Event team manages content in CRM, not the website - ✓ Templates reused across all events ## How it works dhino provides the data API. Your frontend displays it however you want. 1 ### Define what to expose Templates define which event data is available externally: speakers, sessions, agendas, logistics. Access controls determine what is public and what stays internal. 2 ### Serve data via API dhino exposes a governed API endpoint. Your website or app fetches event data from it. Built-in caching protects your CRM from direct traffic. 3 ### Update once, reflect everywhere The event team updates details in the CRM. The website reflects those changes automatically. No developer requests, no manual copy-paste, no stale pages. ## What changes for your events ### Event pages that match reality Speakers, sessions, and agendas on your website always reflect what is in the CRM. No more outdated information causing confusion for attendees. ### No developer needed for content changes The event team manages content where they already work: in the CRM. Website updates happen automatically. No tickets, no waiting. ### Reusable across all events Templates built for one event work for every event. New events get the same governed data pipeline without rebuilding anything. Event pages are one of several ways teams use dhino Publish. [See all Publish capabilities](https://dhino.io/product/publish) ## Ready to power your event pages from CRM data? See how dhino Publish gives your event team a direct path from CRM to website, with governance and caching built in. --- title: Partner API without database exposure | dhino Publish description: Share data with partners through governed API endpoints. Field-level access controls, rate limiting, and audit trails built in. No database credentials shared. url: https://dhino.io/product/publish/partner-api/ --- # Partner API without database exposure Share data, not database credentials Partners need product availability data. Distributors need pricing. Resellers need inventory. The answer is never "here are the database credentials." dhino Publish gives partners exactly what they need through governed API endpoints. ## Why sharing data with partners is risky Partners need access to your data, but every approach is either too open or too slow. Direct database access exposes everything. Building custom APIs takes months and requires ongoing maintenance. Manual data exports are stale before they arrive. "Sensitive data accidentally exposed to external parties. IT teams rebuilding external data access for every new requirement." The risk every time a partner asks for data access ## The partner data challenge You need to share data. You can't afford to share everything. ### Without dhino - ✕ Custom API built for each partner request - ✕ No field-level control over what partners see - ✕ No rate limiting or abuse prevention - ✕ No audit trail of what partners accessed ### With dhino Publish - ✓ Templates define partner-specific data views - ✓ Field-level controls hide sensitive data - ✓ Rate limiting and access policies built in - ✓ Every request logged for compliance ## How it works Governed API endpoints for partners, without building custom integrations. 1 ### Define partner data views Templates determine exactly which fields each partner can see. Product availability without cost data. Inventory levels without supplier details. You decide. 2 ### Expose governed endpoints dhino creates API endpoints with rate limiting, access policies, and caching built in. Partners call the API. Your database stays protected. 3 ### Monitor and audit Every partner request is logged. See who accessed what data, when, and how often. Meet compliance requirements without building custom logging. ## What changes for your partner ecosystem ### Partners get data, not database access Field-level access controls mean partners see exactly what you intend. Cost data, supplier details, and internal notes stay hidden. No more all-or-nothing choices. ### New partners onboarded in days Templates are reusable. When a new partner needs access, you apply an existing template with appropriate permissions. No custom API development per partner. ### Compliance built into every request Audit trails, rate limiting, and access policies are automatic. When compliance asks who accessed what, the answer is already recorded. Partner APIs are one of several ways teams use dhino Publish. [See all Publish capabilities](https://dhino.io/product/publish) ## Ready to share data with partners securely? See how dhino Publish gives your partners the data they need through governed, auditable API endpoints. No database exposure. No custom development. --- title: dhino Trust: Reliable AI Answers from Real Enterprise Data | dhino description: AI that understands your data, without guessing. Make Copilot and custom agents work with your real data. No hallucinations, deterministic results. url: https://dhino.io/product/trust/ --- ![dhino Trust mascot](https://dhino.io/images/trust-dino-visual.webp) # dhino Trust: Reliable AI answers from real enterprise data Finally, Copilot and custom agents work with your real data. Pre-defined templates ensure agents deliver exact results, no hallucinations, no guessing. ## What dhino Trust gives you Templates carry business logic. AI asks questions. dhino returns governed, accurate results. ### Deterministic answers AI doesn't generate SQL or interpret schemas. Templates define the logic. Same question, same answer, every time. ### Built-in governance AI only sees what it's allowed to see. Role-based access, audit trails, and policy enforcement by default. ### AI-agnostic Works with Copilot today. Compatible with any MCP-enabled AI. No vendor lock-in. ### Lower cost, better performance Fewer tokens wasted on context. Queries routed to deterministic logic. Predictable performance at scale. ## Usage scenarios ### Copilot with real pipeline data The sales director asks Copilot: "What's our Q4 pipeline?" Instead of guessing from context, Copilot calls dhino's "Pipeline Summary" template. - • Exact numbers: $4.2M weighted, 127 opportunities - • 23 closing this month - • Same answer, every time Result: Executive decisions based on real numbers, not AI estimates. [Explore the full pipeline data scenario →](https://dhino.io/product/trust/copilot-pipeline) ### Customer service agent with account data An internal support chatbot needs to answer "What's the customer's contract renewal date?" dhino provides the answer from CRM with proper access controls. - • Agent sees only authorized data - • Deterministic: same question, same answer - • Proper governance enforced Result: Faster support, no data leakage. [Explore the full customer service scenario →](https://dhino.io/product/trust/customer-service-agent) ### Consistent executive dashboards Multiple AI-powered reporting tools query the same metrics. Without dhino, each tool might calculate "active customers" differently. - • All tools use the same template - • CFO and CMO see the same numbers - • No conflicting reports Result: One version of truth across all AI tools. [Explore the full cross-department scenario →](https://dhino.io/product/trust/cross-department-consistency) ## Why AI gets your data wrong - ✕ Enterprise data is complex. AI guesses instead of calculating - ✕ Business definitions live in people's heads, not schemas - ✕ Databases weren't designed for AI interpretation - ✕ Same question, different answers. 45% cite inaccuracy as #1 AI barrier - ✕ Direct database access is risky and uncontrolled ## How dhino makes AI reliable Instead of letting AI "figure out" your data, dhino tells AI exactly how your data works. Stage 1: Understanding AI interprets the user's intent and selects the right template. Stage 2: Execution dhino executes pre-defined, deterministic logic. No guessing. ### Built on MCP dhino uses the Model Context Protocol (MCP), the emerging open standard for AI-data connections. Compatible with Microsoft Copilot, custom agents, and the broader AI ecosystem. MCP is the standard for giving AI controlled access to tools and data. dhino is MCP-native. [See how dhino's Dataverse MCP server compares to Microsoft's](https://dhino.io/compare/dataverse-mcp). ## Who benefits from dhino Trust Copilot Users Make Microsoft Copilot actually work with your enterprise data Custom Agent Builders Build internal chatbots and assistants that don't hallucinate AI Platform Owners Deploy AI at scale with proper governance and auditability [See governed AI at scale →](https://dhino.io/product/trust/governed-ai-at-scale) IT & Security Teams Enable AI adoption without compromising data security ## How Trust holds under a jailbreak The model can be talked past its prompt. The policy configured in dhino cannot, because it does not live in the model. Jailbreaks and [prompt injection](https://dhino.io/glossary/prompt-injection) work on the conversation. With enough patience, someone talks the model into agreeing to something it was told to refuse. dhino expects that. The rules that have to hold are evaluated on the action call, deterministically, outside the model. This is [policy enforcement](https://dhino.io/glossary/policy-enforcement) at the action layer, the one [agent guardrail](https://dhino.io/glossary/agent-guardrails) that gives the same answer no matter what the chat said. Named actions only The agent's whole surface is a short list of named actions with typed parameters. There is no path to SQL, to the database, or to arbitrary APIs. Rules on every parameter Each action carries rules configured per parameter: minimum and maximum values, allowed ranges. Set once in dhino, checked on every call. Refusal before the data layer A call that breaks a rule gets a refusal from dhino. The request never reaches the data behind the action. Every call logged Parameters, decision, and result are recorded for every call, allowed or refused, outside the chat log. ## Frequently asked questions about dhino Trust How does dhino prevent AI hallucinations on enterprise data? dhino uses pre-defined templates that carry business logic, relationships, and rules. AI does not generate SQL, interpret schemas, or invent definitions. Instead, AI selects the right template, and dhino executes deterministic logic. Same question, same answer, every time. This separation of understanding from execution eliminates hallucinations on structured data queries that run through dhino templates. What is Model Context Protocol and how does dhino use it? Model Context Protocol (MCP) is the emerging open standard for connecting AI to tools and data sources. dhino is built on MCP, so any MCP-enabled AI agent can connect to dhino and access enterprise data through governed templates. This includes Microsoft Copilot, custom agents, and other AI tools in the MCP ecosystem. Does dhino work with Microsoft Copilot? Yes. dhino works with Microsoft Copilot today. When Copilot needs enterprise data, it calls dhino templates instead of guessing from context. Copilot returns accurate, governed results based on your actual business data and definitions. Can dhino work with AI models other than Copilot? Yes. dhino is AI-agnostic by design. It is built on Model Context Protocol (MCP), an open standard, so it is compatible with any MCP-enabled AI agent or assistant. There is no vendor lock-in. You can use one data layer for all your AI tools. What is the difference between dhino and direct AI-to-database access? Direct AI-to-database access is non-deterministic and high-risk. The AI guesses schema structure and business definitions. dhino is the opposite: deterministic execution through pre-defined templates, role-based governance, and business logic defined once by the people who know the data. The AI asks, dhino answers with exact, governed results. How does dhino handle data governance for AI agents? Governance is built into the platform, not added on top. Every AI request goes through the same governance controls: role-based access, audit trails, and policy enforcement. AI only sees data it is authorized to see. Sensitive data stays protected automatically with every request. What happens if someone jailbreaks an AI agent that uses dhino Trust? The model can be talked into agreeing to almost anything. That is true of every LLM, and dhino does not claim to prevent it. What a jailbreak cannot change is the policy. When the agent calls an action, dhino evaluates the typed parameters against the rules configured for that action, outside the model, and refuses the call if a rule is broken. The refused request never reaches the data behind the action, and every call is logged with its parameters and outcome. A jailbroken conversation gets the same policy decisions as a polite one. What are dhino templates and why do they matter for AI? Templates are pre-defined, tested data operations that carry business logic, relationships, guardrails, and performance constraints. They are created once by IT or data teams and reused by every consumer, including AI agents. When an AI agent needs data, it calls a template instead of generating its own query. This is why dhino returns correct, consistent results instead of AI guesses. How does dhino reduce AI operational costs? dhino reduces costs in two ways. First, fewer tokens are wasted on context because templates carry the business logic, so AI does not need to process large schema descriptions. Second, queries are routed to deterministic logic instead of expensive AI inference on structured data tasks. The result is faster answers, lower token usage, and predictable performance at scale. ## Ready to make AI actually work? See how dhino AI turns your data from a risk into a reliable interface for enterprise AI. Deterministic answers, every time. --- title: Copilot with real pipeline data | dhino Trust description: Your sales director asks Copilot for the Q4 pipeline. With dhino, Copilot calls a governed template and returns exact figures, every time. url: https://dhino.io/product/trust/copilot-pipeline/ --- # Copilot with real pipeline data Ask Copilot a business question. Get an exact answer. The sales director asks Copilot: "What's our Q4 pipeline?" Instead of guessing from context, Copilot calls a dhino template and returns exact figures. [Read the full guide to Copilot data access](https://dhino.io/blog/copilot-enterprise-data-access). ## AI guesses what your data means When a sales director asks "What's our Q4 pipeline?", the AI needs to know what counts as pipeline. Which stages? Which probability threshold? Which fiscal year definition? Without clear definitions, AI invents its own answers. "45% of enterprise leaders cite inaccuracy as the number one barrier to AI adoption." [McKinsey, The State of AI, 2024](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) ## The pipeline question "What's our Q4 pipeline?" means something specific in your business. AI should not have to guess. ### Without dhino - ✕ AI guesses what "pipeline" means - ✕ Different answers depending on when you ask - ✕ No way to know if the number is right - ✕ Executives lose trust in AI-generated reports ### With dhino Trust - ✓ "Pipeline" is predefined with exact criteria - ✓ Same question, same answer, every time - ✓ Exact numbers: $4.2M weighted, 127 opportunities - ✓ Executive decisions based on real data ## How it works Your data expert defines the template once. Copilot uses it every time. 1 ### Define the template A data expert creates the "Pipeline Summary" template. It defines which stages count, how weighting works, and what time period to use. Built once, reused forever. 2 ### Copilot calls dhino When someone asks "What's our Q4 pipeline?", Copilot recognizes the intent and calls the dhino template via MCP. No SQL generation. No schema guessing. 3 ### Exact answer returned dhino executes deterministic logic against your data. Copilot returns: "$4.2M weighted pipeline, 127 open opportunities, 23 closing this month." ## What changes for your business ### Executives trust the numbers Pipeline reviews happen with confidence because the data comes from governed, deterministic templates, not AI interpretation. ### One version of truth Sales, finance, and the board see the same pipeline number. The definition is coded once and applied everywhere. ### No more manual report building Instead of pulling data into spreadsheets and building reports manually, anyone can ask Copilot and get the answer in seconds. Pipeline reporting is one of several ways AI agents use dhino for accurate data. [Explore dhino Trust](https://dhino.io/product/trust) ## Ready to make Copilot work with your pipeline data? See how dhino AI turns your pipeline questions into exact, governed answers. --- title: Consistent AI answers across departments | dhino Trust description: Sales, Marketing, and Finance ask the same question but get different answers. dhino templates give every department the same governed result. url: https://dhino.io/product/trust/cross-department-consistency/ --- # Consistent AI answers across departments Same question. Same answer. Every department. Sales, Marketing, and Finance ask "How many active customers do we have?" Without dhino, each department gets a different number. With dhino, the definition is set once and the answer is always the same. ## Three departments, three different answers Every department has its own understanding of key business terms. Sales counts "active customers" by recent revenue. Marketing counts by content engagement. Finance counts by open contracts. When AI interprets these terms without a shared definition, every department gets a different number from the same data. "45% of enterprise leaders cite inaccuracy as the number one barrier to AI adoption." [McKinsey, The State of AI, 2024](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) ## The "active customer" question Three departments ask the same question. Without a shared definition, AI gives three different answers. ### Without dhino - ✕ Sales counts by recent revenue - ✕ Marketing counts by engagement - ✕ Finance counts by open contracts - ✕ Board gets three conflicting numbers ### With dhino Trust - ✓ "Active customer" defined once in a template - ✓ Role-based access controls what each department sees - ✓ CFO and CMO see the same number - ✓ One version of truth across every report ## How it works Central definitions with role-based access. Every AI tool pulls from the same source. 1 ### Define business terms once "Active customer" is captured in a template with exact criteria: order in the last 90 days, revenue above threshold, contract status open. One definition, agreed on by the business. 2 ### Access controlled by role Each department sees data through their lens, but the core definition stays the same. Sales sees their accounts. Marketing sees campaign metrics. Finance sees contract values. All based on the same "active customer" logic. 3 ### Every AI tool gets the same answer Copilot, custom agents, dashboards, and reporting tools all call the same template. No matter who asks or which tool they use, the number is consistent. ## What changes for your business ### Board meetings with one set of numbers When the CFO and CMO present customer metrics, the numbers match. No more reconciliation debates. ### AI adoption accelerates People trust AI when it gives the same answer regardless of who asks. Consistent results remove the biggest barrier to adoption. ### IT maintains definitions, not custom reports Instead of building separate reports for each department, IT defines the business logic once in templates. Every consumer gets governed, accurate data. Cross-department consistency is one of several ways AI agents use dhino for accurate data. [Explore dhino Trust](https://dhino.io/product/trust) ## Ready to give every department the same answer? See how dhino AI ensures consistent, governed answers across your entire organization. --- title: Customer service agent with account data | dhino Trust description: An internal support chatbot answers account questions with governed CRM data. No hallucinations. No unauthorized data exposure. Deterministic answers from dhino. url: https://dhino.io/product/trust/customer-service-agent/ --- # Customer service agent with account data Support agents get real answers from real CRM data. A support agent asks the internal chatbot: "When does this customer's contract renew?" The chatbot calls dhino and returns the exact date, along with contract tier and renewal terms. No guessing. No hallucinating. ## AI chatbots make up customer data Customer service teams adopt AI chatbots to help agents answer account questions faster. But when the chatbot generates answers from incomplete context, it invents contract dates, fabricates account details, and returns confidently wrong information. The support agent trusts the chatbot. The customer gets a wrong answer. "The chatbot told me my contract renews in March. It actually renews in June. I almost missed the negotiation window." The risk when AI guesses at account data ## The contract renewal question "When does this customer's contract renew?" requires an exact answer, not an approximate one. ### Without dhino - ✕ Chatbot guesses from conversation history - ✕ Contract dates may be fabricated or outdated - ✕ Sensitive account data may leak to unauthorized agents - ✕ No audit trail of what data was shared ### With dhino Trust - ✓ Exact renewal date from CRM record - ✓ Contract tier and terms included automatically - ✓ Agent only sees data they are authorized for - ✓ Every data access logged and auditable ## How it works Your data team defines the templates. The chatbot uses them for every query. 1 ### Define account templates A data expert creates templates for common support queries: contract details, billing history, service level, recent interactions. Each template specifies exactly what data to return and who can see it. 2 ### Chatbot calls dhino When an agent asks about a customer, the chatbot identifies the intent and calls the matching dhino template via MCP. The template runs deterministic logic against your CRM data. 3 ### Governed answer returned The chatbot returns: "Contract renews June 15, 2026. Enterprise tier. Auto-renewal with 60-day notice period." Exact, governed, auditable. ## What changes for your support team ### Faster resolution Agents get account details instantly instead of switching between CRM screens, searching knowledge bases, or escalating to colleagues who "know the system." ### No wrong answers Every answer comes from governed CRM data, not AI interpretation. Contract dates are real dates. Account tiers are real tiers. Billing amounts are real amounts. ### Data stays protected Access controls ensure agents only see data they are authorized for. A tier-1 support agent does not see the same financial details as an account manager. Every access is logged. ## Explore more dhino Trust scenarios Customer service is one way dhino Trust delivers governed data access. [Copilot with real pipeline data](https://dhino.io/product/trust/copilot-pipeline) [Cross-department consistency](https://dhino.io/product/trust/cross-department-consistency) ## Give your support team trusted AI answers See how dhino Trust connects your customer service chatbot to real CRM data with governance, access controls, and audit trails built in. --- title: Governed AI data access at scale | dhino Trust description: What happens when AI requests scale to thousands per day? dhino provides optimized execution, guardrails, and caching for stable, governed performance. url: https://dhino.io/product/trust/governed-ai-at-scale/ --- # Governed AI data access at scale AI pilots work. Production scale is the real test. The first 50 AI requests work fine. But at 500 per day, databases slow down. At 5,000, costs become unpredictable. dhino is built for production-scale AI from day one. ## What happens after the pilot succeeds? Most AI data access patterns were designed for demos, not production. Each request runs expensive AI inference even for questions with known, deterministic answers. At scale, this means unnecessary load on both AI models and databases, unpredictable costs, and governance controls that break under volume. "Less than 50% of AI systems achieve acceptable accuracy on structured enterprise data queries." [arXiv research, 2022](https://arxiv.org/abs/2204.00498) ## The scale challenge Pilot-stage AI access patterns break in production. Every enterprise hits this wall. ### Without dhino - ✕ Database overload at high request volume - ✕ Unpredictable AI inference costs - ✕ No visibility into what AI is querying - ✕ Governance degrades as volume grows ### With dhino Trust - ✓ Optimized execution via deterministic templates - ✓ Predictable costs with template-based routing - ✓ Full audit trails on every AI request - ✓ Governance scales automatically with volume ## How it works Production-grade AI data access without the production-grade headaches. 1 ### Templates replace inference Structured data queries are routed to deterministic templates instead of expensive AI inference. Fewer tokens, faster answers, lower cost per request. 2 ### Guardrails prevent overload Access controls, query optimization, and caching are built into the platform. Your databases stay healthy even at thousands of requests per day. 3 ### Governance scales automatically Every request goes through the same controls regardless of volume. Role-based access, audit trails, and policy enforcement work the same at 50 requests or 5,000. ## What changes for your platform ### Predictable AI operating costs Template-based routing means structured data queries bypass expensive AI inference. Costs scale linearly with usage, not exponentially with complexity. ### Databases stay healthy under load Built-in caching and query optimization prevent AI from overwhelming your data infrastructure. Performance stays stable as request volume grows. ### Governance that works at volume Access controls and audit trails are part of every request, not bolted on after the fact. Compliance stays intact whether you process 50 or 50,000 AI requests per day. Scaling AI is one of several challenges dhino solves for enterprise data access. [Explore dhino Trust](https://dhino.io/product/trust) ## Ready to scale AI with confidence? See how dhino gives your AI platform governed, production-grade data access that performs at any scale.