A Security Checklist Before Connecting Any AI Assistant to Company Data

Someone on your team is going to connect an AI assistant to a company system this quarter. Possibly this week. The integration takes about ninety seconds, which is the problem: the decision is made at the speed of a consent screen and reviewed at the speed of an incident.

This is the checklist we would want a team to run first. It is ordered the way a security review actually proceeds, starting with the questions that can stop the whole thing and ending with the ones that only matter once you have said yes.

The single most common mistake is at number three, and almost nobody gets it right the first time.

1. What data does it reach, exactly?

Not "our Google Workspace." Which mailboxes, which drives, which folders, which records.

Assistants connect at the level the provider offers, and the provider usually offers something broad. A Google Workspace connection is typically mail, documents, spreadsheets and calendar together. A Slack connection may be every channel the authorising user can see, which in most companies is far more than that person thinks.

Write down the actual reachable set. If the honest answer is "everything that person can see," you have found your first finding.

2. Who authorised it, and whose permissions did it inherit?

An assistant connected by an administrator inherits administrator reach. The same connector authorised by an intern is a much smaller problem.

This is worth stating explicitly in your policy, because the natural instinct is for the most senior person to set it up, which is exactly backwards. Connect with the least privileged account that satisfies the use case.

3. Does read access actually mean read-only?

This is the one people get wrong, and it is the most important line in this post.

Content the assistant reads can contain instructions. An email, a calendar invite, a shared document, a Jira ticket, a web page it fetches: any of these can carry text addressed to the assistant rather than to you. If the assistant also holds a connector that can send, post, delete or pay, then a "read-only" connection has become an action path.

This is not theoretical. The ShadowLeak research demonstrated a zero-click exfiltration of Gmail data through an assistant's research agent, and a separate finding showed a compromised calendar invite hijacking an assistant's Gmail connector. Both were patched. The pattern behind them is not patchable, because it is how instruction-following models work.

So the real question is not "is this connector read or write." It is: given everything this assistant can read, and everything it can do, what is the worst sentence someone could put in front of it?

If the answer is unacceptable, the fix is to narrow what it can do, not what it can read, because read access is the part you cannot police.

4. What is the blast radius of the worst allowed action?

List the destructive operations the assistant can reach. Delete, send, pay, refund, revoke, publish, invite.

For each, ask what the largest single instance looks like. Not the typical case. The largest. "It can send email" is fine until you notice it can send email to every address in the CRM.

5. Is there a gate above a threshold, or just a yes/no?

Most connectors are binary: the assistant can use the tool or it cannot. That is authentication, not authorization.

What you usually want is conditional: this operation is allowed, but not above this amount, not outside business hours, not for this customer tier, or not without a human clicking approve. That is a policy, and it needs to live somewhere that is checked at execution time rather than written into a prompt. A prompt is a suggestion. We made that argument in a prompt is not a policy, and the implementation pattern is in policy-as-code for AI agents.

A rule that can be gated looks like this, and lives in version control so changes get reviewed:

{
  "id": "big-refunds",
  "target": ["stripe.refund.create3"],
  "when": { "field": "amount", "operator": ">", "value": 50000 },
  "action": {
    "type": "REQUIRES_APPROVAL",
    "message": "Refunds over 500.00 need approval"
  },
  "approval_timeout": "2h"
}

If your assistant platform cannot express that, note it as a gap rather than assuming the model's judgement covers it.

6. Can you enumerate what it is allowed to call?

"Access to Stripe" is not a permission, it is a category. A reviewable permission is a list of operations.

If you can produce a finite list of the operations an assistant may invoke, and anything outside it fails, you have something a security team can sign off. If the answer is "whatever the catalog exposes," you are approving a surface that changes without your involvement.

This is why an explicit allow list is worth more than it sounds. In our own setup only methods added with swy add method can run at all:

swy get stripe
swy discover "refund a charge"       # find the operation
swy info stripe.refund.create3       # check what it actually takes
swy add method stripe.refund.create3 # allow exactly this one

Anything not on that list fails before a request leaves the machine.

7. Who can revoke it, and how long does that take?

Ask this before you ask what the connector does, because it is the question that matters at 2am.

Can the owning user revoke it themselves? Can an administrator revoke it centrally, for everyone, without contacting the vendor? Does revocation take effect immediately, or at the next token refresh?

Also check what happens when the authorising employee leaves. A connector tied to a departing person's account is either an outage or a ghost, and you want to know which before HR finds out.

8. Where does the data physically go?

The assistant vendor is one hop. Any integration platform between the assistant and your system is another. Each hop is a place your customers' data exists in a form someone could subpoena, breach or log.

