AI Trust & Security

This is not a penetration test with a chatbot bolted on. Your existing security people already cover the network, the endpoints and the login page; we cover the failure modes that only exist once a model is in the loop - and that classical tooling does not see at all. A firewall has no opinion about a paragraph that talks your support assistant into quoting another customer's record.

Every company that shipped a chatbot, a RAG pipeline or an agent this year has attached a new interface to its data: one that takes instructions in natural language, from anyone, and was probably never tested against someone hostile.

We red-team that surface. Fixed scope, fixed price, a report your engineers can act on - and a retest when they have.

Two ways in

Timelines start once access is in place - a staging environment, test accounts, and written authorisation to attack them. Nothing is probed before that authorisation exists, including on a quick scan.

What the red team probes

Breadth comes from attack agents - automated adversaries that generate, mutate and replay thousands of attack patterns against every endpoint, adapting to what gets through the way a patient human would. Depth comes from hands-on red-teaming, because the findings that matter are specific to what your system is connected to. The report distinguishes the two honestly.

The code is part of the attack surface

Model behaviour is only half the audit. The other half is a white-box review of the application wrapped around it - because most exploitable findings live in the glue, not the model:

• Prompt assembly. Where untrusted input meets the prompt, and whether anything separates data from instructions along the way.
• Trust boundaries. What the model's output is allowed to touch before a human or a validator sees it - SQL built from completions, shell commands, rendered HTML.
• Secrets and scope. API keys in client code, over-broad tool credentials, retrieval indexes that quietly contain more than the bot should serve.
• The classics. An LLM application is still an application; injection by paragraph does not retire injection by query string.

What you get

1. 1

   Scoping call

   What the system does, what it can reach, what a bad day looks like. This fixes the price - no open-ended engagement.

2. 2

   Attack agents

   Automated adversaries sweep injection, leakage and manipulation patterns against a staging deployment or an isolated tenant.

3. 3

   Red team

   Hands-on attacks built from your architecture - your retrieval sources, your tools, your permission model - plus the white-box code review.

4. 4

   Report and walkthrough

   Findings ranked by exploitability and blast radius, each with a reproduction and a concrete fix. Presented to your engineers, not thrown over a wall.

5. 5

   Retest

   After remediation, the failing probes run again. The finding is closed when it stops reproducing, not when a ticket does.

The probe suite from your audit is yours to keep - it runs in CI, so the guardrail that regresses three model-versions later fails a pipeline instead of surfacing on social media.

Measured, not anecdotal

A single screenshot of a jailbreak proves very little: models are stochastic, and the interesting question is not whether an attack can work but how often it does. So every probe is repeated, and findings come as success rates with the number of trials behind them. When you fix something, the retest reruns the same suite and reports the rate again - which is how you can tell a real fix from one that moved the problem. Regressions are tracked across retests rather than rediscovered each time.

Retests, afterwards. Once an audit is done, we can rerun your suite on a regular cadence - typically quarterly - and report what changed. New features bring new attack surface and new probes; that is a change to the scope, and we say so rather than quietly widening it.

Agent deployments are a different problem

A chatbot that fails embarrasses you. An agent that fails does something. The security question changes shape when the model holds credentials:

• Blast radius before behaviour. The first question is not "can the model be tricked?" - it usually can - but "what happens when it is?" Scoped permissions, human confirmation on irreversible actions and egress control decide whether an injection is an incident or a log line.
• Tool chains compound. A read-only search tool plus a send-email tool is an exfiltration channel. We map what the combination of tools permits, which is rarely what any single tool suggests.
• Untrusted input is the default. An agent that reads tickets, web pages or inboxes is executing instructions from the public. The architecture has to hold even when persuasion fails.

We audit agentic systems against exactly this: the permission model, the confirmation boundaries, and what a compromised session can reach - then verify the model-level findings against the architecture-level consequences.

Why us

• We build these systems. LLM applications and agents are part of our language and agents practice - we audit as practitioners who have had to defend the same architectures we attack, not as auditors reading about them.
• Measurement is our trade. Quantifying model behaviour - uncertainty, calibration, failure rates - is what a scientific AI consultancy does all day. A security posture you cannot measure is an opinion.
• We have skin in the game publicly. Our positions on AI security are on record with the European Commission's AI Office - see the gaps in Europe's frontier AI strategy - and the assistant on this site is deployed under the same discipline we sell.
• Clear about the boundary. We are engineers, not counsel: we test systems and hand you the evidence. If your GDPR or AI-Act paperwork needs that evidence, it slots in - but compliance sign-off stays with the people whose job it is.

Not included: classical infrastructure and network penetration testing, which your existing security supplier does better than we would; fixing the findings, which we will happily quote as a separate piece of work or leave to your engineers; and compliance sign-off of any kind. How your data is handled during the work is your choice at intake - the three levels are set out with the other assessments. Responses from your system can contain your own data, so real data is redacted out of findings before a report is written.

Where to go next