AI security for SaaS: protect data and pass security reviews

01Why AI security is different in a product that already works

Most enterprise SaaS teams already have SSO, role-based access, tenant separation, encryption and a SOC 2 report or one on the way. AI adds a component that behaves unlike anything else in the stack.

A traditional service does what its code says. A language model does what its input persuades it to do, and its input now includes user messages, uploaded documents, tickets and records from your database. Any of that text can carry instructions. That single fact changes the threat model more than anything else.

The good news for a mature product is that the controls you need mostly exist already. The work is wiring the model into those controls instead of building around them. We cover the wider pattern in how to add AI agents to an existing SaaS product without rebuilding it.

02The AI security threat model, in plain terms

The OWASP Top 10 for LLM Applications is the most widely used starting list. Its 2025 edition puts prompt injection first and sensitive information disclosure second, and it also names improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses and unbounded consumption. For a B2B SaaS product, those collapse into four threats worth designing against.

Prompt injection deserves special attention because it cannot be patched away. It comes from how language models work: they cannot reliably tell the difference between your instructions and instructions hidden in content. So the defense is architectural. Assume that sooner or later the model will be persuaded to try something it should not. Make sure that when it does, the attempt fails at a permission check rather than succeeding because the model held the keys.

The same logic applies to output. Whatever the model produces is untrusted input to the next system in line: the browser, the database, the email service, the workflow engine. Our supporting piece on LLM security treats model output as untrusted input in depth, and the one on RAG security covers tenant isolation in retrieval, where most real leaks start.

03Data governance: what reaches the model and where it goes

Security reviewers ask three data questions before anything else. What customer data reaches the model? How long is it kept, and by whom? Where is it processed?

Answer the first one by design, not by policy. Send the model only the fields the task needs. Every field you leave out is a field you never have to defend. For development and testing, use synthetic or de-identified data so that real customer records stay in production, under production controls.

Retention is the second question and the one most often answered badly. A model call can leave copies in several places: your prompt logs, your trace store, your vector index, your cache and the model provider's own logs. Map each one, set a retention period for each and make sure deletion actually reaches all of them. Soft delete versus hard delete explains why a record marked deleted in your database can still live on in an embedding index. AI data leakage through search metadata shows how titles and snippets can expose what the content itself protects.

Data location is the third. Enterprise and public sector buyers increasingly want the model to run in a region and an account they can name. Running inference in your own cloud account, on a model you choose, answers that question cleanly and keeps the data inside contracts you already have. We compare the main platforms in AWS Bedrock vs Azure AI vs Vertex AI for existing SaaS. For production work with real customer data, our piece on AI data security with production data sets out the boundaries in detail.

04Permissions: the agent gets the user's permissions, never more

The most important rule in AI security is also the simplest. An AI feature acts on behalf of a user, so it gets that user's permissions and nothing more. No service account with admin rights. No shared key that can read every tenant. No tool that bypasses the checks your application already runs.

OWASP calls the failure mode excessive agency and traces it to three causes: too much functionality, too many permissions and too much autonomy. Its guidance matches what we see work in practice. Execute actions in the user's context with the minimum privileges needed, and require human approval for high-impact actions. Enforce authorization in the downstream system rather than trusting the model to decide what is allowed.

In practice that means a short checklist for every tool an agent can call:

1. 01

   Identity

   the call carries the requesting user's identity and tenant, checked on the server.

2. 02

   Scope

   the tool does one narrow job, with no open-ended query or shell access.

3. 03

   Authorization

   the target system validates the request against its normal policy, every time.

4. 04

   Approval

   anything that writes, sends, deletes or spends money waits for a person to confirm.

5. 05

   Limits

   rate limits and spending caps stop a runaway loop before it becomes an incident.

Capability should rise only as control rises with it. Our CTO describes this as a ladder from reading to executing in why AI agents fail in production. The supporting article on AI agent security and permissions goes further into scoping tools for multi-step agents.

05Auditability: prove what the AI did and why

When something goes wrong, or when an auditor asks, you need to reconstruct a run. You need to know who asked, what context the model saw, which tools it called, what each call returned, what the model answered and who approved the action. If you cannot answer those questions from your logs, you do not yet have an auditable AI feature.

A good AI audit trail records the user and tenant, the prompt and model version, the retrieved sources, every tool call with its parameters and result, the final output, any human approval and the time of each step. It is append-only, it follows the same retention and access rules as your other audit logs, and it never becomes a new place where sensitive data piles up unprotected. Our supporting piece on AI audit trails covers the schema and the retention trade-offs, and the one on AI disclaimers covers what users should be told when content is generated.

06Passing enterprise AI security reviews and audits

Enterprise buyers now send AI-specific questionnaires alongside the standard ones. The questions are predictable: which models and providers you use, whether customer data trains any model, where processing happens, how tenants are separated and how prompt injection is handled. They also ask what humans approve, how AI behavior is tested and what is logged.

Map your answers to the frameworks buyers already recognize.

SOC 2 is the report most B2B buyers expect. It covers controls at a service organization across five trust services categories: security, availability, processing integrity, confidentiality and privacy. An AI feature does not need a separate report, but its controls need to sit inside the scope of the one you have. Auditors will want to see access control, change management and monitoring applied to prompts, models and retrieval pipelines just as they are to code.

HIPAA applies where your product handles protected health information. The practical questions are which vendors in the chain touch that data, including the model provider, and what agreements cover them. Our supporting article on HIPAA for AI vendors walks through the questions health care buyers ask.

The NIST AI Risk Management Framework is voluntary and organizes the work into four functions: Govern, Map, Measure and Manage. NIST added a Generative AI Profile in July 2024. Buyers do not certify against it, but structuring your AI risk documentation around those four functions gives reviewers a shape they already trust.

The EU AI Act matters if you sell into Europe. Obligations for general-purpose AI model providers applied from August 2, 2025, and the Article 50 transparency rules started to apply on August 2, 2026. Rules for stand-alone high-risk systems now apply from December 2, 2027, after the Digital Omnibus on AI moved the dates. Most SaaS features are not high-risk, but you should be able to say which category yours falls into and why.

The fastest way through a review is evidence, not assurances: a tested set of real cases, a data flow description, a permission diagram and a sample audit record. The enterprise AI security questions buyers ask lists the common questions with model answers.

07What we see in production

The pattern we see most often is not a dramatic attack. It is an AI feature built as a demo, with a broad service credential and a shared index, that works well until a security review asks how it separates tenants. At that point the feature stalls, sometimes for months, because the fix touches retrieval, permissions and logging at once.

The second pattern is retention drift. Prompt logs and traces are turned on for debugging, nobody sets an expiry, and a year later the trace store holds more sensitive text than the primary database.

The third is that teams underestimate how much their existing controls already solve. When the AI layer is wired through the permission model, tenant boundary and audit log instead of around them, security reviews get shorter, because the answers are ones the security team has given many times before.

That is how we approach AI security at Datics: we start from the product you already run. Our agent harness puts the model behind the same controls as the rest of your application: product context, trusted tools, permissions, tenant boundaries, business rules, human approvals, audit trails, observability and failure handling. Every request follows the same path: user intent, product context, allowed tools, permission check, approval, action, evaluation and audit.

By default the AI runs in your cloud, on your model. We build and test on synthetic or de-identified data, and our engineers have no standing access to client production data. When a product already has AI, we test it on 50 of the product's own cases, including misuse and prompt injection, rank the fixes and draft the answers your customers' security questionnaires ask for. We work within your SOC 2, HIPAA and contractual requirements, and we change only what the AI capability requires.

Frequently asked questions