Fortanix’s 2025 GenAI Data Security Report: Breach Risks Are Spiking

If nearly every enterprise is racing to deploy GenAI, why are so many still getting breached? Fortanix’s 2025 GenAI Data Security Report, covered by Solutions Review, lands a jarring contrast: 97 percent of organizations plan to buy or build GenAI to automate work and drive revenue, yet 87 percent of security executives say their orgs were breached in the past year. That tension—unstoppable AI momentum colliding with escalating cyber risk—defines the moment we’re in.

The report’s core warning is clear: GenAI magnifies the blast radius of data exposure. As models ingest, transform, and infer across multi-cloud and hybrid environments, the traditional perimeter dissolves. Unauthorized access, data exfiltration, and compliance violations (think GDPR) become easier to trigger and harder to detect. Fortanix argues the only sustainable answer is to protect data everywhere—at rest, in transit, and crucially, in use—through confidential computing and zero-trust architectures. And if orgs don’t enforce encryption policies, tailor EDR/XDR to AI workloads, and pen test AI pipelines, AI-related incidents could double.

If you’re a CISO, head of data, or product leader trying to move fast without breaking trust, this post unpacks the implications, adds practical steps, and links to guidance you can act on now.

Source: Solutions Review coverage of the report
Link: AI news for the week of Feb. 21, 2025 (Solutions Review)

The headline numbers—and why they matter

According to Solutions Review’s summary of Fortanix’s 2025 GenAI Data Security Report: – 97% of surveyed organizations plan to buy or build GenAI solutions for automation and revenue. – 87% of security executives reported a breach in the last 12 months. – The report stresses a need to secure data across environments, applications, and geographies as AI accelerates. – It highlights amplified risks: unauthorized access, data exfiltration, and GDPR-aligned compliance failures. – Fortanix advocates confidential computing and zero trust to encrypt data in use—reducing model training/inference exposure. – With ransomware and deepfakes growing more sophisticated, integrated EDR and XDR tailored for GenAI are needed. – Visibility gaps in multi-cloud and hybrid deployments are a key contributor to vulnerability. – Absent proactive measures (policy-driven encryption, pen testing), AI-related incidents could double. – The call to action: embed security-by-design across the AI pipeline to protect IP and customer data while enabling innovation.

Taken together, these insights frame a strategic imperative: if your AI program doesn’t treat data-in-use as a first-class security domain, you’re likely overexposed.

Why GenAI changes the data risk equation

GenAI isn’t “just another app.” It’s a data super-consumer and super-producer:

It concentrates high-value data. Training and retrieval-augmented generation (RAG) pipelines centralize sensitive IP, PII, PHI, and proprietary documents.
It increases surface area. Feature stores, vector databases, model registries, prompt orchestration layers, and inference endpoints multiply entry points.
It blurs boundaries. Data moves across clouds, SaaS tools, and regions; enforcing consistent controls is hard.
It’s attractive to adversaries. From data poisoning and prompt injection to access token theft and model theft, attackers see more ways in.
It can leak unintentionally. Model outputs can regurgitate memorized snippets or expose secrets embedded in prompts, logs, or context windows.
It complicates incident response. Traditional logs may not capture prompts, context, or sensitive snippets processed during inference—making root cause analysis tricky.

In short: GenAI accelerates value creation but also centralizes risk. Security has to evolve from guarding doors to protecting the data itself—everywhere it gets processed.

The compliance squeeze: GDPR and beyond

GenAI heightens classic compliance challenges: – Data minimization vs. model performance. How do you limit personal data while maintaining accuracy? – Lawful basis and purpose limitation. Do your training and inference uses align with user consent and stated purposes? – Cross-border transfers and data residency. Are model training jobs leaking EU data to non-compliant regions? – Right to access, rectify, or erase. Can you trace and act on subject rights across training and vector stores? – Auditability. Can you prove when, where, and under what controls data was used for AI?

Start with policy clarity, then back it up with technical guarantees. For reference: – GDPR primer: European Commission overview – AI risk frameworks you can align to: NIST AI Risk Management Framework and ISO/IEC 42001 (AI management system)

Confidential computing and encryption-in-use: the missing pillar

Encrypting data at rest and in transit is standard. The gap is data in use—when plaintext exists in memory during training or inference. Confidential computing closes that gap by running sensitive workloads inside hardware-backed Trusted Execution Environments (TEEs) that: – Encrypt memory at the hardware level. – Isolate code/data from other processes, the hypervisor, and even cloud operators. – Provide remote attestation so you can verify the code and environment before releasing keys.

