## Key Takeaways

- **Due diligence on an AI employee is different from a normal SaaS review.** The software does not just store your data. It holds credentials to your other tools and takes actions with them, so the review has to cover what it can do, not only what it can see.
- **Ask for documents first: a SOC 2 report, a DPA, and a written answer on model training.** A vendor that has been through an audit can produce these quickly. A vendor that stalls on paperwork will stall on everything else.
- **Know the difference between SOC 2 Type I and Type II.** Type I attests that controls are designed correctly at a point in time. Type II attests they operated over a period. Many young vendors hold Type I with Type II in progress; that is a normal stage, not a red flag, as long as they say it plainly.
- **The strongest questions are architectural, not contractual.** Where do credentials live, and can the model read them? What actions require human approval? Is workspace isolation a technical boundary or a policy promise? Certificates do not answer these; the architecture does.
- **Offboarding is part of the review.** Before you connect anything, confirm you can disconnect any integration, pause any user, and stop any running task on your own, without a support ticket.

## The review that stalls the rollout

The team has picked an AI employee, run a trial in one channel, and everyone wants to keep it. Then someone loops in whoever owns security, and the rollout stops moving. Not because anyone found a problem, but because nobody knows what a proper review of this kind of tool even looks like. The standard vendor questionnaire asks about data storage and encryption, which covers maybe half of what matters here.

This post is the other half: what to request, what to ask, and what a strong answer sounds like, written for the operator who has to get the review done rather than for a security team of twelve. We answer these questions about Viktor along the way, so you can also read it as our own due diligence file.

## Why is an AI employee different from normal SaaS?

A normal SaaS review asks: what data does this vendor store, and how well do they protect it? That still applies. But an AI employee also holds live credentials to your CRM, your ad accounts, your email, and it acts with them. The blast radius of a mistake is not "our data leaked", it is "something sent an email or changed a record".

So the review needs two extra lenses:

- **Credential handling.** The vendor's AI model is the new, untrusted component in the stack. The question is whether your API keys and OAuth tokens are ever visible to it, or whether they are injected by infrastructure the model cannot read.
- **Action control.** What stops the AI from doing something consequential without a human looking first? The honest answers range from "nothing" to "a technical approval gate on sensitive actions". You want to know where on that range your vendor sits.

