AI security guide

Data leakage risks

The most common AI security incident is not a novel attack. It is an employee pasting customer data, source code, or strategy documents into a consumer AI tool that trains on input. The risk is real, measurable, and usually preventable.

Start by classifying what may enter an AI system. Public marketing copy is different from customer PII, health records, source code, and unreleased financials. Each class needs its own rule.

Pair policy with controls: browser DLP, endpoint agents, SSO-required sign-in, and centralized procurement. Policy without enforcement is advice, not security.

Model supply chain

AI systems depend on models, fine-tuning data, inference hosts, vector stores, embedding providers, and third-party plugins. Each is a supply-chain node with its own trust boundary.

What to verify: Who trained the base model? Who hosts inference? Is data retained, and for how long? Are embeddings generated by a separate vendor? Are plugins or MCP tools pulling from external APIs?

Build a vendor security checklist before approving any AI tool: data residency, SOC 2 or ISO 27001, penetration test summaries, subprocessor list, model training opt-out, audit logs, and breach notification terms. This is standard vendor due diligence applied to AI.

Prompt injection

Prompt injection happens when an attacker hides instructions inside data the AI processes, such as an email, document, or web page the model is asked to summarize. The goal is to make the model ignore its intended instructions or leak context.

Prompt injection is hard to eliminate completely. The practical response is defense in depth: limit what the AI can do, validate its outputs, and never give it direct access to privileged actions based on untrusted input alone.

• Separate instructions from untrusted data using clear delimiters and templating.
• Reduce system privileges: the AI should read or suggest, not execute, delete, or approve.
• Use allow-lists for tools and APIs the AI can call, and require human confirmation for destructive actions.
• Monitor for suspicious prompt patterns and anomalous output behavior.

Output handling and validation

AI output is probabilistic. It can be confidently wrong, hallucinated, or subtly biased. The security risk appears when output is treated as fact and fed into decisions, code, customer replies, or automated workflows.

Workflow: AI generates a draft → Human or automated validator checks accuracy, source references, and policy compliance → Approved output moves to the next system → Rejected output is logged and reviewed.

For code-generation tools, run outputs through normal code review, static analysis, and sandboxed testing before merge. For customer-facing content, enforce review queues and prohibited-word filters. For retrieval-augmented systems, cite sources so users can verify claims.

SaaS vs self-hosted

The deployment model changes your control surface. SaaS is faster to adopt and easier to maintain, but you rely on the vendor's data handling, isolation, and availability. Self-hosted gives you more control, but you own patching, scaling, and hardening.

Many organizations use a tiered approach: SaaS for public and internal productivity, private cloud for sensitive workflows, and self-hosted for the most restricted data. Document which data class maps to which deployment model.

Identity and access

AI tools should inherit your identity fabric. Do not let users create standalone accounts with personal emails. Centralize authentication through SSO, map roles to permissions, and remove access automatically when someone leaves.

Least privilege applies to AI too. Not every user needs access to every model, every plugin, or every internal knowledge base. Define roles such as explorer, standard user, power user, and admin, each with different model and data permissions.

Log who asked what, when, and which model or tool answered. Audit logs support incident response, compliance, and behavior analysis. Make sure logs themselves do not retain sensitive prompt content longer than necessary.

Incident response

AI incidents are still security incidents. Adapt your existing IR playbook rather than building a separate one from scratch. The difference is usually the data involved and the speed at which output can spread.

Common AI incident types: sensitive data pasted into a public tool, malicious prompt injection in a customer-facing bot, AI-generated code with a hidden dependency, unauthorized user access through a shared API key, or model output that leaks training data.

Response steps: Contain the exposure (revoke access, rotate keys, block a tool), assess what data or system was affected, notify the right owners, document lessons, and update controls. Run tabletop exercises that include AI scenarios so the team is not figuring it out during a real event.

Security checklist

1. Inventory approved AI tools and block consumer versions at the network or endpoint level.
2. Classify data that may enter AI systems and write simple rules for each class.
3. Require SSO, enterprise agreements, and no-training clauses for all approved tools.
4. Map the supply chain: model, host, embeddings, plugins, and data stores.
5. Apply least-privilege access and role-based permissions.
6. Validate outputs before they reach customers, code repositories, or privileged systems.
7. Enable audit logs and define retention rules for prompts and responses.
8. Add AI scenarios to your incident response playbook and exercise them.