A Security Checklist Before Connecting AI to Your Tools

Picture the moment. A Thursday afternoon, someone in ops finds an AI assistant that promises to summarize deals and draft follow-ups. They click Connect, an OAuth screen asks for access to "read, compose, send, and permanently delete all your email," and they click Allow because the demo looked great and the sprint ends tomorrow. That click was the entire security review. Nobody wrote anything down. Six months later a security questionnaire asks which third parties can read customer email, and nobody can answer.

This article is the AI security checklist that click deserved. It covers the six things that actually matter before you connect an AI product to Gmail, HubSpot, Jira, Stripe, or anything else that holds real data: scopes, isolation, retention, training-data policy, a revocation drill, and the audit trail. At the end there is a printable version you can run in under an hour per vendor.

None of this requires a security team. It requires a document, a calendar reminder, and the discipline to ask boring questions before granting interesting permissions.

Why an AI security checklist matters before the first OAuth screen

Connecting AI to your tools is different from installing another SaaS app, for two reasons.

First, the blast radius is wider. A project management app that connects to Slack reads a few channels. An AI assistant is useful precisely because it reads broadly: your inbox, your CRM, your ticketing system, your billing data. The whole pitch is "give me everything and I will find what matters." That is also the pitch of every data breach.

Second, the data flows further. A traditional integration moves data between two systems you already vetted. An AI integration typically forwards your data to at least one more party: the model provider. Your CRM notes may now transit the AI vendor's servers and a foundation-model API, each with its own retention policy, each a separate line in your next security questionnaire.

The uncomfortable reality at most small and mid-size companies is that AI tools arrive bottom-up. An account executive connects their inbox. A founder connects the company HubSpot. Nobody involved is negligent; there is simply no checkpoint between "this looks useful" and "this now has standing access to customer data." The fix is not a procurement committee. The fix is a short, repeatable AI security checklist that anyone can run, and a rule that nothing gets connected without it. If you are still choosing a vendor, run it alongside the broader questions to ask before buying an AI agent; the security section is necessary but not sufficient.

Scopes: grant the least access the job actually needs

Scopes are the permissions you approve on the OAuth consent screen, and they are where most damage is either prevented or preloaded.

The failure mode is predictable: vendors request broad scopes because granular ones are engineering work. An assistant that only ever drafts email replies has no need for delete permissions. A tool that reads your CRM to build summaries has no need to write to it. Every unnecessary scope you approve is risk you carry for the life of the connection, and you carry it whether or not the feature that "needs" it ever ships.

Concrete things to check, per tool:

• Gmail / Google Workspace. Google's scopes are genuinely granular. gmail.readonly exists, and so does full mailbox access including delete. If a vendor requests full access for a read-shaped feature, ask why, in writing. Google Workspace admins can also restrict which third-party apps users may authorize at all, under API controls; turn that on before the first employee connects anything.
• HubSpot. Scopes are itemized per object type: contacts read is separate from contacts write, and both are separate from settings access. A summarization tool asking for write access to contacts and workflows deserves a follow-up question.
• GitHub. Prefer fine-grained tokens or GitHub Apps scoped to specific repositories over classic tokens that grant the whole org. "Read access to one repo" and "act as me everywhere" are both one screen away from each other.
• Stripe. Never hand an AI tool your secret key. Stripe supports restricted keys with per-resource read or write permissions; a reporting use case needs read access to charges and nothing else.
• Jira. Watch for global admin scopes hiding inside app installs. Project-level access is usually all a triage or summarization assistant needs.

Two rules of thumb. Start read-only: most AI value in the first ninety days is answering questions, and read-only connections make the worst case "data was seen," not "data was changed or deleted." And when a vendor offers only an all-or-nothing scope, connect a dedicated account with limited visibility rather than a human's full account. The underlying protocol matters here too; how the connection is brokered changes what a stolen credential is worth, which is the subject of MCP vs OAuth for business tools.

Isolation: who can see whose data once the AI is inside

Once your data is inside the AI vendor's system, the question shifts from "what can the AI read" to "who else can read what the AI stored."

Ask the vendor three specific questions:

1. Tenant isolation. Is my organization's data logically separated from other customers, and how? The credible answer names a mechanism: per-organization row-level isolation, separate encryption contexts, scoped database policies. "We take security seriously" is not a mechanism.
2. Intra-company isolation. If my teammate connects their Gmail, can my queries read their inbox? The right answer is no by default, with anything shared being an explicit, visible choice. This is the failure mode that actually bites small teams: one admin connects a privileged account, and every seat in the workspace inherits its reach through the AI's answers.
3. Employee access. Can the vendor's own staff read my data, under what conditions, and is that access logged?

Get the answers in writing, then test question two yourself during evaluation with two accounts. It takes ten minutes and vendors' documentation is sometimes more optimistic than their product.

