AI writing tool security review: the SOC 2 and SSO checklist

Legal and IT don't read your product page before a deal closes. They run a structured review against four areas: where your data goes, which model touches it, who can access the system, and what record exists after the fact. Over 70% of enterprise buyers now require a SOC 2 report from technology vendors as part of that process, according to SOC 2 compliance data compiled for 2026, and an AI writing tool that touches your CMS, your brand voice, and your published content gets the same scrutiny as anything else with write access to your systems.

This is the procurement-stage post, not the feature-comparison one. If you're still weighing which AI blog writer fits your workflow, our buyer's checklist covers that earlier decision. This picks up once a tool has cleared that bar and legal wants a straight answer on data, model, access, and audit before anyone signs.

The four areas every AI vendor security review checks: data, model, access, audit

Every enterprise security review, regardless of the tool, collapses into the same four questions: where does our data live, what touches it, who can reach the system, and can we prove what happened. An AI writing tool answers all four differently than a normal SaaS app, because it also reads your content, drafts with a language model, and often needs write access to a repo or CMS.

Data: where it's stored, whether it trains the model, and who else touches it

A reviewer wants three things on data: a named storage region, a direct answer on whether your content trains anyone's model, and a list of every third party that touches it. "We take security seriously" is not an answer to any of those; a region name, a policy citation, and a sub-processor list are.

The training question is the one founders most often answer vaguely, and it's the one legal cares about most. If a writing tool holds its own shared API key across every customer, your drafts are one policy change away from becoming training data for a model your competitors also use. A bring-your-own-key architecture sidesteps that structurally: your Anthropic account holds the data relationship, not the vendor's infrastructure, which is the argument our piece on BYOK versus a SaaS markup makes from the cost side of the same decision.

Model: which model, whose keys, and what happens when it's uncertain

Which model, and whose account it runs under, decides who a customer's data-processing agreement is actually with. A vendor that won't name the underlying model, or that routes every customer through its own shared key, is asking you to trust an extra layer of custody you can't audit directly.

The second part of this question rarely comes up in a features demo, but it comes up in a security review: what does the tool do when it isn't sure a claim is true. A model that guesses and ships a plausible-sounding but unverifiable number is a different risk profile than one that flags the claim and blocks it. This is exactly the gap a dedicated fact-checking pass exists to close, and a reviewer asking "how do you handle hallucination" is really asking whether that gap has a process behind it or just a hope.

Access: least privilege, SSO/MFA, and tenant isolation

Access control is the area IT actually tests, not just reads about. They want the tool scoped to the minimum permission it needs, identity federated through your existing provider, and your account's data kept separate from every other customer's.

For a tool connected to GitHub specifically, this is a concrete, checkable list: Contents and Pull requests, nothing broader. GitHub's own guidance states it plainly: "You should select the minimum permissions required for the app." We cover the full permission-by-permission breakdown, including the red flags (Administration, Workflows, Secrets access with no reason tied to writing a post) in our GitHub App permissions guide, which is the access half of this review in more depth than a single section here can cover.

Audit: exportable logs and a real approval record, not a vendor's word for it

The audit question a reviewer actually asks is narrower than "do you log things": can you export a record that names who drafted, who reviewed, and who approved, with timestamps, independent of the vendor's own dashboard. A screenshot of an internal admin panel doesn't satisfy this. A record you can pull yourself does.

We cover what that record needs to contain, and the EU AI Act deadline making it non-optional for a growing share of published content, in our post on AI content governance and the audit trail. The short version: a Git pull request already gives you most of this for free, which the next section covers as one of the direct answers to bring into the room.

SSO, SOC 2, and data residency: what to ask before the deal moves forward

Three specific asks show up in nearly every enterprise security review of an AI vendor, and each one has a right shape of answer that a reviewer is trained to recognize. Vague reassurance fails all three; a named report, a named protocol, and a named region pass them.

SOC 2 Type I vs Type II, and why Type II is what procurement actually means

SOC 2 Type I checks whether your controls are designed correctly on a single day. SOC 2 Type II checks whether those same controls actually operated correctly over a sustained window, typically six to twelve months, per an analysis of SOC 2 Type I versus Type II requirements. When procurement asks for "a SOC 2 report," they mean Type II, and a vendor handing over a Type I report is answering a question nobody asked.

The gap between the two matters because of who's actually asking. That same analysis, based on more than 500 RFPs reviewed across 2025 and 2026, found 85% of mid-market buyers (500 to 5,000 employees) require Type II, climbing to 98% for Fortune 500 companies, 99% for financial services, and 95% for government buyers, against 60% for SMB buyers. If your buyer sits anywhere above SMB, Type I buys you almost nothing.