For regulated data this is usually the question that decides the architecture rather than refines it. If the answer has to be "it never leaves our cloud account," that rules out most hosted arrangements and points at something deployed into your own AWS, Azure or GCP account. That is what Swytchcode Enterprise is for, and it is worth establishing early because retrofitting it is expensive.

9. What is written down, and by whom?

The test: someone asks why a customer received three emails on Tuesday. Can you answer from a record, without re-running anything?

A log the assistant wrote about its own actions is not sufficient, because it is a record of what the model believed it did, and it systematically omits calls that were blocked or failed before reaching the provider. Those are usually the interesting rows. The record has to come from whatever actually sent the request.

The fields that make a log answer real questions are in logging every API call an agent makes. The short version: operation as a stable identifier, actor, tenant, the policy decision and which rule version applied, status, and whether the response validated. And never the credential.

swy audit network   # what ran
swy audit policy    # what was denied or held

10. How long is the record kept?

Long enough to cover your incident window and whatever you have told customers in a contract. In practice that usually means at least ninety days and often a year.

Check the retention on the actual platform rather than assuming. Short retention windows are common on lower tiers, and the moment you need the log is always after the window has closed.

11. Can a retry do the thing twice?

Not a classic security question, but it belongs on a review because the failure mode is indistinguishable from an attack when you are looking at it at midnight.

Assistant platforms retry failed calls. If the retry is a brand new request rather than the same one, a timed-out payment becomes two payments. Ask whether writes carry an idempotency key across retries. See idempotency explained.

12. Does anyone own this in ninety days?

Connectors are set up by an enthusiast and inherited by nobody. Put a name against each one, and a date to re-review.

The specific thing that rots is scope: providers add capabilities to existing connections, and a permission you approved in October can mean more in February without anyone re-consenting. A connection you have not looked at in a year is not the connection you approved.

The short version

If you only run five of these, run these five.

Where the gaps usually are

Across the connector platforms we look at, the same three things are missing more often than not.

Conditional authorization. Nearly everything ships allow-or-deny. Almost nothing ships "allow, but not above this amount without a human." If your use case involves money, deletion or outbound communication, this is the gap to close first, and human-in-the-loop approval is the shape of the fix.

A log written by the executing layer. Common to find a dashboard of attempted tool calls inside a vendor's product. Rarer to find a record that includes the policy decision and survives in your own systems.

Exactly-once writes. Widely assumed, rarely documented.

None of that means do not connect the assistant. It means connect it with a list of what it may do, a gate on the operations that matter, and a record you own. The architectural shape of that is in what is an execution layer and the credential half is in credential brokering for AI agents.

FAQ

Is it safe to connect an AI assistant to company email?

It depends almost entirely on what else that assistant can do. Reading email is low risk on its own. Reading email while also holding a connector that can send, pay or delete is a different proposition, because email is attacker-controlled content and can carry instructions aimed at the assistant. Narrow what the assistant can do before you worry about what it can read.

What is the biggest risk when connecting AI to company data?

The assumption that read access is passive. Content an assistant reads can contain instructions, so a read connector combined with any action-capable connector becomes a path to action. Published research has demonstrated this against mainstream assistants through both email and calendar invites. Limit the actions, gate the destructive ones, and log what was attempted.

What permissions should an AI assistant have?

The narrowest set that makes the use case work, granted to the least privileged account that can do it, enumerated as a finite list of operations rather than a category like "access to Slack." Widening a scope later is a small change; narrowing one after people depend on it rarely happens.

How do I audit what an AI assistant did?

From a log written by whatever sent the requests, not by the assistant describing its own actions. You need the operation as a stable identifier, who it acted for, the policy decision with the rule version, the status, and whether the response validated. Make sure denied and held calls are in the same place as successful ones.

Do we need approval workflows for AI agents?

If the agent can move money, delete data or send outbound communication, yes. The useful form is conditional rather than blanket: allowed below a threshold, held for a human above it, with a timeout so held requests do not disappear silently. Blanket approval on everything gets switched off within a fortnight.

What should never be given to an AI assistant?

Long-lived credentials it can read, administrator-level scopes when a narrower account would do, and unreviewed write access to anything irreversible. Credentials in particular should be injected at call time by something the model cannot read, rather than placed in an environment variable or a prompt.

How often should connectors be reviewed?

Quarterly is a reasonable default, with a named owner per connection. The thing that changes without you is scope: providers extend what an existing connection can do, so a permission approved months ago can quietly mean more today.

A note on sourcing: the two incidents referenced in check three are publicly documented security research, named here so you can look them up directly. We have kept outbound links on this page to our own documentation.