Cybersecurity · AI security
Controls around the AI you have already shipped
Prompt injection, retrieval that leaks across customers, agents holding more permission than the person using them. We engineer the guardrails, isolation and logging that let you answer for an AI feature rather than hope you are not asked.
Where this starts
The feature shipped faster than the controls
AI features tend to reach production by a route the security function never saw, because the prototype worked and the commercial pressure was real. The questions arrive afterwards, from a customer security review, a data protection assessment or a board that has been reading about the EU AI Act. They are reasonable questions. Most teams cannot yet answer them with evidence.
The questions we are usually brought in to answer
- Can a user make the model return a document they are not entitled to see
- What stops instructions hidden inside a retrieved document being obeyed as though the user had typed them
- What can the agent actually do, and who approved that list of actions
- Where do prompts and responses go, how long are they kept, and is customer data inside them
- Which model and which version answered a given request, and can you prove it
- If the provider changes the model underneath you, how would you find out
Our position
Most AI risk is not exotic. It is authorisation, tenancy and logging, applied to a component that happens to be a model.
What the work covers
Where the real exposure sits
The OWASP list for large language model applications is a useful map. The exploitable ground in a real deployment is narrower and considerably more mundane than the headlines suggest, which is good news for anyone willing to do the plumbing.
Prompt injection and untrusted content
Everything the model reads is input, including a retrieved document, a web page, a ticket comment and a file a customer uploaded. We separate instruction from data, constrain output handling so a response is never executed or rendered unescaped, and run injection payloads as part of the test suite rather than as a one-off exercise.
Retrieval and tenancy
Access control applied at retrieval rather than after generation. A vector store holding every customer’s documents in one index will eventually answer across them. We enforce the authorisation the application already has, at the point documents are fetched, and test it the way we would test any other tenancy boundary.
Agent permissions and tool calling
Every tool an agent can call is an action your system takes. We scope tools to the acting user’s permissions rather than the service account’s, require confirmation for anything irreversible, and put a hard boundary around anything that spends money, sends a message or writes to a system of record.
Data handling and residency
What leaves your estate, to which provider, in which region, under what retention and training commitments. Redaction before the call where the data does not need to be there at all, and the contractual position checked against what the code actually sends, which is not always the same thing.
Evaluation as a release gate
Safety and injection evaluations running in the pipeline like any other test, with a threshold that blocks a release. A prompt change and a model change are code changes and are treated as such, including review and rollback.
Assurance and regulation
Mapping to the NIST AI Risk Management Framework, ISO 42001 and whichever EU AI Act obligations follow from your classification, with the evidence produced by the running system rather than assembled by hand the month before an audit.
How it stays provable
An AI control that is not logged is a claim
These are the points where we wire evidence in, chosen because they are the points you will be asked about.
Request
Structured logging of model, version, prompt template, retrieved document identifiers and the acting user, with sensitive fields redacted at write time rather than on the way out.
Retrieval
Authorisation decisions recorded alongside the documents returned, so a question about a possible leak is answered from the log rather than reconstructed from memory.
Action
Every tool invocation attributed to a user and to an approval, with irreversible actions requiring an explicit confirmation that is itself recorded.
Release
Evaluation results attached to the build, so you can show exactly which safety thresholds a given version passed before it went out.
Drift
Scheduled re-evaluation against a fixed set, which is how a silent provider-side model change becomes visible to you before it becomes visible to a customer.
What you are left holding
- A written control set mapped to the framework your customers ask about
- Retrieval that enforces the application’s own permissions, with tests that prove it
- An agent permission model with a named owner for every tool
- Injection and safety evaluations running as a release gate
- Logs that answer a data protection question without an engineer having to dig
You already have AI in production
Tell us what it does and who it serves. We will tell you which of these controls are missing and which ones genuinely matter for your risk.