AI systems create new paths for data to move: documents become embeddings, prompts reach model providers, tools query systems and outputs enter logs. Security teams need a map of that movement before they can apply the right controls.

A secure AI data pipeline classifies data, limits access at every stage, preserves provenance, controls retention and makes movement observable from source through model, tool and output.

The model is not a separate security universe. Established practices—least privilege, encryption, isolation, audit and incident response—still apply, but AI introduces probabilistic output and prompt-based attacks that require additional testing.

Map every data boundary

Document sources, ingestion, transformation, storage, retrieval, prompts, providers, tools, logs and downstream consumers. Include development and evaluation datasets. Mark where data crosses a network, legal entity or geographic boundary.

For each flow, record purpose, owner, classification, lawful basis where relevant, retention and deletion behaviour. Unknown copies are a larger risk than any single approved store.

Review whether the business outcome needs raw data. Tokenisation, pseudonymisation, aggregation or a smaller feature set may reduce exposure without reducing value.

Enforce least privilege before retrieval

Permissions must be applied before documents or records enter model context. If a user cannot open a source directly, the AI system should not retrieve it on their behalf unless a specifically authorised workflow requires that access.

Carry tenant, role and sensitivity metadata into indexes. Test object-level authorization, not only login. Isolate customers and environments. Use short-lived credentials for tools and restrict each tool to the operations the workflow needs.

The OWASP Top 10 for Large Language Model Applications provides a useful catalogue of risks including prompt injection, sensitive information disclosure and excessive agency.

Treat retrieved content as untrusted input

A document can contain instructions designed to manipulate the model. Separate system instructions from retrieved data and tell the model that evidence is content, not authority. Use allow-listed tools and validate every tool argument outside the model.

Do not depend on a prompt such as “ignore malicious instructions” as the only defence. Constrain what the system can do, require confirmation for consequential actions and monitor unusual patterns.

Test indirect prompt injection through files, webpages and support messages. Security review should include the content supply chain, not only the user prompt.

Control providers and retention

Understand whether prompts and outputs are stored, used for training, reviewed by people or transferred to subprocessors. Configure enterprise privacy controls and regional endpoints where required. Put contractual promises into an operating checklist that engineering can verify.

Minimise application logs. Sensitive prompts should not appear in error traces by default. Define retention by purpose and test deletion across primary stores, indexes, caches and backups.

Encrypt data in transit and at rest, but remember that the system must decrypt data to use it. Identity, authorization and workload isolation remain essential.

Preserve provenance

Record which source, model, prompt and tool version produced an important result. Sign or otherwise protect audit records where decisions need to be explained. Provenance supports incident investigation, quality evaluation and customer trust.

For generated code or content entering production, preserve review and approval. AI assistance should not erase the human and system controls already required for a change.

Monitor the business action

Security telemetry should connect model behaviour to the action attempted. Watch unusual retrieval volume, repeated access denials, tool sequences, data exfiltration patterns and spikes in long or encoded prompts.

Set rate and spend limits. Build circuit breakers that can disable a tool or model path without taking down the entire product. Include AI dependencies in incident response and recovery exercises.

The NIST AI Risk Management Framework offers a lifecycle structure for governance and measurement. Vinove’s Agentra and ValueCoders apply that practical focus to AI products and the surrounding engineering.

A control map for review

For every boundary, confirm data purpose and classification, identity and least privilege, isolation, encryption, retention, provenance, validation, monitoring and a tested failure response. Assign an owner and evidence for each control.

Secure AI is not achieved by one filter around a model. It comes from controlling the complete path through which data becomes a decision or action.

Apply the map to a real workflow

Consider an assistant that answers questions from customer contracts. The source documents contain commercial terms and personal information. The ingestion service should accept only approved repositories, attach customer and permission metadata and remove a contract when retention expires. Retrieval must filter by the requesting user before a passage reaches the model. The model may draft an explanation, but a deterministic service should calculate any amount and the interface should link to the relevant clause.

Telemetry can record contract identifier, retrieval result, model version and approval without storing the full contract or prompt indefinitely. A security test should place malicious instructions inside a contract and confirm they cannot change system policy or activate a tool. An incident switch should disable contract retrieval without taking down unrelated features.

Walking one workflow through the complete map usually reveals more than debating general AI security. It shows the exact boundary where identity, evidence, retention and action must remain under organisational control.