Security Due Diligence Before You Hire an AI Employee

It is a Tuesday afternoon and your ops lead is staring at an OAuth consent screen. The new AI assistant wants read and write access to Gmail, full CRM access in HubSpot, read access to Stripe, and permission to act on the team's behalf in Jira. One click grants all of it. The security questionnaire your IT person keeps in a Google Doc was written for ordinary SaaS tools, and it has no question that covers what happens when software can read every deal, every invoice, and every email thread, then act on what it reads. That gap is the whole subject of AI employee security, and closing it before you click Allow is the point of this guide.

This is not a compliance checkbox exercise. It is a short list of questions where the answer actually changes your risk, plus the weak answers vendors give when they hope you will not push, plus what a strong answer sounds like. You can run the whole process in two weeks without a security team.

Why AI Employee Security Is Not Ordinary SaaS Security

When you buy a normal SaaS tool, you hand it one slice of your data. Your help desk tool sees tickets. Your accounting tool sees the ledger. The blast radius of a breach is one system.

An AI employee inverts that. Its entire value proposition is breadth: it answers questions by reading across Gmail, Salesforce, Stripe, Notion, and your database at the same time. That means a single vendor now holds, or at minimum can reach, a cross-section of your company that no other tool holds. Three consequences follow.

First, the credential problem multiplies. The vendor is not storing one API key. It is storing OAuth tokens and keys for ten or twenty systems per customer, and those tokens are exactly what an attacker wants, because each one is a skeleton key to a system you actually run your business on.

Second, the data flow is continuous and hard to see. A traditional integration syncs a defined object on a defined schedule. An AI employee pulls whatever context the current question needs. Unless the vendor shows you what was read and why, you cannot reconstruct the flow after the fact.

Third, the model layer adds a question that did not exist five years ago: does anything my team types, and anything the system reads from my tools, end up training someone's model? That question has a precise answer at every vendor, and you are entitled to it in writing.

So the due diligence is different in kind, not just degree. The rest of this guide walks the five areas that matter: encryption, isolation, training-data policy, credential handling, and breach process, in roughly the order a real evaluation should hit them.

Map the Blast Radius Before You Read a Single Policy

Before you send a vendor anything, spend thirty minutes on your own side of the table. Write down, in a plain list, which systems the AI employee would connect to and what the worst plausible outcome is for each.

Be concrete. Gmail read access means every offer letter, every legal thread, every password reset email. HubSpot write access means someone could silently edit deal stages or export your entire contact database. Stripe read access means revenue, customer payment history, and churn are visible. Jira access means your unreleased roadmap. A direct database connection means whatever is in the tables you expose.

This list does two jobs. It tells you which vendor questions to weight heavily: if you are connecting Stripe and a production database, isolation and credential handling dominate; if you are mostly connecting Notion and Jira, training-data policy may matter more than token storage. And it forces the scoping conversation early. The cheapest security control available to you is not granting a scope at all. Most platforms let you connect read-only where write is not needed, and connect a restricted database user instead of an admin one. If you have not already decided who on your team can grant these connections and what they are allowed to include, work through how to scope an AI employee's access before you evaluate anyone.

Encryption: The Questions Behind the Checkbox

Every vendor page on the internet says "encrypted at rest and in transit." The phrase is so universal it carries almost no information. The follow-up questions are where vendors separate.

Ask what algorithm and mode is used at rest. AES-256 is the expected answer, and a vendor should say it without hesitation. Ask whether encryption at rest covers only the primary database or also backups, file storage, and logs. Logs are the classic gap: a system that encrypts its database but writes request bodies containing your CRM records into plaintext logs has not meaningfully encrypted anything.

Ask about transit. TLS 1.2 minimum, TLS 1.3 preferably, on every hop, including hops between the vendor's own internal services, not just the hop from your browser.

Then ask the question that actually distinguishes AI platforms: are stored credentials and tokens encrypted separately from ordinary application data, with separate keys? Your OAuth tokens are the most dangerous thing the vendor holds. A vendor that treats a Google refresh token with the same care as a display-name field has made a design decision you should know about.

For calibration, this is the standard we hold ourselves to at Skopx: AES-256 at rest, TLS 1.3 in transit, and connected-tool credentials handled as a distinct, higher-sensitivity class of data. Any serious vendor should be able to state its equivalents in one paragraph, from memory, without routing you to legal.

Data Isolation: One Tenant's Leak Is Every Tenant's Problem

Almost every AI platform you will evaluate is multi-tenant. Your data and another company's data live in the same infrastructure, separated by software. The question is what kind of software.

The weak version is application-level filtering: every query is supposed to include a "where organization equals yours" clause, written by hand, by every engineer, in every code path, forever. One forgotten clause in one endpoint and Company A sees Company B's data. This failure mode is common enough across the industry that you should assume it will eventually happen anywhere isolation depends on developer discipline alone.

