Dust AI agent: making an agent reliable on your internal data

You run a marketing, operations or IT team, and Dust is the tool chosen to plug an agent into the company's knowledge. This page is for those who have to decide what this AI agent on Dust is allowed to read and who gets access to it.

It helps you settle three things: which sources prevail, which rights the agent inherits from the person querying it, and which tests have to fail before its scope is widened.

An agent that knows what your company knows

An organization's knowledge does not live in a model. It is spread across a messaging tool where decisions get taken, a document space where official versions lie dormant, a wiki three people maintain, a ticket base where customers' real questions live. An agent plugged into that whole is worth what it knows about you, and how reliable that knowledge is.

So the structuring decision is no longer “which model”, it is “which sources, with which rights”. The agent itself remains an agent in the sense of our pillar on AI agents, with rights graded according to the four permission levels. Arbitrating between families of tools is handled when choosing an AI agent platform; here, the tool is chosen, and the question becomes what you give it to read.

What changes when the knowledge comes from inside

An agent grounded in internal sources does not answer “in general”: it answers on your refund policy, your discount grid, your escalation procedure. The value no longer comes from the writing, it comes from the searching that has been removed.

The trade-off explains most disappointments: the value depends less on the model than on the integration with the information system. An excellent engine plugged into six contradictory sources produces wrong, confident answers; an ordinary engine plugged into three up-to-date reference bases renders a service nobody disputes.

Which agent for which team, and how far to let it go

Rather than a catalogue of use cases, one grid is enough. It crosses the team served, the type of agent that helps it and the level of autonomy granted. The fourth column is the one people forget: the sources that carry authority change from one team to the next.

Autonomy follows from the sources: the support agent goes far because its sources are closed and reviewed, the data agent stays gradual because its definitions are moving.

Choosing your sources: which ones prevail, which ones stay out

This is the decision that governs all the others, and the one people rush. “Connect everything you can” sounds generous; in practice, every source added increases the error surface faster than the coverage. Start from a scope of questions, retain the two or three reference bases that answer them, and justify each additional source by a question no other one covers.

What is at stake here is internal knowledge: searching the open web and citing public sources is the job of an AI agent like Perplexity, which is not governed the same way.

Arbitrating between a wiki, a messaging tool and a ticket base

Every type of source has a virtue and a vice; the trade-off is knowing which one you can take on. The document space is reliable but does not say why a rule exists; the wiki explains the why and ages without warning; the messaging tool mixes real decisions with discussions an agent will read as decisions. Before connecting a source, ask it four questions:

• who owns it;
• how often it is reviewed;
• what it alone contains;
• what happens if the agent cites it wrongly.

The answers can be summed up by type of source; the last column serves as the exclusion criterion: a source whose risk is covered by no rule stays out.

Data that changes, sources that contradict each other

Separate two regimes. Stable data (definitions, procedures, reference bases) tolerates periodic ingestion. Time-bound data (policies, offers, legal rules) requires the version in force: otherwise the agent gets it wrong without anything in its answer looking like an error, and that is the most expensive failure.

So treat document grounding as a contract: which sources prevail, how they are updated, how the agent cites its internal references. The mechanics that support it belong to a RAG AI agent; what is decided here is a question of organization and accountability.

That leaves the most frequent case, and the one nobody works through: two sources contradict each other. Three behaviours are possible; one has to be chosen explicitly, family of questions by family of questions:

• Deciding: assumes a hierarchy written in advance (the official beats the wiki, which beats the messaging tool) and only holds if it is true.
• Flagging: exposes the disagreement and both references. It is the safest default.
• Refusing: is reserved for high-risk surfaces.

That choice is written into the instructions and checked in testing.

Access rights: spaces, roles and logging

Plugging an agent into internal documents is first of all a matter of trust: 60% of employees say they are concerned about data confidentiality (Hostinger, 2026), a benchmark that appears with its variants in our set of AI statistics. The first incident, a document obtained through the agent without the right to see it, costs months of adoption.

Three decisions arise together:

• which sources to connect, prioritizing reference bases that carry authority;
• who has access to what, through rights by role and dedicated spaces;
• what is logged, that is, the input, the sources consulted and the output.

Minimal rights and inherited permissions

The rule is simple to state and hard to hold: an agent must never make visible what the person querying it could not read themselves. That rules out the most tempting shortcut: a broad-access service account that answers everyone with the same knowledge. That arrangement turns the agent into a silent way round your permissions: nothing in the answer indicates that the source was restricted.

