The objection almost always arrives in the same shape.

Someone has watched the demo, understood the value, and is halfway to a yes when they stop and say: I'm just not sure about the data. It is said with real conviction and almost no detail, and it usually ends the meeting.

What makes this worth writing about is that the concern is entirely legitimate and the way it gets expressed is almost useless. "Is it secure?" cannot be answered badly. Every vendor says yes. Every vendor means something slightly different by it. The buyer leaves with a reassurance they cannot check and a discomfort they cannot name, and the project quietly does not happen.

The businesses that get this right are not braver than the ones that stall. They just ask narrower questions.

Why the general question fails

Security is not one property. It is at least four separate things that happen to share a word.

There is what the tool can see: which mailboxes, which folders, which channels, and whether that scope is something you chose or something the integration decided by default. There is what it keeps: whether the content itself is stored somewhere or only referenced, and for how long. There is where it goes: which third parties process it on the way through, and in which jurisdiction. And there is what happens on the way out: whether you can get it all back, and whether deleting means deleting.

A vendor can be excellent at one of these and vague on the others, and "is it secure?" will not distinguish between them. Worse, it invites the answer you least want, which is a list of certifications. Certifications describe a company's internal processes. They tell you very little about what a specific agent will do with a specific inbox on Tuesday.

So the questions below are deliberately small. Each one has a wrong answer that is easy to hear.

One. What exactly can this agent see, and who decided that?

The honest version of this question is about defaults. Most integrations request the broadest permission scope that will make the product work, because a narrower scope creates support tickets. Connecting a mail account can mean the agent has access to every message in it, including the ones from your accountant, your lawyer and your GP.

That may be fine. It is fine much more often than people assume. But it should be a decision somebody made rather than a side effect of clicking Allow, and the tool should let you make it. If the answer is that access is all-or-nothing at the account level, you have not learned that the vendor is careless. You have learned that scoping is your job now, and you can do it by choosing which account you connect.

The wrong answer sounds like: we only access what we need. That is a description of intent, not of permissions.

Two. What does it store, and what does it merely read?

There is a real difference between an agent that processes a message and keeps a structured note about it, and one that keeps the message.

The first is a system that knows a client raised a concern about a delivery date on 14 August. The second is a system holding a copy of your correspondence. Both can be run responsibly. Only one of them is a meaningful new place for your data to exist, and if a vendor cannot tell you which one they are, that is the finding.

Ask what a stored record actually looks like. If somebody can show you one, in the product, the answer is real.

Three. Which model providers see this, and under what terms?

Almost every AI product is calling a model it did not build. That is not a scandal; it is the architecture of the entire industry, and pretending otherwise is more suspicious than admitting it.

What matters is the terms. Enterprise API agreements with the major model providers generally include no training on submitted data and limited retention, which is a materially different arrangement from the consumer chat products the same companies sell. Those are not the same contract, and a lot of the anxiety about AI and confidential data comes from applying the reputation of one to the other.

So ask which providers, and ask whether the contract with them excludes training. "We don't train on your data" is a sentence about the vendor. It is not automatically a sentence about the four companies downstream of them, and the difference is worth thirty seconds.

Four. Can I see what it did?

This is the question that separates a tool you can supervise from one you have to believe in.

An agent that acts on your business should be able to show you, after the fact, what it looked at, what it concluded, and what it did about it. Not a status light. A record, with the source of each thing it thinks it knows, so that when it produces something surprising you can find out why rather than guess.

The practical value is not compliance. It is debugging. Every agent will eventually be confidently wrong about something, and the difference between a five-minute fix and a loss of trust is whether you can trace the error to the message that caused it.

Five. What happens when I want it gone?

Deletion is where a lot of otherwise good answers get soft.

There is a version where deleting removes a record from your view. There is a version where it removes the record. There is a version where it removes the record but the derived summary that mentioned it survives in a report from last month. Ask which one, and ask specifically about the things built on top of the data rather than the data itself.

The same applies to leaving. You should be able to get your information out in a form something else can read, and disconnecting an integration should stop new information flowing immediately rather than at the end of a billing period.

Six. Who at the vendor can read this?

Usually somebody can. Support cannot fix what it cannot see, and a company that claims literally no employee can ever access any customer data is either describing a very unusual architecture or has not thought about how support works.

The good answer is not no. The good answer is: a small number of people, only with a reason, only with a record of it, and here is how you would find out. What you are testing is whether the vendor has treated internal access as a thing that needs a rule, or as something that never came up.

What good answers have in common

None of these questions is technical, and none of them requires you to know anything about how the system is built. They share one property: each can be answered by showing you something in the product.

That is the real test. A vendor who answers by opening the tool and pointing at a permissions screen, a stored record, an activity log and a delete button has built for people who ask. A vendor who answers with a PDF has built for procurement. Both may be perfectly safe. Only one of them will still be answerable in eight months when the person who ran the evaluation has left.

Where Kritmatta stands on this

We publish our answers rather than waiting to be asked, because the questions above come up in almost every conversation we have with a business considering their first agent.

Agents ask before they act, so the actions that carry consequence sit behind a person. Everything an agent knows is browsable by category, showing when it was learned and where it came from, and any single memory or whole category can be deleted immediately. Data is encrypted in storage and in transit, kept walled off from other customers, and is never used to train AI models. You choose which data each agent can see and which team members can change it, and export and consent handling are built in for UK GDPR rather than bolted on.

The full detail lives on our transparency page, including the parts that are less flattering to summarise in a sentence.

The question underneath the question

What people are really asking, when they say they are not sure about the data, is whether they will be able to explain this decision if it goes wrong.

That is a reasonable thing to want and it is not satisfied by reassurance. It is satisfied by specifics: a scope you chose, a record you can read, a delete that deletes, and an answer about model providers that names them.

Ask the small questions. They are the only ones with wrong answers.