A Security Checklist Before Connecting AI to Your Tools

Key Takeaways

• The risk is not the AI thinking. It is the AI acting. Reading a dashboard is low-stakes. Sending an email to a customer or editing a billing record is not.
• Scope access to the job, not the whole account. Connect the tools the work needs, at the permission level it needs, and nothing more.
• A human approval step is the single most important control. Review-first means the AI drafts and stages, but a person signs off before anything sends or commits.
• You should be able to see what it did and undo a connection instantly. Audit logs and one-click revocation turn trust into something you can verify, not just hope for.
• Ask vendors the boring questions. Where does data go, what is logged, what is the compliance posture, and what happens to access when someone leaves.

Publicly reported AI incidents are climbing fast: Stanford's 2024 AI Index recorded a sharp year-over-year jump. Most of those stories are not about a model saying something wrong in a chat window. The ones that hurt a business are about an AI taking an action it should not have, sending the wrong message, touching the wrong record, exposing data it was handed too freely.

That is the right way to frame the decision. Connecting an AI to your tools is not inherently risky; connecting it carelessly is. Before you give any AI access to your CRM, your inbox, or your billing system, run the checklist below. It is the same one we would want a customer to run on us.

Why "acting" is the line that matters

A useful mental split: there is a world of difference between an AI that reads and an AI that writes. An AI that reads your analytics and summarizes it can be wrong, but the blast radius is a bad sentence you can ignore. An AI that writes, sends an email, moves a deal, issues a refund, can be wrong in ways that reach customers and money.

Almost every item below exists to make the write side safe. You are not trying to stop the AI from thinking. You are trying to make sure nothing leaves the building without a human nodding first.

The pattern is clear: the more irreversible the action, the more controls it needs around it.

The pre-connection security checklist

Run through these before you connect anything. Treat any "no" as a reason to slow down.

• Scope the access. Can you grant only the specific tools the task needs, at the permission level it needs? Connecting an AI to your entire Google Workspace when the job only needs one inbox is the most common over-grant.
• Confirm a human approval gate. Does the AI draft and stage changes and wait for sign-off before sending or committing? This is the control that makes everything else lower-stakes.
• Check the audit trail. Can you see a record of what the AI read and what it changed, after the fact? If you cannot review it, you cannot trust it.
• Understand data handling. Where does your data go, is it used to train models, and is it encrypted in transit and at rest? Get this in writing.
• Verify revocation. Can you cut a tool's access in one click, immediately, without a support ticket? Fast off-switches matter more than promises.
• Map offboarding. When a teammate leaves, does their access and the AI's access tied to them get cleaned up? Stale access is how quiet breaches start.
• Review the compliance posture. Does the vendor hold a recognized security certification, and can they show you the report?

The over-grant trap

If you only fix one thing on that list, fix scope. The most common security mistake with AI tools is not a dramatic breach; it is quietly granting far more access than the job needs, because the broad option is the default and the narrow one takes an extra minute.

A concrete version: a team wants an AI to summarize one shared support inbox, so they connect their entire email and calendar workspace because that was the one-click option. Nothing bad happens on day one. But now an AI has read access to every executive's calendar and every private thread, for a task that needed exactly one mailbox. The fix costs nothing and is purely a habit: ask "what is the smallest grant that lets this task work," and start there. You can always widen access later; you cannot un-expose data an over-broad connection already touched.

How review-first changes the risk math

The single highest-leverage item on that list is the approval gate, so it is worth seeing in practice. Here is a finance task that touches money, exactly the kind you would never want an AI doing on its own:

@Viktor pull this week's overdue invoices from Stripe, draft a polite
payment reminder for each customer, and show me all of them in my DM.
Do not send anything until I approve each one.

Notice the last line. The AI does the tedious gathering and drafting, the part that wastes an afternoon, but the irreversible action, sending a customer a payment reminder, stays behind a human gate. That is what review-first means, and it is Viktor's default. You can loosen it deliberately as trust builds, for example letting him create internal tasks on his own while customer-facing messages always wait. The point is that you choose where the brake sits, task by task.

How Viktor maps to the checklist

We built Viktor to pass his own checklist, so here is the honest mapping. Viktor connects to 3,200+ tools with scoped access, so you grant only what a job needs, whether that is read-only reporting from Stripe, send access to Gmail, or record updates in HubSpot. He is review-first by default, so he drafts and stages and waits for approval before acting, and he works inside Slack and Microsoft Teams where the approval can happen in the open. Connections can be revoked, and Viktor is SOC 2 Type I and hosted by default, so access is auditable rather than a black box.

For the deeper version of this argument, is your AI agent safe covers the threat model, don't let your AI agent act without asking makes the case for the approval gate, and the evaluating AI agents checklist extends this list to capabilities beyond security.

Frequently Asked Questions

Is it safe to connect an AI to my CRM and email?

It can be, if the AI scopes its access to what the task needs, waits for human approval before sending or changing anything, logs its actions, and lets you revoke access instantly. The danger is unscoped access with no approval gate, not connection itself.

What is the most important AI security control?

A human approval step. If the AI drafts and stages changes but a person signs off before anything irreversible happens, the impact of a mistake drops dramatically. Everything else on the checklist supports that one control.

What should I ask an AI vendor about security?

Where your data goes and whether it trains models, what is logged and whether you can audit it, how fast you can revoke access, what happens at offboarding, and what security certification they hold. Ask for the report, not just the claim.

What does review-first mean?

Review-first means the AI prepares the work, a drafted email, a staged record change, then waits for a human to approve before it sends or commits. Viktor works this way by default, and you can adjust the gate per task as trust grows.

Does Viktor meet these security requirements?

Viktor uses scoped, revocable access to each connected tool, is review-first by default, and is SOC 2 Type I and hosted by default with auditable actions. That maps to the core items on this checklist.