Useful resources: – Overview: Confidential Computing Consortium – Cloud capabilities: AWS Nitro Enclaves, Azure Confidential Computing, Google Cloud Confidential VMs

Fortanix’s position, as summarized by Solutions Review, is that encrypting data in use is non-negotiable for GenAI, particularly during model training and inference where secrets, IP, and regulated data are most exposed.

Encrypting model training and inference end-to-end

A practical design for encryption-in-use usually includes: – TEEs for training clusters and inference endpoints. – Remote attestation gating—keys are released only if the workload is verified to be running approved code in an approved enclave configuration. – Segregated compute pools: confidential for sensitive datasets; standard for public/low-risk data. – Inference pathways that keep prompts, context, and outputs encrypted in memory, and redact/partition logs. – Integration with HSM-backed KMS for strict key control and cryptographic attestation.

Key management and policy enforcement

Great encryption is useless if keys sprawl: – Use centralized, HSM-backed key management with strong separation of duties. – Enforce bring-your-own-key/control (BYOK/BYOKMS) in SaaS and cloud AI services where possible. – Implement crypto-agility (support for post-quantum-ready transition plans) and routine rotation. – Enforce policy-as-code for data classification, residency, and key usage—violations should hard-fail. – Monitor and block shadow keys or unmanaged secrets in AI pipelines.

Zero trust for AI: never trust, always verify, least privilege

Zero trust isn’t a product; it’s an operating model that fits AI perfectly: – Verify explicitly: Strong identity for humans, services, and workloads (including non-human identities and service accounts). – Use least privilege: Scope datasets, model registries, and feature stores with granular RBAC/ABAC. – Assume breach: Segment every AI stage so compromise in one does not spill to others. – Inspect continuously: Validate requests, context length, and allowed data classes at runtime.

Start with guiding references: – NIST SP 800-207 (Zero Trust Architecture)

A reference architecture for zero-trust AI pipelines

Map your pipeline and insert explicit control points: – Data sources and ingestion: DLP, tokenization, PII detection, row-level access controls. – Feature store / vector DB: Namespace isolation, fine-grained ACLs, encryption-in-use, auditable fetch policies. – Training: Enclave-protected nodes, attestation-gated keys, approved images only, signed data manifests. – Model registry: Signed artifacts, version controls, attested promotion gates. – Deployment: Runtime policy enforcement (e.g., allowed connectors), rate limits, content filters, and output watermarking where applicable. – Observability: Prompt and context telemetry with redaction, model behavior monitoring, and privacy-preserving logs.

EDR/XDR tuned for GenAI workloads

Traditional EDR/XDR won’t automatically see inside AI pipelines: – You need telemetry from enclaved workloads (within limits) and adjacent layers—storage, orchestration, service mesh, and identity systems. – Watch for AI-specific TTPs: data poisoning patterns, anomalous vector store queries, prompt injection attempts, model parameter exfil, or token abuse. – Fuse data loss prevention (DLP) with model observability: detect sensitive strings emerging from outputs or context. – Integrate detections with incident response runbooks designed for AI artifacts (prompts, embeddings, registries).

Helpful references: – XDR concept overview: What is XDR? (Microsoft) – Adversarial techniques library: MITRE ATLAS

Closing the multi-cloud and hybrid visibility gap

GenAI thrives in heterogeneous environments. Security teams need shared truth across: – Cloud providers (AWS/Azure/GCP), on-prem clusters, and edge. – Managed AI services and homegrown components. – Data platforms (data lakes, warehouses, vector stores, feature stores). – Identity providers and service accounts.

Key moves: – Unified inventory of AI assets: models, datasets, embeddings, secrets, registries, endpoints. – CNAPP/CSPM to enforce guardrails and detect misconfigurations. – Central data catalogs with classifications propagated to pipelines. – Standardized logging schema for prompts, context usage, and model versions (with redaction and access governance).

A pragmatic 90-day roadmap to de-risk your GenAI program

You can make measurable progress fast by sequencing the right wins.

