April 21, 2026
Due Diligence
5 Signs Your AI Vendor's Security Claims Are Marketing, Not Engineering
Security marketing is easy. Every vendor has "enterprise-grade security." Fewer can tell you their encryption algorithm without pausing to check. Here's how to tell the difference — before you hand over access to your infrastructure.
There's a script most AI vendors run when security comes up. It starts with "enterprise-grade," references a SOC 2 badge, reassures you that data is "encrypted in transit and at rest," and ends with an offer to loop in their security team. That security team will then produce a version of the same script with more footnotes.
None of this is lying, exactly. But almost none of it is engineering. It's the appearance of rigor — claims built for procurement checklists, not for the CTO who actually needs to understand the data flow.
The good news: engineering leaves evidence. You don't need a law degree or a background in security to spot the difference between a vendor who has thought hard about where your data goes and one who has thought hard about how to answer that question without answering it.
Here are five tells.
Sign 01 / 05
They say "enterprise-grade security" but can't name their encryption
"Enterprise-grade" is the most useful phrase in security marketing because it communicates confidence while committing to nothing. Ask a follow-up: What encryption do you use at rest and in transit? A vendor who has engineered their security knows the answer instantly — AES-256-GCM at rest, TLS 1.3 in transit, key management via AWS KMS or equivalent. A vendor running marketing knows the phrase "enterprise-grade." The gap between those two answers is the gap between architecture and aspiration.
✗ Marketing
"We use enterprise-grade encryption across all data — both in transit and at rest. Security is our top priority."
✓ Engineering
"AES-256-GCM at rest, TLS 1.3 in transit. Keys managed per-tenant via AWS KMS. Happy to share our crypto spec doc."
Sign 02 / 05
They mention SOC 2 but won't share the actual report
SOC 2 Type II certification is meaningful. The report behind it — the actual auditor findings, control descriptions, and any exceptions noted — is where the substance lives. Vendors who passed a clean SOC 2 share the report readily. They're proud of it. Vendors who have certification but hesitate to share the report are managing what you see. Either they have exceptions they don't want you to read, or the scope of the audit is narrower than you'd expect. Both are things you should know before signing.
✗ Marketing
"We're SOC 2 Type II certified. The report is available to enterprise customers under NDA after contract execution."
✓ Engineering
"Here's our most recent SOC 2 Type II report. Clean opinion, no exceptions. We also do annual pen tests — let me know if you want those results too."
The NDA trap: Requiring an NDA before sharing a SOC 2 report is a delay tactic dressed as a formality. Legitimate vendors don't need you to sign a contract to tell you how they handle your data. If you have to commit before you can evaluate, the evaluation is designed to fail.
Sign 03 / 05
They say "your data is safe" but their architecture requires data to leave your environment
"Your data is safe" is not an architecture. It's a sentiment. The real question is: where does my data go when I use your product? Most AI tools require your data to travel to their servers for processing — cloud configurations, access logs, API call records — because that's where their compute runs. They can apply excellent controls to that data and still be the wrong choice for enterprises with data residency requirements, HIPAA obligations, or customers who ask "where does your data go?" on security questionnaires. "Safe on our servers" and "never leaves your environment" are not the same claim, and only one of them answers the compliance question.
✗ Marketing
"Your data is processed securely on our SOC 2-certified infrastructure. We never store raw data beyond the processing window."
✓ Engineering
"Our agents deploy into your cloud account. Processing runs on your compute. Raw data never reaches us — only operational telemetry does."
Sign 04 / 05
They say "we never train on your data" but their ToS says otherwise
This one is worth reading the fine print for. The verbal commitment and the legal document often do not match. A vendor can genuinely believe they don't train on your data while their Terms of Service include a license to use "aggregated, de-identified data" for model improvement — which, depending on the data and the de-identification method, may include patterns derived from your environment. More commonly, the vendor doesn't train on your data, but they send it to OpenAI, Anthropic, or another AI provider whose enterprise terms allow for some form of retention or analysis. "We don't train on your data" needs to extend to every system your data touches.
✗ Marketing
"We never use customer data to train our models." (ToS, section 4.2: "We may use aggregated usage data to improve our services.")
✓ Engineering
"We don't receive your raw data, so the question doesn't apply. Our ToS matches our architecture — there's nothing to train on."
Sign 05 / 05
They say "we support BYOC" but mean "we'll install in your VPC and phone home"
Bring Your Own Cloud has become a selling point, which means it has also become a thing that gets claimed without full delivery. True BYOC means the vendor's software runs in your cloud, on your compute, and your data never leaves your account. What some vendors call BYOC is closer to a VPC-peering deployment: they install agents in your network, but those agents maintain persistent connections back to the vendor's control plane, sending data for processing or logging on the vendor's side. You're still on their servers — just via a different route. Ask directly: Does any of my data leave my cloud account during normal operation?
✗ Marketing
"Our BYOC deployment option installs agents in your VPC for secure, low-latency access to your infrastructure."
✓ Engineering
"Agents run entirely in your cloud. No data leaves your account. We receive run status and completion signals — nothing raw. You can audit exactly what our agents emit."
How to Run This Yourself
You don't need a security team to do this evaluation. You need five questions and the patience to push back on non-answers.
- Encryption: "What specific encryption do you use at rest and in transit? Who manages the keys?"
- SOC 2: "Can you share your most recent Type II report now, without an NDA?"
- Data location: "Where exactly is my data processed — your servers or mine?"
- Training: "Does your ToS permit any use of customer data — raw or derived — for model improvement? Does that extend to your AI providers?"
- BYOC: "During normal operation, does any of my data leave my cloud account? What exactly do your agents send back to you?"
A vendor who answers all five with specifics — encryption algorithms, data flow diagrams, direct ToS citations — has built security in. A vendor who deflects, pivots to certifications, or asks to schedule a call to "walk you through our security posture" has not.
The five signs above aren't exotic attack vectors. They're the gap between what's said in a sales meeting and what's true in a production environment. Engineering closes that gap. Marketing lives in it.
Foundri Passes Its Own Test
We wrote this list because we pass it. Foundri deploys compliance automation agents directly into your AWS, GCP, or Azure account. Raw data never reaches us. Our encryption spec is documented and shareable before you sign anything. Our SOC 2 report is available on request, no contract required. Our ToS cannot grant us training rights on data we never receive.
The cleanest security architecture is one where the questions above simply don't apply — because the data never moved.
BYOC Compliance Automation
Foundri passes all five signs.
Compliance agents that run in your cloud. Your data never leaves your environment. No SOC 2 exceptions. No ToS workarounds. No phone-home BYOC theater.
Describe your workflow →