The strong version enforces isolation below the application. Database row-level security policies mean the database itself refuses to return rows outside your organization, even if the application code has a bug. Skopx runs per-organization row-level isolation for exactly this reason: the enforcement lives in the layer that does not forget.

Questions to ask, verbatim: Is tenant isolation enforced in the application layer or the database layer? Has a third-party penetration test specifically probed cross-tenant access, and can I see the summary? What happens to my data, all of it, including embeddings and cached context, when I delete my account?

That last one matters more for AI platforms than for regular SaaS. AI systems create derived copies of your data: vector embeddings for search, cached retrievals, conversation history that quotes your documents. Deletion has to reach the derivatives, not just the originals. A vendor that has thought about this will name the derived stores unprompted. One that has not will say "we delete your data" and stop, and you should not stop there with them. The broader questions of retention and derived data are worth their own pass, and the data privacy side of hiring an AI employee covers them in depth.

Training-Data Policy: Where Your Data Goes After the Answer

This is the question your leadership will ask you, so get the answer in writing.

There are three distinct flows to pin down, and vendors love to answer only the first.

One: does the platform vendor train its own models on your data? The answer you want is an unqualified no, in the contract, not just the marketing site.

Two: what do the underlying model providers do? Most AI employees are built on top of foundation models from Anthropic, OpenAI, or Google. The commercial API terms of the major providers state, as of mid-2026 and per their public documentation, that API inputs and outputs are not used for training by default. Confirm which providers your vendor uses, confirm the vendor is on commercial API terms rather than consumer terms, and confirm no vendor-side setting opts you into data sharing for model improvement.

Three: the sneaky one. Does the vendor use your data to improve its own product in ways short of model training? Fine-tuning ranking systems, mining prompts for feature research, human review of conversations for quality. None of these are automatically disqualifying, but each should be disclosed, and human review of your CRM-derived conversations is something your legal team gets to opine on before it happens, not after.

Skopx's position on flow one is simple and contractual: customer data never trains models. Whatever platform you choose, insist on the same sentence with the same lack of qualifiers.

Credential and Token Handling: The Part Everyone Skips

Here is the uncomfortable truth about the AI employee category: the model is rarely the biggest risk. The credential vault is.

When you connect Gmail, HubSpot, Stripe, and your Postgres instance to a platform, that platform is now a custodian of tokens that can read and write your business. Attackers know this. A breach of the vault is a breach of every connected system for every customer at once. Your due diligence should treat this topic with the same seriousness you would apply to a password manager, because functionally that is what you are buying alongside the AI.

Concrete questions. Are tokens encrypted with keys held separately from the database they live in? Who at the vendor can decrypt them, and under what process? Are the minimum OAuth scopes requested per integration, or does every connection ask for everything up front? Can I revoke a single integration instantly from my side, and does revocation actually invalidate the stored token rather than just hiding the button? Is there an audit log showing every time a credential was used, which action used it, and who triggered that action?

The audit log question doubles as a product-quality question. A platform that logs every tool action with its trigger can show you, line by line, what the AI did on your behalf. That record is what makes it possible to verify an AI employee's work instead of trusting it, and it is the difference between an incident investigation that takes an hour and one that takes a week.

Related: ask what the AI is allowed to do without a human clicking approve. Reading is one risk tier. Writing, sending, and deleting are another. The pattern to look for is approval-gated action: the AI drafts the Jira update or the email, a human approves, then it executes. Autonomy is fine for read-only surfaces like briefings and monitoring; it deserves an explicit human-in-the-loop policy everywhere state changes.

Breach Process: Ask While Nothing Is on Fire

Every vendor will eventually have a security incident of some size. The differentiator is not a perfect record; it is whether the vendor has a rehearsed process and a track record of honesty.

Ask four things. What is your notification commitment, in hours, written into the contract? Seventy-two hours to notify affected customers is a common contractual standard, borrowed from GDPR's regulator-notification clock; shorter is better, and "as required by law" with no number is a dodge. Second, what exactly would you tell me: will I get the affected data categories and the affected connected tools, or a vague "some customer data may have been accessed"? Third, have you had incidents before, and how did you communicate them? A vendor that says "yes, in 2024, here is the postmortem" is showing you maturity, not weakness. Fourth, who is the named security contact, with an email that a human reads?

Then ask about the compliance artifacts, with correct skepticism. A SOC 2 Type II report means an auditor watched the controls operate over months; ask to read it under NDA rather than accepting the badge. If a vendor describes itself with a phrase like "SOC 2 controls in place," that is an honest statement that the control set exists without an implied completed audit, and you can ask directly what stage the audit is at. Vagueness in either direction, badge with no report or claims with no specifics, tells you something. Skopx uses exactly that phrasing about itself, controls in place, because precision about security claims is itself a security signal.

The AI Employee Security Questionnaire, Scored

Send these in your first email, before the demo if you can. The middle two columns are how you grade the replies.