The [security checklist for AI tool access](https://viktor.com/blog/security-checklist-for-ai-tool-access) covers how to scope what an AI employee can reach inside your workspace. This post is about vetting the vendor itself.

## Which documents should you request?

Request a SOC 2 report, a data processing agreement, a written statement on model training, and the vendor's public security overview. That set covers attestation, legal basis, the AI-specific risk, and a quick sanity check, in that order.

### The core document set

- **SOC 2 report.** An independent auditor's attestation of security controls. Expect to sign an NDA to receive it; that is standard. Viktor holds SOC 2 Type I, with the Type II audit in progress, and the report is available under NDA.
- **Data processing agreement (DPA).** The legal document that makes the vendor your data processor under GDPR. If you have EU users or customers, this is not optional.
- **Model training statement.** Get it in writing: does any of your data train their models or their providers' models? For Viktor the answer is no. Conversations and files never enter a training set, not ours and not our model providers'.
- **Public security overview.** A serious vendor documents their posture publicly. Ours is at [viktor.com/security](https://viktor.com/security), and it covers encryption, SSO, data residency, and compliance status.

### Reading compliance status honestly

A vendor's compliance page usually mixes finished audits with work in progress. That is fine; what matters is that the two are labeled. As of mid-2026, Viktor's status is: SOC 2 Type I certified, SOC 2 Type II in progress, GDPR aligned with a DPA available, CCPA compliant, CASA Tier 3 certified (the highest assessment tier required for Google API access), and ISO 27001 in progress. A vendor who presents in-progress work as finished certification is telling you something about how they will handle incident disclosure too.

## What questions separate strong vendors from weak ones?

Documents prove the vendor did the work once. Questions prove the design is sound. These five, with what weak and strong answers sound like:

| Question | Weak answer | Strong answer |
| --- | --- | --- |
| Can the AI model read our API keys and tokens? | "Credentials are stored securely." | "A tool gateway injects credentials at execution time. The model never sees them. It is architecture, not policy." |
| What happens before a consequential action, like sending an email or changing a record? | "The agent is very reliable." | "Sensitive actions wait for explicit human approval in chat. Money moves, code pushes, and customer emails do not go out on their own." |
| Is our workspace isolated from other customers? | "We take isolation seriously." | "Skills, integrations, and memory are walled off per workspace. There is no cross-tenant access." |
| How do we revoke access, today, ourselves? | "Contact support and we will remove it." | "Admins disconnect any integration, pause any user, or stop a running task in one click." |
| Does our data train your models? | "We may use data to improve our services." | "No. Not our models, not our model providers' models. In writing." |

The right column is how Viktor is built, and each of those answers is verifiable on the [security page](https://viktor.com/security) rather than something a salesperson says on a call.

### The encryption and SSO basics

Do not skip the boring rows. Data should be encrypted with TLS 1.2+ in transit and AES-256 at rest, secrets should live in dedicated vaults, and the vendor should support SAML SSO with your identity provider. Viktor supports SSO across Okta, Entra ID, Google Workspace, OneLogin, and any SAML 2.0 IdP on Enterprise contracts. If your company has residency requirements, ask where data is hosted; Viktor is US-hosted by default with EU data residency available on Enterprise contracts.

## How do you verify claims instead of trusting them?

Run a small live test in a scoped channel before you sign anything. An AI employee that works in your chat tool can demonstrate its own boundaries in front of you, which no PDF can.

Three checks worth running during a trial:

1. **The access check.** Ask it what it can currently reach. A well-built AI employee will give you a straight inventory.

```prompt
@Viktor list every integration you currently hold credentials for in this workspace, and who connected each one.
```

2. **The boundary check.** Ask it about a channel it is not a member of. The correct behavior is a clean refusal: membership is the boundary, and [controlling where your AI employee works](https://viktor.com/blog/how-to-control-where-your-ai-employee-works) should be as simple as inviting or removing it from a channel.

3. **The approval check.** Give it a task that ends in a consequential action, like drafting an email to a real address, and confirm it stops for sign-off instead of sending. How that gate works day to day is covered in [keeping a human in the loop](https://viktor.com/blog/how-to-keep-a-human-in-the-loop-with-your-ai-employee).

If all three behave in front of your security reviewer, the review meeting gets dramatically shorter.

## What does offboarding look like?

Every review should end with the exit question, because the day you need it is the worst day to discover the answer. Confirm three things: you can disconnect any single integration without touching the rest, you can pause or remove individual users, and you can stop a running task mid-flight. All three should be self-serve, immediate, and not require a support conversation.

This is also your incident playbook in miniature. If a token is compromised or a teammate leaves, the fix is the same one-click revocation you tested on day one.

## Frequently Asked Questions

### What is the difference between SOC 2 Type I and Type II?

Type I attests that a vendor's security controls are properly designed at a point in time. Type II attests that those controls actually operated effectively over an observation period of several months. Type II is the stronger attestation, and most vendors get Type I first while the Type II observation window runs. Viktor holds SOC 2 Type I with Type II in progress.

### Does Viktor train AI models on our data?

No. Your conversations and files never enter a training set, neither Viktor's nor those of the model providers Viktor runs on. This is stated publicly on the security page and can be put in writing during your review.

### Can the AI model see our passwords and API keys?

No. Credentials are injected at execution time by a backend tool gateway, and the model itself never sees them. This is an architectural boundary rather than a policy, which is exactly the distinction your security reviewer should push every vendor on.

### Is Viktor's Slack app reviewed by Slack?

Yes. Viktor is published in the official Slack App Directory, which means the OAuth scopes and security posture were reviewed and approved by Slack before the app could be distributed through their store.

### What if our company requires EU data residency?

Viktor is US-hosted by default, and EU data residency is available on Enterprise contracts. If residency is a hard requirement, raise it early in the conversation so the right setup is scoped from the start.

### How long should security due diligence on an AI employee take?

With a cooperative vendor, the document exchange takes days, not weeks: NDA, SOC 2 report, DPA, and written answers to the architectural questions above. The live trial checks take under an hour. If a vendor cannot move at that pace on paperwork, treat it as signal.

---

**Viktor is an AI employee that lives in Slack, connects to 3,200+ integrations, and does real work for your team.** [Add Viktor to your workspace -- free to start →](https://viktor.com/?utm_source=blog&utm_medium=cta&utm_campaign=how-to-run-security-due-diligence-on-an-ai-employee)