AI security
The risks that arrive with the model
Shipping an AI system creates an attack surface that did not exist before, and most of it is invisible to a conventional security review. A penetration test looks for injection in your web tier; it does not ask whether a document in your knowledge base can instruct the assistant reading it.
We build these controls in while the system is being designed. Retrofitting them after launch means unpicking decisions about trust and authority that are by then load-bearing.
Prompt injection
A model reading a document, a web page or a support ticket is reading text an attacker may control. Indirect injection is the harder half, and it is not solved by filtering the user’s own input. We design so a model’s output never carries authority it has not earned.
Retrieval access control
RAG systems leak when the index forgets who may see what. Permissions have to be enforced at query time and inherited from the source system — not applied as a filter after the documents have already been retrieved.
Data poisoning & provenance
Training sets, fine-tuning data and retrieval corpora are all attack surface if an outsider can influence what goes into them. We track provenance and put change review on anything that feeds a model.
Model supply chain
Third-party weights, adapters and packages, pinned and scanned. Serialised model formats that execute code when loaded are treated as executables — because that is what they are.
Secrets & PII boundaries
What crosses into a prompt, what lands in a log, and what could resurface in an output months later. Redaction at the boundary, and log hygiene treated as seriously as the model itself.
Agent authority
Tool-using agents hold real credentials. Least privilege per tool, an authorisation boundary the model cannot talk its way past, and human approval on anything irreversible.