Phase 1: Assess and prioritize (Weeks 1–3) – Inventory AI assets: models (internal and third-party), datasets, vector DBs, pipelines, SaaS AI tools. – Classify data risk: map PII/PHI/IP and regulatory obligations (GDPR/CCPA/HIPAA/etc.). – Threat model top three AI use cases: data flows, trust boundaries, attack paths, business impact. – Policy baseline: define data-in-use encryption requirements, BYOKMS expectations, data residency restrictions, and logging redaction standards.

Phase 2: Harden the pipeline (Weeks 4–8) – Implement confidential computing for sensitive training/inference paths; add attestation-gated key release. – Enforce zero-trust access: IAM clean-up, least-privilege scoping for datasets and model artifacts, service account segregation. – Lock down vector stores: namespace isolation, query policy, and encryption-in-use for embeddings. – Update CI/CD for models: signed containers/artifacts, allowlisted base images, SBOMs for AI components. – Instrument observability: redact prompts; collect context metadata; baseline normal access patterns for detection. – Update vendor contracts: require no-retention options, data isolation, BYOK support, model isolation, and transparent privacy terms.

Phase 3: Test and monitor (Weeks 9–12) – Run AI red-teaming and penetration tests focused on prompt injection, data leakage, and poisoning. – Stand up EDR/XDR use cases for AI: anomaly detection around vector DBs, registries, and inference APIs. – Drill incident response: rehearse AI-specific runbooks; validate you can revoke keys, rotate secrets, and quarantine endpoints quickly. – Define and report KPIs to leadership: coverage of encryption-in-use, attestation pass rates, and mean time to detect/respond for AI incidents.

Build vs. buy: secure choices at every layer

Whether you’re buying a SaaS copilot or building a bespoke RAG system, ask: – Data handling and retention: Is your data used for training? Is there a “no-train, no-retain” option? – Isolation: Are tenants and models isolated? Can you attest to runtime environments? – Keys and residency: Does the provider support BYOK/BYOKMS, HSM-backed keys, and regional key custody? – Telemetry: Do you get redaction-aware logs, model/version IDs, and inference audit trails? – Security certifications: SOC 2, ISO 27001, and alignment to AI risk frameworks (e.g., NIST AI RMF). – Egress controls: Can you limit outbound calls from the model to approved connectors? – Supply chain: Are models, weights, and datasets signed with verifiable provenance?

Metrics your board will actually understand

Translate “AI security” into crisp, decision-grade metrics: – Percentage of sensitive AI workloads protected by encryption-in-use. – Remote attestation coverage rate and failure/block counts. – AI data inventory completeness (% of models/datasets/cataloged). – Mean time to detect/respond (MTTD/MTTR) for AI-related incidents. – Policy enforcement rate (blocked vs. permitted access attempts to sensitive data via AI). – Vendor compliance coverage (BYOK, no-train policies) across critical AI services. – Red-team findings remediation velocity (days to fix critical AI issues).

Common pitfalls to avoid

Shadow AI and rogue datasets. Unvetted copilots or “temporary” data copies become permanent liabilities.
Over-relying on masking. Pseudonymization won’t stop reidentification or leakage during inference.
Incomplete lineage. If you can’t trace which data shaped which model version, you can’t answer regulators—or customers.
Ignoring data-in-use. Encryption at rest and transit is necessary but insufficient for GenAI.
One-size-fits-all logging. Collecting raw prompts is risky; collect what you need with redaction and access governance.
Skipping AI-focused incident response. Treat prompts, context stores, embeddings, and model endpoints as first-class IR objects.
No continuous testing. AI red teaming should be a recurring practice, not a one-off.

What Fortanix brings to the table

Per Solutions Review’s coverage, Fortanix positions its confidential computing and data-in-use encryption capabilities as essential for GenAI security. The emphasis is on: – Protecting sensitive data during model training and inference with encryption-in-use. – Enforcing encryption policies centrally across clouds and environments. – Leveraging zero-trust controls and attestation to block unauthorized access. – Integrations that support EDR/XDR visibility for AI workloads.

If you’re evaluating technology options in this space, review confidential computing offerings from your cloud providers and independent vendors. For background on Fortanix’s approach, see:
Fortanix (company site)

The bottom line: innovate without compromise

GenAI is moving too fast for bolt-on security. The organizations that win will embed protection where it matters most: around the data, throughout the pipeline, and at runtime in the compute itself. Fortanix’s 2025 report, as summarized by Solutions Review, is a timely reminder that we can’t “wait and see.” Encrypt in use, verify everything, monitor continuously, and pressure-test your AI stack like your business depends on it—because it does.

