Connecting an AI tool to your business data shouldn’t mean handing over everything in it.
Tugger® lets you decide, category by category, what an AI tool is allowed to see. Names, pay, addresses, performance records, free text. Set any of it to hidden and it’s withheld before the answer ever leaves Tugger.
Your reporting carries on exactly as before. This governs AI access only.
What the AI receives. Click any setting to change it.
Illustrative. Changes take effect on the next AI call.
AI tools are brilliant at answering questions about your business. Which products make money. Which jobs went over budget. Who owes you what.
But your systems hold more than job numbers and invoice totals. They hold employee pay, home addresses, disciplinary records, next of kin, free text notes somebody wrote about a customer three years ago.
Most people’s answer to that is to not connect AI at all. That’s a shame, because the useful data and the sensitive data sit in the same systems. So we built the controls instead.
The settings live on a page in Tugger called Personal Data For AI. Only a client administrator can see or change it.
Every category of personal data is set to Visible or Hidden. Anything hidden is withheld inside Tugger before the response leaves the platform, so the AI tool never receives it.
Every table is tagged with whose data it holds, and each category is set independently for the two groups.
So you can keep staff names visible for operational reporting while withholding customer names. Or the reverse. Whatever your policy calls for.
Staff covers employees, consultants and trainees. External covers customers, prospects, suppliers, applicants, next of kin and the like. Where the subject isn’t clear, it’s treated as External.
Account rules cover every connected application. Application rules override them for one application type. Connection rules override those for a single connection.
Anything not set anywhere is visible. The settings page shows you where each effective setting comes from, so you’re never guessing which rule won.
Three things stay visible whatever you set, because they rarely identify anyone and reporting falls apart without them.
A control that only hides a field from display isn’t worth much. An AI tool can work around that in one question. So the block covers every route in.
When the AI asks what data exists, hidden fields don’t appear. A table with withheld columns carries a note, so the AI knows it isn’t seeing everything.
The AI is told the field is held back, answers without it, and tells the user something was withheld.
No filtering, grouping, sorting, counting, totalling or averaging on a hidden field. That’s the bit that matters, because an average is a disclosure route just as much as a list is.
Where an application stores structured values, hidden keys are stripped out before the value is passed on.
Records can’t be matched across applications on a field that’s been cleaned.
Some fields can’t be classified ahead of time, mainly ones you’ve created yourself. For those, Tugger inspects each value and removes it where both the field name and the content point to personal data in a category you’ve hidden. Where that happens, the response carries a note so the AI can tell the user.
Every AI call is recorded on the AI Query History page.
Each record holds the version of the settings in force at the time, and what was withheld on that call. Withheld items are recorded by field name only, never by value. The record doesn’t contain the query, the data, or technical error detail.
Every save creates a new numbered version of the whole rule set, showing who saved it, when, and what changed. Previous versions can’t be edited, which is what makes the record reliable as evidence.
The practical effect is that your data protection officer can demonstrate what an AI tool was able to access on any past date, including after the settings have changed since.
Changes take effect on the next AI call. Settings are read fresh every time and never cached.
employee.pay_ratecontact.mobilejob.notesField names only, never values. No query text, no data.
Power BI, Tableau, Excel, whatever you use. Unchanged. It sees exactly what it saw before.
Untouched. Tugger is read-only and never writes back.
Nothing is deleted. It stays in your Tugger database exactly as it was. This governs what AI responses can include, nothing else.
Plenty of organisations aren’t comfortable letting staff connect an assistant directly, and that doesn’t stop you using Tugger.
Connecting an assistant isn’t something a user can decide to do on their own. Three things have to line up.
Connections use OAuth 2.0 with short-lived access tokens and refresh token rotation. Connector permissions are re-checked on every request rather than only at sign-in. And because each connector’s data sits in its own database, a query can’t reach across into another one.
Yes. The controls apply to any AI tool connected to Tugger through MCP, including Claude, ChatGPT, Gemini and others.
Yes. Schema discovery, sample data, counts, single queries, multiple queries and queries spanning applications are all covered equally.
Not by us. Your data sits in your own Tugger warehouse and we never use it to train anything. Your AI provider’s policy is a separate matter and differs by plan, so it’s worth a look at their privacy settings if you’re on a personal tier.
The query history records what was withheld and under which settings, not the query text itself. That’s deliberate, since the log is evidence of access controls rather than a record of what your staff typed.
Send them over. We’d rather answer properly than have you guess.
If your data protection officer wants a call with someone technical, we’ll put that on. We’ve also got a written briefing on these controls, including the limitations, that we’re happy to send over for a formal review.