Four measures follow:

• segmentation by space that reproduces your existing scopes;
• data minimization, each connection opened to the strict minimum rather than to a whole tool;
• periodic access reviews, because a scope granted for a pilot outlives the pilot;
• leak test scenarios, with malicious prompts and source confusion.

Log who asked what, which documents were consulted, what was produced: without that triplet, no incident can be explained.

What you secure in the contract, rather than what the vendor promises

Product pages all announce security, encryption and compliance. Only what is in the contract binds the vendor. So state your requests before the demo; four are not up for negotiation:

• Non-reuse of the data: obtain in writing that your content trains no model, with the commitment extended to subprocessors.
• Where the processing takes place: where the data is hosted, where it transits, which law governs access requests.
• Revocation of access: the delay between an employee leaving and the loss of their rights on the agent side, and who can cut a connection in an emergency.
• Export of the logs: recovering your traces in a usable format, over an audit-grade depth.

During the demo, have a question asked by a profile with no access to the source that answers it: the tool must show the refusal, its reason and its trace, otherwise it will not explain a drift in production any better.

Read, propose, execute: three levels, three control regimes

The more the agent can act, the more you have to distinguish what it consults, what it suggests and what it triggers. Confusing those regimes turns a successful pilot into an incident: the agent is validated on its ability to answer, then write access is opened without the controls being revisited.

What each regime adds when the sources are internal

The scale is the pillar's: the four permission levels of an agent (read-only, controlled writing with human validation, supervised execution, bounded autonomy), also detailed for autonomous AI agents. What matters on Dust is what each level adds when the agent reads your documents.

The scope of human validation is not narrowed on the grounds that the agent “rarely gets it wrong”. Also ask for a setting surface by surface: a global approval ends up slowing down a team in a hurry, and on that day it gets dropped altogether.

The five-stage workflow and the fallback answers

A company agent runs a chain, not a conversation. Five stages structure it, each one observable:

• the trigger: a user request, an incoming ticket, a scheduled event;
• the context collection: authorized documents, useful history, nothing more;
• the production: answer, summary, proposed action;
• the check: verification list, logs, human validation when the surface demands it;
• execution, if it is authorized, and its logging.

Each workflow carries explicit limits: source scope, mandatory steps, a stopping point before any irreversible action. Also prepare the fallback answers, the mark of agents that stay in production: “I do not know”, “I have to escalate”, “here are the documents to check”. The third is specific to an agent grounded in internal documents: it does not claim to answer, but it hands back control with enough to decide in two minutes.

Specifying and testing: what low-code does not excuse

Configuring an agent without code shortens the start-up, not the specification: the more the agent acts (writes, routes, publishes), the more you have to formalize the edge cases and test:

• What speeds things up: templates, reusable instructions, standard connectors, fast iterations.
• What has to be specified: the definition of “good”, the tone rules, the authorized sources, the escalation thresholds.
• What has to be tested: outdated data, permissions, sensitive content, conflicts between sources.

The five-stage creation sequence

A high-performing agent is not “general-purpose”: it has a role, objectives, constraints and quality criteria. The sequence that holds is always the same:

• Define the role and the objective: what the agent does, on what scope, with what measurable objective (time saved, errors avoided, escalation rate).
• Write the instructions and the constraints: what it must never do (invent a policy, act without validation, expose sensitive data) and when it escalates.
• Connect the sources you have retained, with the minimum rights needed, with no “just in case” scope.
• Set stable outputs: constant formats, systematic citation of the documents consulted.
• Test on a set of real cases, then switch on human validation before any sensitive action.

The second line decides everything: an agent whose prohibitions are not written down has no guardrails, it has habits, and they change at the next change of model.

The tests that have to fail

A test set made of normal questions only shows that the agent works when all is well. The useful acceptance check is made of “trap” cases, built to provoke a clean failure and replayed at every widening of the scope:

• Contradictory information: two documents that say the opposite. The agent must apply the chosen behaviour (decide, flag or refuse), not improvise a third one.
• Lapsed documents: an old version left inside the scope. The agent must cite the version in force, or acknowledge that it does not know which one it is.
• Permissions: a question asked by a profile with no access to the source that answers it. The right answer is an explicit refusal, not an evasive answer drawn from the forbidden document.
• Leaks and source confusion: a request built to extract restricted content, or to pass an external source off as an internal one.