For what it is worth, this is one of the places where we can speak to our own design at Skopx: data is isolated per organization with row-level policies, encrypted with AES-256 at rest and TLS 1.3 in transit, and anything the AI does inside a connected tool happens on your instruction with your approval. Whatever platform you evaluate, hold it to at least that bar, and make it show you the mechanism rather than the adjective.

Retention and training-data policy: where your data lives after the answer

Every prompt that includes your CRM notes and every answer generated from your inbox exists somewhere for some amount of time. Your job is to find out where and for how long, at every hop.

Map the chain explicitly. A typical AI product has three layers of retention:

• The AI vendor. How long do they keep your prompts, retrieved documents, and generated outputs? Is there a deletion path you can trigger, and does deletion actually propagate to backups on a stated timeline?
• The model provider. Most AI products are built on a foundation-model API. Which one? Under what terms? The major providers offer commercial terms where API inputs are not retained long-term and are not used for training, but those terms vary by product tier and change over time, so ask the vendor to point to the specific agreement they operate under rather than summarizing it for you.
• Subprocessors. Vector databases, logging services, analytics. The vendor's DPA should list them. If there is no DPA and no subprocessor list, that is your answer about organizational maturity.

Training-data policy deserves its own line item because it is the question executives actually ask. "Is our data used to train models?" should get an unconditional no in the contract, not a settings toggle that defaults to yes, and not a "we may use aggregated data to improve our services" clause doing quiet work in paragraph nine. Skopx's position, for the record: customer data never trains models, full stop. Any vendor unwilling to put an equivalent sentence in writing is telling you something.

Finally, ask about retention of the connection credentials themselves. OAuth refresh tokens are keys to your systems; they should be encrypted at rest, and the vendor should be able to say how.

The revocation drill: practice unplugging before you need to

Everyone assumes they can disconnect an AI tool. Almost nobody has actually done it before the day it matters, and revocation has sharp edges that only show up in practice.

The core problem: revocation lives on both sides of the connection, and doing only one side leaves you exposed.

• Vendor side. Deleting a connection in the AI product's settings should destroy the stored tokens. Should. You cannot verify this directly, which is exactly why you also revoke from your side.
• Your side. Google Workspace: Security, then API controls, then app access, where an admin can revoke a third-party app for the whole domain. HubSpot: Settings, Connected Apps, uninstall. GitHub: Settings, Applications, Authorized OAuth Apps. Stripe: roll or delete the restricted key. Each takes about a minute once you know where it is; the drill is knowing where it is.

Run the drill for real during evaluation: connect, revoke from your side only, then watch whether the AI product visibly fails on its next access. If it keeps working, it cached data or holds another credential path, and you want to know that now.

Then put two recurring events on the calendar. Quarterly: list every third-party grant in Google Workspace, HubSpot, GitHub, and Stripe, and kill anything unrecognized or unused. This sweep routinely turns up connections from tools the team abandoned a year ago, one of the quieter items in the hidden cost of tool sprawl. And on every offboarding: check what the departing person connected under their own account, because per-user OAuth grants die with the account only if you actually disable the account.

Audit trail: can you reconstruct what the AI did last Tuesday?

If an AI tool acts inside your systems, you need to be able to answer, after the fact: what did it read, what did it change, who asked, and why.

Minimum requirements worth holding a vendor to:

• Attribution. Actions performed by the AI in Gmail or HubSpot should be attributable to the AI connection and to the human who instructed it, not blended into a human user's activity history. A shared "integration@" identity that six people drive through an AI is an audit dead end.
• Citations on answers. When the AI asserts "this deal stalled after the pricing call," it should show which email, ticket, or CRM record that came from. Uncited answers are unverifiable answers, and unverifiable answers get pasted into decisions. This is a security property, not a UX nicety: citations are how you detect the AI confidently misreading your data.
• Run history for automation. Anything that runs on a schedule or a webhook needs a complete run log: when it fired, what inputs it saw, what it did, what failed, plus versioning so you know which iteration of the automation was live when something went wrong.
• Approval gates on autonomy. Monitoring that notices things is low-risk. Monitoring that acts on things is not. Follow-up actions should require an explicit human approval, and the approval should be in the log.

This set of requirements shaped how Skopx works: every chat answer cites its source, workflows keep versions and full run history, and monitoring follow-ups are approval-gated rather than fired automatically. If you want to see how those pieces fit together in practice, the AI agents overview walks through it. But the requirements stand on their own; apply them to whatever you deploy.

How connection patterns compare on blast radius

Most of the risk in connecting AI is decided by the shape of the credential, before any AI is involved. Here is the comparison that should drive which pattern you accept:

