Securing enterprise AI adoption: a practical AI security control set
The AI security controls that matter first — identity, data boundaries, model access, logging, human oversight and supplier assurance.
Why AI security fails in practice
Most organisations do not lose control of AI because a model behaves unexpectedly. They lose control because an unmanaged tool receives sensitive information, an integration is granted broad standing access, or nobody can later evidence what the system did and who approved it.
The practical response is unglamorous. Treat every AI system as an application that processes data, holds credentials, produces output that people act on, and has a supplier behind it. Existing security disciplines already cover most of that ground once you extend them deliberately.
Control one: know what AI you actually run
Maintain an AI inventory that records the system, its business owner, the data classes it touches, the integrations it holds, whether it can take action autonomously, and the supplier behind the model. Include embedded AI features inside existing SaaS products, because that is where most unmanaged use hides.
Classify each entry by impact and autonomy. A drafting assistant that only returns text to one user is a very different risk profile to an agent that can email customers, update records or approve transactions.
Control two: data boundaries before capability
Decide, per system, which data classes may enter it, whether inputs may be retained or used for training, where processing occurs, and how long records persist. Configure the tenancy and retention settings to enforce that decision rather than relying on an acceptable-use statement.
For retrieval-based systems, the boundary is the index. If the underlying permissions of the source repositories are inconsistent, retrieval will faithfully surface content that a user was never meant to see. Fix source permissions before enabling enterprise-wide search.
Control three: identity, least privilege and blast radius
Give each AI integration its own identity, scoped credentials and a short-lived token where the platform supports it. Avoid shared service accounts with broad standing permissions, and avoid granting an agent write access simply because read access was inconvenient.
For anything that can act, require a bounded action set, rate limits and a reversible path. The question to answer before deployment is simple: if this system is manipulated, what is the worst action it can take before a human notices?
Want this assessed against your environment?
Send us the specifics and a senior advisor will respond within one business day.
Control four: logging, oversight and evidence
Log prompts, retrieved context references, model responses, actions taken and the human decision that followed, in line with your privacy obligations. Without that trail you cannot investigate an incident, defend a decision, or demonstrate oversight to an auditor or a regulator.
Define where a human must review before an output is used, and make that gate proportionate. Blanket review destroys the value case; no review on a high-impact system destroys the risk case.
Control five: supplier and model assurance
Assess the provider on data use and retention, tenancy separation, subprocessors and hosting regions, security certifications, model change and deprecation notice, incident notification terms and your exit position.
Record the answers alongside the inventory entry. Supplier posture changes, so schedule reassessment when the vendor changes model versions, hosting arrangements or terms.
Sources and further reading
- ISO/IEC 42001 AI management systems
- ISO/IEC 27001 information security management systems
- OWASP Top 10 for Large Language Model Applications
- NIST SP 800-53 security and privacy controls
This article provides general information and decision support. It is not legal advice, audit assurance, certification advice or a guarantee of outcome.
Related reading
AI risk assessment: how to assess an AI system before it ships
A repeatable AI risk assessment covering purpose, data, model behaviour, integration, human oversight, failure modes and evidence.
Read articleISO 42001 vs ISO 27001: how the two management systems interlock
What each standard covers, where they overlap, and how to run one integrated management system instead of two parallel programmes.
Read articleThe AI governance operating model: roles, gates and evidence
How to design an AI governance framework that approves useful work quickly and stops harmful work early, without a committee bottleneck.
Read article