One clarification worth making explicit in the room: the AICPA's Trust Services Criteria underlying every SOC 2 report cover five areas, Security, Availability, Processing Integrity, Confidentiality, and Privacy, but only Security is required in every audit. A vendor's report scope, which of the other four it opted into, tells you what was actually tested. Ask for the scope, not just the logo.

SAML, OIDC, and SCIM: the three acronyms an IT reviewer will actually test

SSO is no longer a nice-to-have line item. 45% of enterprise SaaS purchasing decisions now require SSO as a non-negotiable baseline before a deal can close, according to SSOJet's analysis of enterprise SaaS procurement. An SSOJet spokesperson framed the shift bluntly: "Two years ago, SSO was a nice-to-have. In 2026, it is the line that separates SMB SaaS from real enterprise SaaS."

Three protocols show up in that test, and they answer two different questions. SAML and OIDC handle authentication, proving who someone is at the moment they log in. SCIM handles provisioning, keeping the app's user list synced with your identity provider so someone offboarded in Okta or Entra ID loses access automatically instead of keeping a stale account alive, per WorkOS's breakdown of SCIM versus SAML. A reviewer who only asks about SSO and skips SCIM is missing half the test; most will ask about both, because SAML alone can't reflect an access change made after login.

Data residency and sub-processor disclosure for a tool that touches your content

Data residency asks a specific question: which region does your content and account data actually live in, not "the cloud." Sub-processor disclosure asks a related one: which named third parties, the model provider, the hosting platform, any analytics tool, touch that data along the way, and does the vendor commit to telling you before that list changes. A vendor that can produce both on request, in writing, has done this review before. One that needs a week to find out probably hasn't.

Questions that kill a deal, and how to answer them before they're asked

Three questions come up often enough in these reviews that it's worth pre-answering them in a document you bring into the room, rather than fielding them live and hoping the answer holds up.

"Does this train on our data?" and why a BYOK, PR-based architecture answers it structurally

This is usually the first question, and the honest answer depends on two separate facts: the model vendor's default policy, and whose API key runs the request. Anthropic's own policy states it plainly: "By default, we will not use your inputs or outputs from our commercial products (e.g. Claude for Work, Anthropic API, Claude Gov, etc.) to train our models," per Anthropic's data usage documentation, with the exception requiring an explicit customer opt-in.

That policy is stronger when it applies to an account you control directly rather than a shared pool the vendor manages on your behalf. A bring-your-own-key setup, where your content flows through your own Anthropic account under your own agreement, means the no-training default applies to you specifically, not to an aggregate the vendor could theoretically change terms on. This is the same distinction our BYOK pricing breakdown makes for cost, and it happens to be the cleanest structural answer to the training question a reviewer will ask.

"Who can see our drafts before they publish?" and the access/audit answer that satisfies IT

The honest answer here is usually: the tool's model provider, briefly, to generate the draft, and then only the people your own repo or CMS already grants access to, because nothing publishes without a pull request a human on your team merges. That's not a workaround for the question, it's the actual architecture behind a Git-based AI blog writer: a branch, a diff, and a merge button, the same review flow your engineers already use for code.

It satisfies IT for two reasons at once. Access-wise, the tool never gets a path to your live CMS, only to a branch a human reviews. Audit-wise, that same pull request is the record: commit history names the author, review comments name the reviewer, and the merge event is a timestamped, named approval, which is the exact shape of record our governance piece argues the EU AI Act's Article 50(4) exemption for reviewed content actually expects. One architectural choice answers an access question and an audit question at the same time, which is worth pointing out explicitly when a reviewer asks them separately.

A one-page answer key to bring into the security review, not after it starts

Bring a single page with the four areas above, not a slide deck. Reviewers move faster when the shape of your answer matches the shape of their checklist:

The stakes for getting this page wrong are higher than a missed deal. 97% of organizations that experienced an AI-related security incident said they lacked proper AI access controls at the time, and 63% of breached organizations either had no AI governance policy in place or were still building one, according to IBM's 2025 Cost of a Data Breach report, based on Ponemon Institute research across 600 organizations. A fifth of the breaches studied were linked to shadow AI, tools adopted without IT or security sign-off, adding as much as $670,000 to the average breach cost. A structured answer key isn't just what gets a deal through procurement faster. It's the same discipline that keeps an unreviewed tool from becoming the next line in that statistic.

A security review of an AI writing tool comes down to four checkable answers, and a BYOK, pull-request architecture is built to give you all four without a special enterprise tier: your key, your data policy, scoped repo access, and a Git history as the audit trail.

Try Lyra → · Talk to the founder