Enterprise AI security checklist: 5 control points for data, models, permissions, and audit

We ran a security audit last year for a mid-sized life insurance company before their underwriting Copilot went live. The system was polished. Even the chief compliance officer nodded through the demo. We didn't start by examining the model. We started by tracing what data it could access. Their RAG vector database had ingested every policy in the company to build its search index. In doing that, it had pulled in ID numbers and medical summaries without any filtering. Any employee with a login could ask the right question and retrieve those records. The system worked fine. Nobody had drawn that line.

The pattern repeats across our work. Companies prioritize whether AI is accurate. Few conduct systematic checks on whether systems are actually safe. We compiled incidents from our practice into a checklist that breaks down into five control points: data, models and prompts, access control, audit, and supply chain.

What this enterprise AI security checklist examines

Enterprise AI security maintains confidentiality, enforces permission boundaries, and enables traceability from data ingestion through model execution to final output. This isn't about acquiring a secure model. It's about establishing control points across your data and processes.

The five control points and their key checks appear below. Compare them against your current setup.

Data classification and model prompts: guarding entry and exit points

Data classification is the first control point, though teams often skip it. The process is straightforward. Before data reaches your AI system, sort your fields into four tiers: public, internal, confidential, and personally identifiable information. Keep confidential data and PII either out of your search indices or de-identified first. If you operate in Taiwan, pay attention to what the Personal Data Protection Act specifies about sensitive categories. Medical records, health exams, and criminal history have special protections. Financial institutions must also layer in regulator requirements for outsourcing and cloud deployment. If sensitive data doesn't need to enter the model, keep it out. When it must, apply masking at the field level.

The second control point is models and prompts. Prompt injection is the most concrete threat here. A user, or a compromised document, phrases a query to trick the model into revealing restricted content or performing actions it shouldn't. Three defenses matter: structurally separate user input from system instructions, validate all model output before it writes to a database or triggers an action, and use whitelists for every tool call in agent workflows. It's better to constrain what an agent can do than to let it touch production systems without guardrails.

Access control, audit, and supply chain: making behavior controllable, queryable, and traceable

The third control point is access control. This is where that insurance company ran into trouble. The AI ran under a single high-privilege service account with broad read access. Users could ask the AI to retrieve data they normally couldn't access. The right approach makes AI access follow user identity. Data you can't see in your regular system shouldn't surface through the AI. In RAG systems, this means document-level permission filtering. Implementation is tedious, but it separates a contained incident from a data breach.

The fourth control point is audit trails. Many teams only log API call counts, which tells you nothing if something goes wrong. At minimum, record the requester's identity, timestamp, what was asked, which source documents were retrieved, what the model returned, and whether anyone acted on the output. Audit trails serve more than security investigation. Financial services and healthcare regulators will ask why the AI made a particular recommendation. Having the trail now means providing an answer instead of reconstructing events under pressure.

The fifth control point is supply chain. Each third-party model and each integration creates a possible data exit. You need specific answers: Will the vendor use your data to train its model? Where will your data land geographically? Does the contract include a Data Processing Addendum? Does the vendor's security certification hold up? Taiwan-based companies often overlook cross-border data transfers, especially when sending data to overseas APIs. The Personal Data Protection Act's notification and consent requirements don't stop applying because you're using AI.

Working through all five control points shows that most risk lives not in the model itself but in the joints where the model meets your data and processes. At Tenten, security checks for FDE deployments aren't post-launch documents. Engineers and business leads work through them together in week one. A polished demo matters little if a medical record leaks and the project ends.