Every test carries an expected result written in advance, otherwise review becomes a matter of opinion. The criterion is stated in the negative: you are not looking for the best answer, you are looking for the absence of a wrong answer stated with confidence.

Governing the agent and getting it adopted

A company agent does not “replace” a process: it runs it faster. A process still has to exist and somebody has to answer for it: who creates, who approves, who audits, who cuts the agent off in case of an incident. Four roles answer that, and the second is the one most often left vacant:

• a business owner, who decides what the agent does;
• a data owner, who answers for the connected sources and their freshness;
• a security lead, who arbitrates the scopes;
• reviewers, who approve the high-risk surfaces.

Add written policies (authorized sources, publishing rules, escalations) and reviews based on the logs. Measurement follows the same logic: four dimensions, each with an indicator and what you are looking for behind it.

Keep expectations sober: the gain shows up on these four indicators, flow by flow, not in a global promise.

Adoption depends on the teams' ability to phrase good objectives, to understand the limits and to document “what works”. The main brake is internal skills, not the tool. Formalize a kit:

• a usage guide;
• examples of requests that work;
• quality rules;
• a feedback loop to the business owner.

Continue reading

Depending on your situation, the next article in the cluster takes over:

• Your teams do not know what to ask the agent: the criteria for assessing AI agent training will tell you what to ask of a programme.
• Your first agent is a support agent: the automatable scope, the handover to a human and resolution indicators are covered on the AI customer service agent.
• The sources are chosen, what remains is connecting them: connectors, data exchange and recovery on error belong to AI agent integration.
• The pilot held, the question becomes full deployment: permissions at scale, indicators and total cost of ownership are the subject of the AI agent for business.

If your need goes beyond configuring an off-the-shelf tool, an agent designed on your data and your access rules falls under our personalized AI offer.

FAQ on AI agents on Dust and the Dust Platform

What is Dust?

Dust is an enterprise AI agent platform: it is used to create, deploy and govern specialized agents connected to an organization's internal tools and knowledge. It does not supply a model but a layer above the models: connectors to internal sources, rights spaces, orchestration between agents and logging of usage, at the time of writing.

What is the Dust Platform and what exactly does it cover?

At the time of writing, the Dust Platform refers to three blocks: a context layer, which connects the agent to the internal sources and manages what it is allowed to read; a tools layer, which lets it act beyond a text answer; and an enterprise layer (identities, permission spaces, roles, logs). What it covers for you is checked in the contract.

How do you create an agent on Dust?

An agent on Dust is created in five stages: define the role and the measurable objective, write the instructions and the prohibitions, connect the sources you have retained with minimal rights, set stable outputs that cite the documents consulted, then test on real cases before any sensitive action. Configuration takes little time; specification takes a lot.

Which use cases are the most relevant in B2B?

The relevant use cases combine volume, repetition and a need for internal context: answering and routing in support, briefs and quality control in marketing, meeting preparation and tenders on the sales side, guided queries and reporting on the data side. The common criterion is the existence of internal sources kept up to date.

Does Dust suit a low-code approach for enterprise agents?

Yes: configuration does not require writing code, and business profiles can steer advanced behaviours. As soon as the agent acts (writes, routes, modifies), however, quality depends on the precision of the rules, the tests and the governance. Low-code shortens the start-up; it excuses no specification.

What data and access-rights prerequisites come before connecting your sources?

Three clarifications come before any connection: which sources prevail, who has access to what, and which data is time-bound and therefore has to be kept up to date. Then set rights by space and by role that reproduce your existing permissions, rather than an over-broad service access, and check that the logging covers the input, the sources consulted and the output.

How do you reduce hallucinations and make an agent's answers reliable?

You make an agent reliable by restricting its sources to official, versioned reference bases, forcing citation of the documents consulted, building trap tests (contradictions, lapsed documents, permissions) and switching on human validation for legal, finance, brand and irreversible actions. Freshness matters most: a lapsed piece of data produces an answer that is credible and yet wrong.

Which indicators should be tracked to measure an agent?

Four indicators measure a company agent: the rate of answers approved or corrected (less human editing at constant effort), the escalation rate on sensitive cases (the agent knows how to stop), the average handling time (a reduction with no loss of quality) and the completeness of the logs (every answer stays auditable).