Cybersecurity · AI security
Controls for the AI features you have already launched
AI features bring new risks. Hidden instructions can hijack a model, AI search can return one customer’s documents to another, and AI agents can end up with more access than the people using them. We build the safeguards, separation and logging that let you answer questions about your AI features with evidence.
Where this starts
The feature launched before the controls were in place
AI features often reach production without a security review, because the prototype worked and there was commercial pressure to launch. The questions come later, from a customer’s security review, a data protection assessment, or a board that has been reading about the EU AI Act. They are reasonable questions, but most teams cannot yet answer them with evidence.
The questions we are usually asked to answer
- Can a user get the AI to show them a document they are not allowed to see?
- What stops instructions hidden in a document from being followed as if the user had typed them?
- What can the AI agent actually do, and who approved those actions?
- Where do prompts and responses go, how long are they kept, and do they contain customer data?
- Which model and which version answered a particular request, and can you prove it?
- If the AI provider changes the model without telling you, how would you find out?
Our position
Most AI risks are not new. They are familiar problems of permissions, customer data separation and logging, applied to a system that happens to include an AI model.
What the work covers
Where the real risks are
The OWASP list of risks for AI applications is a useful guide. In practice, the real risks in most deployments are narrower and more ordinary than the headlines suggest, which means they can be fixed with careful engineering.
Prompt injection and untrusted content
Everything the model reads can contain instructions, including documents, web pages, support tickets and files uploaded by customers. We keep instructions separate from data, make sure the model’s responses are never run as code or displayed without being made safe, and include injection attacks in your regular automated tests.
AI search and customer data separation
We apply access controls when documents are retrieved, not after the answer has been generated. If every customer’s documents sit in one shared search index, the AI will eventually return one customer’s information to another. We apply your application’s existing permissions at the point documents are fetched, and test them in the same way as any other boundary between customers.
Agent permissions
Every tool an AI agent can use is an action your system takes. We limit each agent to the permissions of the person using it, rather than a powerful system account. We require confirmation before anything that cannot be undone, and put firm limits on anything that spends money, sends messages or changes important records.
Data handling and location
We establish what data leaves your systems, which provider receives it, where it is stored, how long it is kept and whether it can be used for training. Where data does not need to be sent at all, we remove it before the call. We also check that your contracts match what your code actually sends, because the two do not always agree.
Testing before every release
Safety and injection tests run in your pipeline like any other test, with a threshold that blocks a release. A change to a prompt or a model is treated as a code change, with review and the ability to roll it back.
Assurance and regulation
We map your controls to the NIST AI Risk Management Framework, ISO 42001 and any EU AI Act obligations that apply to you. The running system produces the evidence, so nobody has to gather it by hand in the month before an audit.
How it stays provable
If a control is not logged, you cannot prove it works
These are the points where we build in evidence. We chose them because they are the points you will be asked about.
Request
We log the model, its version, the prompt template, the documents retrieved and the user who made the request. Sensitive details are removed when the log is written, not later.
Retrieval
Every access decision is recorded alongside the documents returned. If someone asks whether data was leaked, the answer comes from the log rather than from memory.
Action
Every action an agent takes is linked to a user and an approval. Actions that cannot be undone need explicit confirmation, and that confirmation is recorded too.
Release
Test results are attached to each build, so you can show exactly which safety thresholds a version passed before it was released.
Model changes
We re-test regularly against a fixed set of cases. If your provider quietly changes the model, you will notice before your customers do.
What you are left with
- A written set of controls, mapped to the framework your customers ask about
- AI search that respects your application’s permissions, with tests that prove it
- A permission model for AI agents, with a named owner for every tool
- Injection and safety tests that must pass before any release
- Logs that answer data protection questions without an engineer having to investigate
You already have AI in production
Tell us what it does and who uses it. We will tell you which controls are missing, and which of them really matter for your level of risk.