ai and llm security

AI and LLM security,
tested as a system, not just a model.

Assess the application, retrieval layer, tools, data flows, permissions and human approvals that turn model output into real-world impact.

what this engagement answers

An AI feature is an application system with probabilistic behavior. Risk emerges from the model, system prompt, retrieval sources, output consumers, connected tools, identities, data and user experience.

Testing therefore follows trust boundaries and consequences. It explores direct and indirect prompt injection, data exposure, unsafe output handling, excessive agency, resource abuse and how monitoring or human approval contains failure.

Primary baselines: OWASP Top 10 for LLM Applications 2025 and OWASP GenAI Security guidance.

scope

What is reviewed.

Final scope is confirmed in writing before work starts. Testing is performed only on authorised assets and within agreed rules of engagement.

01

Prompt injection

Direct, indirect and stored instruction attacks across user input, documents, web content and connected systems.

02

Sensitive information

System prompts, secrets, personal data, proprietary content, embeddings, logs and cross-user leakage.

03

Agent permissions

Tool allowlists, identity, least privilege, approval gates, transaction limits and confused-deputy paths.

04

Retrieval and data

Ingestion trust, document authorization, poisoning, source attribution and tenant boundaries.

05

Output handling

Code, markup, links, commands and downstream automation that may trust generated content.

06

Abuse and observability

Cost exhaustion, model denial of service, unsafe use cases, telemetry, incident response and red-team coverage.

evidence

What you receive.

01
AI attack-path reportSystem-specific scenarios linking input, model behavior, data, tools and business consequences.
02
Guardrail findingsEvidence showing where permissions, validation, isolation or human approval failed or contained the attempt.
03
Control design backlogApplication, identity, data, monitoring and product changes ordered by consequence and feasibility.
04
Retest recordVerification of the highest-risk fixes using the same scenario and success criteria.

// how it works

A controlled, decision-ready process

The engagement turns technical observations into owned decisions. Critical issues are escalated through the agreed channel, not left waiting for the final report.

01

Map

Document components, data, retrieval sources, tools, identities, users and consequences.

02

Threat-model

Choose abuse cases and acceptance criteria relevant to the actual product.

03

Exercise

Test prompt, data, permission, output and monitoring boundaries under agreed controls.

04

Harden

Prioritise deterministic controls around the model and reduce unnecessary agency.

05

Retest

Repeat critical scenarios and record residual risk.

buyer questions

What teams usually ask.

Is this only jailbreak testing?

No. Jailbreaks are one input class. The assessment also covers data access, retrieval, tool permissions, output handling, monitoring and business consequences.

Can an LLM be made perfectly secure?

No single guardrail eliminates probabilistic failure. Risk is reduced through layered application controls, least privilege, isolation, approvals, monitoring and tested response.

Do you test third-party model providers?

The assessment focuses on the system you control and its integration. Provider configuration and contractual boundaries can be reviewed without claiming access to the provider’s internal model.

Methodology and primary references

These sources define the baseline. The exact checks are selected for the architecture, risk, data flows and engagement objective, not copied as a generic checklist.

Can your AI feature take actions or reach private data?

Describe the model, retrieval sources, connected tools, user roles and highest-consequence action. Keep credentials and sensitive prompts out of the form.