Frequently Asked Questions

Q1) What is “encryption-in-use,” and why does GenAI need it?
Encryption-in-use protects data while it’s being processed—inside memory and CPU—using confidential computing (TEEs). GenAI pipelines often handle highly sensitive prompts, embeddings, and training data. Without encryption-in-use, that data can be exposed to insiders, malware, or compromised infrastructure during training or inference.

Q2) Won’t confidential computing slow down model training and inference?
There can be overhead, depending on hardware, workload, and implementation. For many inference use cases, overhead is manageable, and performance-optimized TEEs keep improving. For training, you can segment: keep highly sensitive stages/data in TEEs and use standard compute for low-risk tasks. Always benchmark your workload before broad rollout.

Q3) How does zero trust apply to LLMs and RAG systems?
Treat every hop as untrusted: authenticate and authorize each service, dataset, and call. Enforce least privilege at the vector store, model registry, and inference API. Validate inputs (prompts and retrieved context) and outputs (content filtering, watermark checks) at runtime. Segment environments so compromise in one stage doesn’t spread.

Q4) Can zero trust stop prompt injection?
Not entirely, but it helps contain damage. Combine zero trust with robust input validation, retrieval whitelisting, content filters, and response policies. Test against common prompt-injection patterns during red teaming and restrict the model’s available tools/connectors to minimize impact if a prompt bypasses guardrails.

Q5) Are synthetic or anonymized datasets a silver bullet for privacy?
No. Synthetic or anonymized data can reduce exposure but may still leak patterns or enable reidentification, especially when combined with other data. Apply privacy risk assessments, limit linkage, and still protect data-in-use during processing.

Q6) How should we secure a third-party GenAI copilot?
Require no-train/no-retain options, BYOK/BYOKMS support, tenant/model isolation, regional data processing, and export controls. Verify audit logs (with redaction), define allowed connectors, and restrict egress. Conduct a DPIA if personal data is involved and test for data leakage with red teaming.

Q7) What does “XDR for GenAI” actually mean?
It means your detection stack must see signals from AI-specific components—vector DBs, model registries, inference APIs—and correlate them with identity, endpoint, and network telemetry. You’re looking for anomalies in AI data access and behavior (e.g., unusual embedding queries, atypical prompt patterns, or rapid data pulls).

Q8) How often should we red-team our AI systems?
Embed AI red teaming into your release cadence—at minimum before major launches or model/retrieval changes, plus periodic (quarterly) exercises. Focus on prompt injection, data exfiltration, poisoning, and output safety—then track and close findings quickly.

Q9) Does GDPR apply differently to AI?
GDPR applies to personal data processing regardless of whether AI is used. GenAI complicates compliance due to scale, cross-border processing, and explainability. Ensure lawful basis, purpose limitation, data minimization, subject rights fulfillment, and documented controls—backed by technical guarantees like encryption-in-use and strong key custody.

Clear takeaway

AI’s upside is undeniable, but so is the risk of doing it wrong. The fastest path to safe, scalable GenAI is to protect data throughout its lifecycle—especially in use—while enforcing zero-trust principles and tuning detection for AI realities. Use the next 90 days to inventory your AI assets, encrypt sensitive workloads in TEEs, lock down access, and pressure-test your pipeline. You’ll ship faster, sleep better, and build AI your customers can trust.

Discover more at InnoVirtuoso.com

I would love some feedback on my writing so if you have any, please don’t hesitate to leave a comment around here or in any platforms that is convenient for you.

For more on tech and other topics, explore InnoVirtuoso.com anytime. Subscribe to my newsletter and join our growing community—we’ll create something magical together. I promise, it’ll never be boring!

Stay updated with the latest news—subscribe to our newsletter today!

Thank you all—wishing you an amazing day ahead!

The Psychology of Cyber Defense: Burnout, Attacker vs. Defender Mindsets, and the Human Factors Behind Every Breach

Unveiling Google Gemini 2.0: The Next Generation of AI Technology

Fake VPNs and Spam Blocker Apps: How VexTrio’s Ad Fraud and Subscription Scams Are Tricking Millions

Cultivating a Hacker Mindset in Cybersecurity Defense

First Line of Defense: Cybersecurity Training for Customer Support Teams

The End of an Era? The Takedown of BreachForums and the ShinyHunters Cybercrime Empire