AI Security Foundations

Part 1 of the KIS AI Security Series: a practical starting point for protecting data, controlling access and keeping people accountable as your organisation adopts AI.

Start with the everyday decisions

An employee summarises a customer email. A developer asks an assistant to review code. A service team uses a chatbot to search internal documents. These familiar activities are where AI security begins.

You do not need to train a model to be responsible for AI risk. If a tool processes your information or influences your decisions, you need to understand its boundaries. This series starts with those basics, then moves into data protection, prompt injection, connected knowledge sources and AI agents.

Our earlier article, AI Security with Human Oversight, introduced the governance perspective. This practical series turns that perspective into steps teams can apply one use case at a time.

What does AI security actually protect?

AI security protects the complete service: the information people submit, the accounts that access it, the model and its integrations, and the actions taken using its output. A secure cloud platform alone cannot prevent an employee from uploading an unsuitable document or accepting an inaccurate answer.

Four risks to recognise first

1. Sensitive information leaves its intended boundary

A prompt can contain as much confidential information as an attachment. Before approving a tool, check what it stores, who can access the data, how deletion works and whether the relevant service settings permit use for model improvement. Do not assume that every free or paid service handles data in the same way.

Starting control: publish clear examples of permitted and prohibited information. Use approved enterprise services and minimise or remove sensitive details wherever possible.

2. External content tries to redirect the assistant

A document or web page may contain instructions designed to make an assistant ignore its task or reveal information. This is called prompt injection. A warning in the system prompt is useful, but it is not a complete security boundary.

Starting control: treat retrieved material as untrusted, enforce access permissions outside the model, validate tool requests and test how the application behaves with hostile content.

3. The assistant can do more than the task requires

Drafting a reply is different from sending it. Reading a report is different from changing a customer record. Risk increases when an AI tool can act through connected systems.

Starting control: start with read-only access where practical. Give each integration narrowly scoped permissions and require human approval for consequential actions such as external communication or production changes.

4. A convincing answer is treated as a verified answer

AI output can be fluent and wrong. A fabricated policy clause or an insecure code suggestion may appear credible to a busy reviewer. Asking the model how confident it is does not establish correctness.

Starting control: check important claims against authoritative sources, test generated code and assign a qualified reviewer to decisions that could materially affect people or the business.

An everyday example: summarising customer complaints

A practical first-month plan

Week 1: make AI use visible

Ask teams which assistants, copilots and AI-enabled vendor features they already use. Record the purpose, owner, users, data and connected systems. A short inventory is more useful than a long policy that no one can apply.

Week 2: choose a bounded pilot

Select a task with a measurable benefit and limited consequences if the output is wrong. Define approved data, permitted actions, reviewer responsibilities and conditions that would stop the pilot.

Week 3: test the likely mistakes

Try incorrect questions, sensitive inputs, misleading documents and requests outside the tool’s purpose. Check that access controls still apply and that unsafe actions are blocked or escalated. Record the findings and fixes.

Week 4: review evidence before expanding

Compare the benefits with observed errors and control gaps. Confirm that logging is proportionate and protected: logs can themselves contain confidential prompts or responses. Decide who can suspend the service and how users report a problem.

Guidance to support your programme

The NIST AI Risk Management Framework provides a voluntary foundation for managing AI risk throughout its lifecycle. The OWASP GenAI Security Project offers practical resources for security risks in generative AI applications. Use these references alongside your existing security and privacy processes; tailor the controls to the actual use case.

Coming next: protecting data in AI workflows

Part 2 will examine what belongs in a prompt, how to review a provider’s data handling and why connected document sources need their own access controls. Later articles will cover prompt injection, retrieval-augmented generation (RAG), AI agents and security monitoring.

KIS AI Security Series · Part 1. Examples are illustrative and intended to help teams discuss practical controls.