Scoring is simple: a strong answer earns the next meeting, a weak answer earns exactly one follow-up, and a weak answer to the follow-up ends the evaluation for that vendor. There are enough platforms in this category that you never need to talk yourself into one.

AI Employee Security Red Flags That End the Conversation

Some findings are not negotiation points. They are exits.

The vendor cannot say which foundation-model providers it uses. You cannot evaluate a training-data policy through a vendor that will not name its own supply chain.

Every integration demands maximum scopes. If the platform wants full Gmail send-and-delete to answer questions about your inbox, the vendor optimized for demo speed over your blast radius.

No audit log of actions. An AI employee whose work cannot be inspected after the fact is unverifiable by construction, and unverifiable systems fail in ways you discover from your customers. This is the same root cause behind many stories of why AI employees fail in their first quarter: not malice, just nobody watching the log because there was no log.

Security answers only available under sales pressure. If the questionnaire answers require three calls and an executive sponsor, the honest reading is that the answers do not survive being written down.

A silent right to train on your data buried in the terms. Search the terms of service for "improve," "train," and "machine learning" yourself. Five minutes, occasionally decisive.

How to Run the Evaluation in Two Weeks

Week one: blast-radius list on day one, questionnaire emailed to two or three vendors on day two, answers graded against the table above by day five. Kill anyone with two weak follow-ups.

Week two: hands-on pilot with the finalists, scoped deliberately. Connect one low-stakes tool, maybe Notion or Jira, with read-only access. Confirm the audit log shows what was read. Test deletion: remove a document, ask a question that would have needed it, confirm the answer no longer draws on it. Revoke the integration and verify from the tool's own security page (Google's third-party access page, HubSpot's connected apps list) that the grant is actually gone. Vendors describe their revocation behavior; the tool's own page proves it.

Then write down what you learned as the beginning of an operating agreement: which tools are connected, at what scopes, who approves new connections, what requires human sign-off. That document, not the vendor's policy, is what your team will actually follow, and a good runbook is where it should live. If you want to see how a platform in this category presents its own answers to everything above, Skopx's AI agents page is a reasonable place to test this guide against a live vendor, ours included: every answer cites its source, actions in your tools run on your instruction with your approval, and the security posture is the one described in this article. Hold us to it the same way you would hold anyone else.

FAQ: AI Employee Security Due Diligence

Do I need a security team to run this process?

No. The questionnaire in this guide is designed to be sent by an ops lead or founder and graded by pattern-matching against the strong and weak answers. What you need is the discipline to actually disqualify vendors on weak answers, which is harder than it sounds when the demo was impressive. If you have a fractional security consultant, the highest-value hour you can buy is a review of the vendor's answers, not the vendor's marketing.

Is a vendor without a completed SOC 2 audit automatically unsafe?

No, and a vendor with one is not automatically safe. A SOC 2 Type II report is strong evidence that stated controls operated over time, and you should read it when it exists. But young vendors can have genuinely strong engineering controls, described precisely, ahead of a completed audit, and describing that state as controls in place is honest. Grade the specificity of the answers and the willingness to put them in the contract. Precision plus contractual commitment beats a badge you were never allowed to read behind.

What is the single most important question if I only get one?

Ask how OAuth tokens and credentials are stored and who can decrypt them. It is the least-rehearsed question, so you get an unpolished answer, and it targets the genuinely catastrophic failure mode: one vault breach exposing every customer's Gmail, Stripe, and CRM tokens simultaneously. A vendor that answers this one well has usually thought about everything else too.

Should the AI employee ever act without human approval?

For state changes in your tools, sending, writing, deleting, the default should be no: the AI drafts, a human approves, the action executes and gets logged. Autonomy is reasonable for read-only surfaces, things like a morning briefing, monitoring that flags what is slipping, or publishing you explicitly scheduled in advance. The decision of when to let AI act without review should be made deliberately per action type, written down, and revisited as trust accumulates, never inherited silently from a vendor's defaults.

How often should I redo this due diligence?

Annually as a floor, and immediately on three triggers: the vendor is acquired, the vendor changes model providers or terms of service, or you expand the connection scope into a new sensitivity tier, such as adding Stripe or a production database to a deployment that previously only touched project tools. The thirty-minute blast-radius exercise is worth rerunning every time someone on the team asks to connect something new.

The Short Version

An AI employee concentrates more of your company's data and credentials in one vendor than any tool you have bought before, so the due diligence has to be sharper than the questionnaire you use for ordinary SaaS. Five areas carry nearly all the risk: encryption with specifics, isolation enforced below the application layer, a contractual no on training, credential handling treated like a password manager's, and a breach process with numbers in it. Grade answers on specificity, disqualify on vagueness twice, verify revocation and deletion with your own hands during the pilot, and write the operating agreement before the rollout. The vendors worth hiring from will respect the process, because they built for buyers who run it.