What It Touches
Is it safe to give an AI vendor access to your CRM? What it reads, what leaves your network, who owns the automation after they're gone, and what to put in writing.
Want this inside your company?
Tell us the outcome you need, and we'll show you what we can build.
Problem: You are about to let an outside AI vendor into your CRM, the software your company uses to track customers and deals. Your CFO asks three reasonable questions. What does it read? What leaves our network? Who owns it when you're gone? Most vendors answer with a link to a security page and a confident smile.
Quick Win: Get the answers in writing before anyone issues a key, and make the scope a list, not an adjective. "Read-only" is not one setting. Read-only on four named record types is a completely different risk from read-only across an entire account. Below is how we answer all three questions, including the parts that make us look worse.
The Three Questions Nobody Puts In Writing
Every serious buyer asks the same three things, usually in the same order, usually in a room where the vendor is not present.
- What does it read? Not "your data" in general. Which systems, which records, which fields.
- What leaves our network? What gets copied, where the copy lives, who else can see it, and how long it is kept.
- Who owns it afterwards? When the project ends, what do we have, and can it be taken away?
Most vendors have never written down an answer to any of these. They have a security page, a compliance badge, and a contract drafted for a login-based software product, not for someone building a working system inside your company. If you ask for a scope list and get a marketing PDF, you have learned something.
Read-Only Is Not One Thing: Four Levels of Access
Here is the ranking we use, ordered by how much damage one stolen key does. "Read-only" means the vendor's software can look at your records but cannot change or delete them.
| Level | What it can do | Damage if the key is stolen | When it's the right choice |
|---|---|---|---|
| 0. Export only | You run an export, we get a file. No connection at all. | One file, frozen at one moment. Nothing keeps flowing. | First diagnosis, one-off analysis, anything touching sensitive records |
| 1. Read-only, named fields | Reads a written list of record types and fields, nothing else | Exactly what's on the list, continuously, until the key is cancelled | Monitoring, reporting, watching for changes. This is the default. |
| 2. Read-only, whole account | Reads everything in the system | Everything, including the fields nobody remembered were in there | Almost never. Convenient for the vendor, expensive for you. |
| 3. Read and write, named fields | Can also create or update specific records | Records can be changed or deleted, not just copied | Automation that has to update the system, with a change log and a way to undo |
Most vendors ask for Level 2 because it is faster to set up. Most work only needs Level 1. The gap between those two is where breaches get expensive.
A real example. In August 2025, attackers stole the login keys behind an AI chat tool's connection to Salesforce and pulled data out of more than 700 organizations, including Cloudflare, Palo Alto Networks and Zscaler (The Hacker News, Arctic Wolf). Those keys are OAuth tokens: a long-lived pass your system hands a vendor's software so it can log in without a password, and which keeps working until someone cancels it.
Here is the lesson. The attackers were not mainly after sales records. They searched what they pulled for cloud access keys and passwords that employees had pasted into support tickets over the years (Unit 42). Read access alone was enough, because your CRM is not just a customer list. It is a filing cabinet full of things people typed into a text box and forgot.
Read-only limits the damage. It does not eliminate it. Anyone who says otherwise is selling.
What Leaves Your Network, What Never Does
Three categories, and they are not equally risky.
Never leaves. Work that runs inside your own accounts, with your own keys. We build here whenever the job allows it, because the safest copy of your data is the one that was never made.
Leaves, is processed, is not stored. A record's text goes to an outside AI provider, comes back as a summary or a score, and nothing is kept beyond however long that provider says it holds requests.
Leaves and is stored. A copy sits outside your walls: a database, a spreadsheet, a vendor's test system. This is the category that causes incidents, and the one to question hardest.
Now the part that makes us look worse. If a customer record's text goes to an AI model to be summarized or scored, that text left your building. A contract can name which provider sees it, cap how long it is kept, and forbid training on it. It cannot undo the trip. Anyone claiming "your data never leaves your network" while running it through an outside AI provider is either confused or lying. The honest version is a table sorting every piece of data into one of those three buckets, handed over before you sign.
The Risk Is Already In The Building
The argument for caution, stated as strongly as it deserves. In the 2025 Verizon Data Breach Investigations Report, an analysis of more than 22,000 incidents including 12,195 confirmed breaches, the share of breaches involving a third party doubled, from 15% to 30% (Verizon). Letting an outsider in is a real category of risk, and it grew fast.
Now the part nobody puts in the risk memo. The comparison your CFO is making, approved vendor access versus no AI touching your data, is not the choice you have. Your team is already doing it.
- 27% of employees admitted using AI tools their company had not authorized (1Password, via Infosecurity Magazine)
- 78% of workers who already use AI on the job admitted using tools their employer had not approved (WalkMe)
- 81% of workers, and 88% of security professionals, reported using unapproved AI tools, with fewer than 20% sticking to company-approved tools only (UpGuard)
The spread is wide because each survey asks different people different questions. WalkMe only polled people who already use AI at work, which is why its number sits high. Treat the range as the finding: somewhere between a quarter and most of your staff. And the detail that should end the debate: UpGuard found that while mid-level managers and junior staff had the highest overall use, executives were the heaviest regular users (Cybersecurity Dive). There is a decent chance the person asking whether it is safe to connect an AI vendor pasted company data into a chat window last week.
So the real comparison is a narrow, logged, cancellable connection versus unlogged copying you will never see. One produces a record. The other produces a surprise.
Who Owns It Afterwards
This is the question that gets skipped, and it is the expensive one. Name four things separately, because vendors are vague about exactly one of them.
Your data. Yours, permanently. Plus a deletion deadline: every copy destroyed within a fixed number of days of the project ending, with written confirmation.
The files and the code. Ask for ownership to transfer to you on delivery, not a licence. A licence is permission to use something the vendor still owns, and permission can be withdrawn or repriced later. Ownership cannot.
The written instructions that drive the system. This is the one vendors get cute about, because the instructions are the product. If the code is yours but the instructions are "our proprietary methodology," you own an empty box. Name them in the same clause as the code.
The operating guide. How to run it, what breaks, what to check weekly. Without this you own something you cannot operate, which is the same as not owning it.
One legal wrinkle before you write that clause. In January 2025 the US Copyright Office concluded that copyright requires human authorship, that prompts alone do not give the user authorship of AI output, and that AI-generated material without sufficient human contribution is not copyrightable (U.S. Copyright Office, Part 2: Copyrightability). So a vendor promising to "assign you the copyright in the AI-generated output" may be handing over something nobody owns. What protects you is possession, not copyright theory: the files sit in your own storage, under your own account, with an unrestricted right to use them, change them and hand them to anyone else.
What To Put In The Contract, In Plain Words
Seven clauses. None of them require a specialist to understand.
- A scope list, by name. Named systems, named record types, read or write. Anything not on the list needs written approval first.
- Where copies live and for how long. Every storage location outside your systems, named, with a deletion deadline and written confirmation.
- Everyone downstream, named. If an outside AI provider or a hosting company sees your data, name them. "Trusted partners" is not a name.
- No training on your data. Explicit, not implied.
- You issue and cancel the keys. Plus a current list of which keys exist, so you can kill them all in an afternoon.
- Ownership transfers on delivery. Files, code, written instructions, settings, operating guide. Owned by you, not licensed to you.
- An exit clause with a date. What you receive, in what format, within how many days, whether the ending is friendly or not.
And one clause to stop relying on. "The vendor indemnifies us," meaning the vendor promises to cover your costs if something goes wrong, is not the shield people think it is. Colorado rewrote its AI law in 2026. SB 26-189, signed in May 2026, repeals and replaces the 2024 Colorado AI Act and takes effect 1 January 2027. It splits fault between the company that builds an automated decision system and the company that uses it, and it voids any contract clause that tries to make one party cover the other's own discriminatory acts in a decision with real consequences for a person (Colorado General Assembly, Crowell & Moring).
Two caveats, in fairness. The law covers automated decisions that materially influence outcomes like employment, lending, housing and insurance, so a system that drafts proposals is probably outside it, and the Colorado Attorney General has said enforcement will not begin until the rulemaking process finishes. This is not legal advice. But the direction is clear enough to plan around: you cannot buy your way out of responsibility for how you use the thing.
Where This Approach Is The Wrong Fit
Five situations where we tell people not to do this, or not to do it with us.
The value requires data we should not touch. Patient records, card numbers, anything under a regime with real teeth. If the win only exists inside that data, build and run it entirely inside your own walls with your own people.
Nobody internally owns the credentials. If no one can answer "who can cancel this key today, without a ticket," stop. That is not an AI problem. It is a control problem, and adding a vendor makes it worse.
The review costs more than the finding. If a six-week security review burns more than the leak we would have found, do the Level 0 version. You export, we analyze, nothing gets connected. Less elegant, and it usually surfaces enough to justify the deeper version later.
You want a black box. Some buyers want a vendor who keeps the method secret so the dependency stays. We do not build things only we can run.
You need a large liability cap. A liability cap is the maximum a vendor agrees to pay if their work causes damage, and this one costs us work. A small team cannot carry the insurance a large vendor can. If your legal team requires eight figures of coverage, buy from someone with eight figures of coverage. That is a reasonable requirement and we will say so.
Related Reading
- Done-for-you vs SaaS vs consultants, where the ownership answer differs across all three
- The reliability iceberg, what keeping one of these running costs after handover
- A ranked map of where you lose time and money, the project that usually runs at Level 0
Frequently Asked Questions
Can we start without giving any access at all?
Yes, and it is often the right first step. You run an export, we work from the file, nothing is connected and no key is issued. That is enough to produce a ranked map of where the money leaks. The tradeoff: a file is a snapshot, so anything that needs to keep watching your systems eventually needs a real connection.
How do we know what it actually read?
Ask for the log, and ask before you sign. Every connection should produce a readable record of which records were touched and when, held in your systems, not the vendor's. If a vendor cannot produce that, the honest reading is that they do not know either.
Does read-only mean we're safe?
Safer, not safe. Read access cannot change or delete records, which removes the worst outcomes. It can still copy everything in scope, and your CRM holds years of things people typed into free-text boxes, including passwords. That is how attackers turned read-only connections into a much larger problem across 700 organizations (Unit 42). Narrow the scope, log the access, keep the ability to cancel a key in one click.
If you're stuck between an AI project that needs data and a security review with no end date, the fix is not more policy. It is a smaller scope, written down. We start most projects at export-only access, show the finding first, and put the scope list, the storage table and the ownership clause in writing before anyone issues a key. See what we install inside companies →
Want this inside your company?
Tell us the outcome you need, and we'll show you what we can build.
Before You Sign
Twelve questions to ask an AI implementation partner before you sign, grouped by what they protect you from. Four of them would disqualify us.
AI for the CFO
The four finance numbers a CFO should automate first, ranked by payback: month-end close, collections and DSO, forecast prep, and board reporting.