AI & LLM Security
AI security assessment, of the whole architecture.
We assess AI as an architecture rather than a model: prompts, retrieval, agents, tools and the enterprise data sitting at the end of the chain. You get findings written as attack paths, with the controls that close them.
- Practice
- AI & LLM Security
- Scope
- LLM, RAG, agents, MCP
- Frameworks
- OWASP LLM · NIST AI RMF
- Delivery
- Senior, direct
What is AI Security Assessment?
An AI security assessment establishes how your AI systems can be misused, what they can reach when they are, and which controls would stop it. It covers the model, but most of the work sits around it: the application, the retrieval pipeline, the tools an agent can call, and the data inside the blast radius.
Compromise rarely requires touching the model at all. A document lands in the retrieval corpus carrying instructions, the agent reads it as content and acts on it as direction, and calls a tool it was legitimately granted. The assessment is built to find those chains before someone else does.
Who it is for.
- Teams shipping LLM features, copilots or chat assistants to customers or staff
- Organisations running RAG over internal documents or customer data
- Anyone deploying AI agents with tool access, MCP servers or plugins
- Risk, security and compliance leads who must evidence control of AI to a board, customer or auditor
What we do.
Map the AI architecture
Inventory models, prompts, retrieval sources, tools, agents and connectors, and the trust boundaries between them, as they actually run rather than as the diagram claims.
Test prompt and indirect injection
Direct and indirect prompt injection, jailbreaks and instruction smuggling through documents, web content and tool output.
Assess RAG and data boundaries
What can reach the retrieval layer, whether retrieved content carries provenance, and which data an attacker could pull back out through the model.
Review agent and tool permissions
What the agent can invoke without a human, what scope each tool or MCP server inherited, and where high-impact actions need approval.
Check governance and evidence
Whether the organisation can show control of the system: ownership, risk assessment, monitoring and the records an auditor or customer will ask for.
What actually arrives.
An engagement that ends at a slide deck leaves you with an opinion. These are the artefacts this one produces.
Executive summary
What the AI system exposes, in business terms, and the small number of decisions leadership needs to make.
Attack-path findings
Each finding written as a chain: entry point, pivot, consequence, with evidence and reproduction steps.
Prioritised remediation plan
Architectural controls first (scoped tool permissions, provenance on retrieved content, human approval on high-impact actions), ranked by risk reduced.
Framework mapping
Findings mapped to OWASP LLM Top 10, NIST AI RMF, ISO/IEC 42001 or the EU AI Act, whichever your stakeholders ask about.
Retest and evidence pack
Verification that fixes hold, documented for customers and auditors.
Frequently asked questions.
- How is an AI security assessment different from a normal penetration test?
- An AI system fails differently. We test the architecture: prompt handling, retrieval pipelines, agent tool permissions, MCP trust boundaries and the data those components can reach, alongside the governance question of whether the organisation can evidence control of it.
- Do you need access to the model itself?
- Usually not. Most of the risk sits in the application, retrieval, tools and data around the model, and that is where most of the testing happens. We agree the access needed during scoping.
- Which frameworks do you map findings to?
- OWASP LLM Top 10, NIST AI RMF, ISO/IEC 42001 and the EU AI Act, whichever your auditors, customers or regulators actually ask about.
- Who does the work?
- Senior practitioners, directly. The person who scopes the engagement is the person who delivers it.
Next step
Talk to us about AI Security Assessment.
Start with a scoping conversation.
Describe the system and the decision you need to make. You will get a practitioner's view of where the risk actually sits, and what the engagement should cover, before anything is scoped.