AI security, for systems that are already running
Most organizations did not decide to adopt AI. It arrived inside tools they already paid for, in code their developers generated, and in a feature someone shipped to answer a customer question. The security questions that follow are ordinary ones — what can this reach, who can make it act, what happens when the answer is wrong — asked about a component that does not behave like the rest of the stack.
The failure modes are documented, and they are not the usual ones
The OWASP Top 10 for LLM Applications 2025 names the ten that matter most in practice: prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. Several have no equivalent in a conventional application. A model cannot reliably separate instructions from data, so any text it reads — a document, a web page, a support ticket — is a potential instruction to it.
OWASP Top 10 for LLM Applications 2025 is the reference used on these pages, alongside the NIST AI Risk Management Framework.
What an engagement here looks like
An assessment reads the system as built — prompts, tools, retrieval, identity and output handling — and reports what an attacker can reach through it, against the OWASP Top 10 for LLM Applications 2025. It names what is reachable, what an untrusted input can cause, and what evidence exists that a control is in place rather than intended.
Work is sized to the system, not to a package. A single assistant feature behind a login is a different scope from an agent with tool access to production systems, and the report says which one was examined.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
Testing and adversary simulation are carried out only with signed authorization, to a scope agreed in writing.
Investigation and forensic work is delivered with appropriately licensed partners where the law requires it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
What does an AI security assessment cover?
An assessment reads the system as built — prompts, tools, retrieval, identity and output handling — and reports what an attacker can reach through it, against the OWASP Top 10 for LLM Applications 2025.
Will you test our AI application?
Testing and adversary simulation are carried out only with signed authorization, to a scope agreed in writing.
Who signs off an AI system at the end?
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs.
Start with the system you already have
Describe what is running and what it can reach; the reply says what a scope for it would look like and what it would produce.
What this covers
Each page below says what the work is, what it produces, and what it does not cover.
Assess
AI security assessment
A review of the AI systems you are already running, against all ten OWASP LLM categories, with findings ranked by what an attacker can actually reach.
AI threat modelling
The design-review engagement: decompose the AI system, enumerate what crosses each trust boundary, and leave a threat model your architects maintain.
Shadow AI and vendor risk
Two halves of one question: which AI is already in the estate, and what the suppliers behind it do with what you send them.
Establish
Secure AI environment
The environment work itself: where the gateway sits, what the guardrails check, which credentials exist, and what is logged so an incident can be reconstructed.
RAG and vector security
Whether the assistant can retrieve what the person asking is not allowed to read — the tenancy boundary, the permission inheritance and the corpus itself.
AI supply chain security
Where the model came from, what went into it, and what can tamper with it between a download and production.
Secure model fine-tuning
What goes into a model, who can change it, and what has to be true before a fine-tuned model ships.
Test
LLM penetration testing
Human-led adversarial testing of a named application, against all ten OWASP LLM categories, under signed authorization and a scope agreed in writing.
Agentic AI and MCP security
An agent with tools takes actions, not just text. What it can reach, whose authority it borrows, and where a person has to be in the loop.
AI-generated code security
Two risks, not one: what the generated code does to your controls, and what the coding agent itself can reach in your repositories and pipelines.
Operate
AI monitoring and detection
The AI went to production and detection did not follow. Coverage gaps, detection use cases, and a tabletop that checks whether they would fire.
Deepfake fraud controls
Controls built on the assumption that the voice and the face are fake: out-of-band verification for every instruction that moves something irreversible.
Respond
AI incident readiness
Planning and exercising, done before anything happens: AI runbooks, the telemetry an investigation would need, and a tabletop that tests both.
Govern
AI governance readiness
The artifact a board, a regulator or a customer will accept: an inventory, a control set, a gap review against your chosen framework, and the evidence behind it.