The pattern to prefer is the second row for anything organizational and the first row for anything personal. The pattern to refuse is the last row, and any AI vendor that asks you to paste in a password rather than authorize through OAuth has failed the checklist at step one.

The printable AI security checklist

Run this per vendor, before connecting. Most teams get through it in under an hour once the first vendor has forced the research.

Before you connect

• Written one sentence describing what the AI needs to do, and matched every requested scope against it
• Confirmed read-only scopes are used wherever the job is read-shaped
• Chosen the credential pattern deliberately: per-user OAuth or a dedicated limited service account, never a shared login or a bare admin API key
• Asked the vendor, in writing: tenant isolation mechanism, whether teammates' connected data is visible to other seats by default, and whether staff access to customer data is logged
• Read the DPA, listed the subprocessors, and identified the model provider and the terms it operates under
• Confirmed in the contract that customer data is not used to train models
• Confirmed prompts and outputs have a stated retention period and a deletion path
• Asked for the vendor's security documentation, including any SOC 2 report or a description of the controls in place

At connection

• Connected a sandbox or low-stakes account first, real data second
• Screenshotted the consent screen and filed it, so the granted scopes are on record
• Recorded the connection in a shared register: tool, owner, scopes, date, purpose

Within the first week

• Run the revocation drill: revoke from your platform's side and verify the AI visibly loses access
• Tested cross-user isolation with two accounts
• Located the audit surface: where actions, citations, and run history live

Quarterly

• Swept third-party grants across Google Workspace, HubSpot, GitHub, Stripe, and Jira; revoked anything unused or unrecognized
• Re-checked the vendor's subprocessor list and terms for changes
• Re-run the offboarding check for anyone who left with connections in their name

Copy it into your wiki, put a name next to it, and it becomes policy. Leave it in a browser tab and it becomes trivia.

FAQ: the AI security checklist questions teams actually ask

Is read-only access safe enough to skip the rest of the checklist?

No. Read-only removes the "AI changed or deleted something" failure mode, which is valuable, but reading is exfiltration-shaped by definition: everything readable can end up in prompts, logs, retention systems, and answers shown to the wrong seat. Isolation, retention, training policy, and revocation all still apply with full force to a read-only connection. Read-only is where you start, not where the checklist ends.

Should we ban employees from connecting AI tools themselves?

Bans produce shadow AI: personal accounts, pasted data, zero visibility. A better posture is a paved road: a short approved list, this checklist as the approval process, and platform-level controls (like Google Workspace API app restrictions) so unknown apps cannot be authorized at all. Make the sanctioned path genuinely easier than the workaround and most people take it.

Do we need a DPA with an AI vendor?

If the connected tools contain personal data, which email and CRM systems do by definition, then under GDPR and similar regimes the vendor is processing personal data on your behalf and a DPA is the standard instrument for that. Beyond compliance, the DPA is where subprocessors, retention, and deletion obligations become enforceable rather than aspirational. A vendor with no DPA to offer is early in a way that should inform your decision.

What about prompt injection: can a malicious email make the AI misbehave?

It is a real class of risk: content the AI reads (an inbound email, a webpage, a shared doc) can contain instructions that try to steer it. The mitigations map directly onto this checklist. Minimal scopes cap what a steered AI could touch. Read-only defaults mean steering yields wrong words, not wrong actions. Approval gates put a human between the AI's intent and any write. Citations let you see what the answer was built from. For a broader map of failure modes, see what AI agents can't do.

Does the checklist change for AI that takes actions, not just answers questions?

The items stay the same; the weights change. For action-taking AI, attribution and approval gates move from nice-to-have to non-negotiable, write scopes must be enumerated one by one, and run history needs to be complete enough to reconstruct any incident. Autonomy should live in low-risk surfaces first: briefings, monitoring, scheduled publishing, with anything that mutates a system of record gated behind a human.

How often should we re-run it?

Fully, once per vendor at adoption and again at renewal. The quarterly sweep covers drift in between: new scopes added by vendor updates, new subprocessors, connections orphaned by departures. Vendors change their terms and their model providers more often than you would expect; the register you built at connection time is what makes re-checking fast.

Run the checklist, then connect

The point of an AI security checklist is not to slow AI adoption. Teams that skip diligence do not move faster; they move until the first incident or the first enterprise security questionnaire, and then they stall hard while they reverse-engineer what they connected and why. That stall is a recurring character in why AI pilots stall.

An hour per vendor buys you the opposite position: you know exactly what each AI can see, you can prove what it did, you can unplug it in five minutes, and you can answer a customer's security questionnaire from your register instead of from memory. Scopes, isolation, retention, training policy, revocation, audit trail. Six sections, one owner, on the calendar. Then connect with confidence, because this time the Allow click will actually be the end of the review instead of the absence of one.