Key takeaways
- AI security tools enforce controls at runtime, while AI risk management software tracks policy and inventory; enterprises generally need both.
- Four control points determine exposure: data entering the model, tools it can call, output leaving the system, and identity across all three.
- Vendor certification is weak evidence of fitness, so run your own permission, refusal and log-reconstruction tests during a trial before you commit.
AI security tools are the systems that control what data reaches a model, what a model is allowed to do, what leaves the system, and what evidence you keep of all three. This article sets out the four control points worth protecting, explains why vendor certification is weak evidence of fitness, and gives six checks to run during a trial. It is written for security, data and engineering leaders choosing tooling before an AI deployment scales.
The sequencing is what causes the damage. A team builds an AI capability, it works, it spreads across the organisation, and security tooling gets selected afterwards to cover something already running in production. By then the integration points are fixed and the tooling has to work around them.
Choosing earlier is cheaper. It also changes what you are choosing, because the question shifts from how to monitor an existing system to how to constrain one you are still designing.
What are AI security tools?
AI security tools are software that enforces and evidences controls around machine learning and language model systems. The category covers four functions: controlling data entering the model, constraining what the model can access or act on, inspecting what leaves the system, and producing records that satisfy an auditor.
This overlaps with AI risk management software, which sits a level above and tracks policy, model inventory and assessment status rather than enforcing anything at runtime. The two are complementary. Enterprises usually need both, and confusing them leads to buying a register when what was needed was a control.
Agent-based systems raise the stakes because the model can act rather than only respond. AI agent security tools for enterprise use are a distinct requirement: an agent with write access to a system of record needs constraints that a chatbot does not.
The four control points
Four points determine your exposure, and each needs its own control.
Data entering the model. Retrieval pulls documents into a prompt, and permissions that exist in the source system are frequently lost in transit. The control is enforcing the original access rules at retrieval time rather than trusting the model to be discreet about what it has been shown.
Tools the model can call. Every function an agent can invoke is a capability someone could induce it to misuse. Constrain by allowlist, scope credentials narrowly, and require approval on anything that writes.
Output leaving the system. Model output can carry data the requester was never entitled to see, or instructions injected from content the model processed. The OWASP list for language model applications is the reference for this class of problem.
Identity across all three. One identity model, applied consistently. Two identity models is how the controls above end up enforcing different rules on the same request.
| Control point | What can go wrong | What to verify during a trial |
|---|---|---|
| Data entering the model | Retrieval bypasses source permissions | Query as a restricted user and confirm the restriction holds |
| Tools the model can call | Over-scoped credentials, unapproved writes | Attempt an action outside the allowlist and check it is refused |
| Output leaving the system | Sensitive data or injected instructions in responses | Test with adversarial content in the source corpus |
| Identity and audit | Gaps between systems, incomplete records | Reconstruct a full request path from logs alone |
Why certification is not evidence
Vendor certification tells you a product passed a defined assessment. It tells you very little about whether the product will meet your acceptance criteria in your environment, and treating the two as equivalent is a recurring source of expensive surprise.
We learned this expensively on a consent management implementation for an enterprise e-commerce client. The requirement was a unified platform across web and app, meeting GDPR and ePrivacy obligations while keeping analytics and attribution compliant. The chosen vendor was a Google-verified platform, selected on advertised support for both channels, flexible customisation and strong reporting. Partner documentation suggested a direct integration with no custom work required.
None of the acceptance criteria worked out of the box. Rendering was inconsistent between channels. Consent did not sync between the app and its web-views, so users were prompted twice. Consent state was stored only inside the vendor SDK in encrypted form, which made it unreadable by Google Tag Manager and broke the analytics pipeline. Styling options were incomplete on mobile, and several SDK issues stayed unresolved.
Our team built the way through: exporting consent data via the vendor API as an encrypted string, passing it into the web-view so the platform did not trigger again, then extracting consent values and converting them into key-value pairs that Tag Manager could read. The implementation is stable and compliant today. It cost considerably more engineering than the procurement decision assumed.
The transferable point has nothing to do with that vendor. Any tool in a young category will have a gap between its marketing surface and its behaviour in your architecture, and the only way to find the gap is to run your own acceptance criteria against it before you commit.
Six checks to run before you sign
Run these during a trial, using your own data and your own environment.
- Query as a restricted user and confirm the restriction survives retrieval.
- Attempt an action outside the permitted set and confirm refusal.
- Place adversarial content in the source corpus and check what reaches the output.
- Reconstruct one complete request path from logs alone.
- Export your configuration and confirm it is portable.
- Test every channel you actually use, including the awkward ones such as embedded web-views.
The ENISA guidance on securing machine learning systems is a useful companion when defining what else to test, and the EU AI Act sets out the record-keeping obligations that check four is really about.
Choosing tooling before your AI systems scale?
We help European organisations design and evaluate the controls around private AI deployments, and we test vendor claims against real acceptance criteria before anyone signs. Talk to our team about what you are assessing.
Frequently asked questions
What is prompt injection in AI systems?
Prompt injection is an attack in which instructions hidden in content a model processes, such as a document, web page or email, override the instructions the system was given. Prompt injection can make a model leak data or misuse its tools, which is why AI security tools inspect output and constrain what an agent can call.
How do you stop RAG from exposing restricted documents?
Stop retrieval-augmented generation (RAG) from exposing restricted documents by enforcing the source system’s access rules at retrieval time, so the model only sees what the requesting user is entitled to see. Relying on the model to withhold what it has been shown does not work. Test the control by querying as a restricted user during a trial.
What should AI agent security tools for enterprise cover?
AI agent security tools for enterprise should cover an allowlist of the functions an agent can call, narrowly scoped credentials, human approval on any write action and a complete audit trail of every step. Agents with write access to a system of record need these constraints, because an agent can act where a chatbot can only respond.
Do you need AI risk management software as well as AI security tools?
Enterprises usually need both AI risk management software and AI security tools, because the two do different jobs. AI risk management software tracks policy, model inventory and assessment status, while AI security tools enforce controls at runtime. Buying a register when the gap is a runtime control leaves the actual exposure unaddressed.
What does the EU AI Act require for AI logging?
The EU AI Act requires high-risk AI systems to record events automatically over their lifetime, so their behaviour can be traced and audited. AI security tools support that obligation by producing records an auditor can use. Reconstructing one complete request path from logs alone during a trial shows whether a tool’s logging is good enough.
When should you choose AI security tools?
Choose AI security tools while the AI system is still being designed, before it scales across the organisation. Selecting tooling afterwards means working around integration points that are already fixed, which costs more. Choosing early changes the question from how to monitor an existing system to how to constrain one still in design.
__________________________________________________________
The Groundwork Advantage
Between 60 and 95 per cent of enterprise AI initiatives produce no measurable business value. Our free AI handbook covers what has to be true inside an organisation before AI produces anything: clear business objectives, data you can trust, governance built in from the start, and infrastructure that keeps your options open.
Read the handbook | Take the five-question self-assessment
__________________________________________________________
