Replace assumptions with observed behaviour
See how your application responds to agreed misuse scenarios, so release decisions reflect evidence about the controls you depend on.
2-sec AI practice / AI LLM and Prompt Testing
See How Your AI Holds Up Under Manipulation
Find out whether crafted prompts and untrusted content can push your AI beyond its intended boundaries.
2-sec tests AI applications against realistic manipulation attempts, giving you evidence of what holds up, where controls fail and what to strengthen before you rely on them.
Part of the 2-sec AI practice for securing AI systems and data through AI governance.
Realistic scenariosTests shaped around your AI use
System boundariesPrompts and connected controls
Traceable evidenceFindings your teams can investigate
Practical prioritiesA clear route from finding to fix
The assurance gap
Good answers do not prove your AI can resist misuse
An assistant may perform well in routine use while behaving differently when someone deliberately tries to redirect it. Testing helps you understand that gap before it affects customers, information or connected workflows.
Identify failures that matter in practice
Connect unexpected responses to what the system can access or do, distinguishing an inappropriate answer from a meaningful security exposure.
Give teams a clearer route to remediation
Provide technical owners with the conditions, evidence and priorities they need to investigate weaknesses and make targeted changes.
What Is LLM and Prompt Testing
LLM and prompt testing evaluates how applications built on large language models respond to adversarial inputs. It examines whether manipulation can override intended behaviour, expose protected information or trigger actions outside agreed boundaries.
Adversarial Inputs
Uses deliberately challenging prompts and untrusted content to examine whether an AI application can be redirected away from its intended behaviour, including across multiple exchanges.
System Boundaries
Examines the application around the model, including information access, user permissions, connected tools and approval controls that determine what a manipulated response could expose or trigger.
Observed Behaviour
Compares actual responses and downstream effects with expected boundaries, recording test conditions and supporting evidence so findings can be investigated and their limitations understood.
Contextual Assurance
Interprets results against the tested use case, configuration and business impact. Conclusions apply to the assessed conditions and inform remediation and further testing as the system changes.
What we test
Challenge the paths that could lead to a real security failure
The scope follows your application, user roles, data sources and integrations. We agree relevant scenarios and expected behaviour before testing begins.
Prompt injection and instruction override
Test whether crafted user inputs can redirect the application away from its intended task or conflict with the rules it should follow.
Instructions hidden in external material
Examine whether retrieved documents, uploaded files or other supported content can influence the assistant as instructions rather than information.
Data disclosure and access boundaries
Test whether manipulation can expose restricted information or cross user boundaries, using agreed roles and controlled test data.
Tool use and approval controls
Where the application can call tools or trigger workflows, test whether it stays within permitted actions and honours required approvals.
Jailbreaks and conversation persistence
Assess attempts to bypass behavioural restrictions, including whether boundaries remain effective as context builds across multiple exchanges.
Manipulated outputs and system responses
Where included, examine how connected components handle adversarial outputs and whether validation prevents unintended downstream effects.
Testing is authorised and scoped to agreed environments. Supplier permissions, test data, operating limits and stop conditions are established before work starts.
Direct and indirect injection are recognised attack categories in the OWASP guidance on prompt injection.
What you receive
Evidence your leaders can assess and your engineers can use
The engagement produces a record of the tested scope, observed outcomes and recommended actions, with limitations made clear.
An accessible findings summary
A business view of the most significant findings, their implications and the decisions needed on deployment, restrictions or further work.
A documented test and findings record
The scenarios attempted, relevant configuration, observed responses and supporting traces, with reproduction steps and repeatability limits where applicable.
A practical improvement plan
Prioritised recommendations tied to the observed weaknesses, with a proposed approach to validating fixes. Implementation and retesting are agreed in scope.
Illustrative test scenario
A retrieved document tries to redirect an internal assistant
A controlled test document contains instructions that conflict with the intended task. Testing observes whether the assistant follows those instructions, attempts access to restricted test information or triggers a connected action.
The evidence records the input route, expected boundary, actual response and any downstream effect. This is an example of the testing approach, not a reported client finding.
How we work
Test against the way your AI is actually deployed
A focused engagement connects realistic attack scenarios with your business context and the controls you expect to protect it.
Agree the boundaries
Identify the application, model configuration, user roles and integrations. Confirm authorisation, environments, test data, success criteria and operating limits.
Design the scenarios
Map relevant input routes and trust boundaries. Select manipulation attempts that reflect the tasks, information and actions available in your deployment.
Run and document tests
Exercise the agreed scenarios, capture responses and investigate observed failures. Record relevant conditions and variability so findings can be interpreted accurately.
Review the evidence
Walk through findings and priorities with your team. Agree next actions and define any follow-on remediation or retesting needed to check changes.
From findings to stronger controls
Strengthen the controls around the model
Testing can reveal weaknesses in how prompts, permissions and connected systems work together. Recommendations follow the observed failure and the level at which it needs to be addressed.
Tighten what the application can access
Review data permissions and retrieval boundaries where testing reveals access that exceeds the intended user or business purpose.
Constrain what the application can do
Address tool permissions, output validation and approval checks where model behaviour could lead to an unintended action.
Check changes against the original failure
Agree targeted retesting after fixes and review when model, prompt, data or integration changes justify further evaluation.
Testing provides evidence for the agreed scope and configuration at the time of assessment. It does not guarantee resistance to every future attack.
The wider AI practice
Bring technical evidence into AI governance
AI LLM and Prompt Testing checks how your application behaves under manipulation. AI Risk Assessment helps establish the wider exposures, while AI Policy Development defines the rules people should follow.
Use testing findings to inform governance decisions, risk ownership and control improvements. For organisations pursuing ISO 42001, this evidence can support wider management system work without constituting certification.
A useful starting point when
- You are preparing to launch an AI assistant or customer chatbot.
- You are connecting an LLM to internal documents or business tools.
- You need evidence for a deployment or supplier assurance decision.
- You have changed a model, system prompt or integration.
- You need to investigate unexpected AI behaviour.
Questions before you start
Know what to expect from AI testing
The initial discussion establishes what you need to validate and what access is available.
Can you test an application that uses a third party model
Yes, subject to authorisation and supplier terms. The scope can focus on your application, configuration, data access and integrations. Testing a deployed application does not imply access to the provider’s underlying model or infrastructure.
Is this the same as ordinary penetration testing
The focus here is manipulation of AI behaviour and the consequences for the surrounding application. Conventional web, API and infrastructure testing examines other weaknesses. The two can be combined where the agreed scope calls for both.
Do we need to provide source code
Access requirements depend on the testing depth. An engagement may use the application interface and agreed test accounts, while more detailed investigation may need configuration, logs or source code. We establish those requirements during scoping.
Can testing be carried out before launch
Yes. A representative test environment can help identify weaknesses before release. It should reflect the intended model configuration, permissions, data flows and integrations closely enough for the results to be useful.
Will a successful test prove our AI is secure
A successful outcome means the tested boundary held under the recorded conditions. It does not prove immunity to every manipulation attempt. Reports distinguish observed outcomes, untested areas and limitations.
Does the engagement include fixes and retesting
The proposal identifies what is included. Remediation support and retesting can be agreed as part of the engagement or as follow-on work, with clear responsibilities and validation criteria.
How long does testing take and what does it cost
This depends on the number of applications, roles and integrations, the range of scenarios and the depth of evidence required. We agree scope, deliverables, timing and cost before testing starts.
Your next step
Put your AI boundaries to the test
Tell us what your AI does, what it can access and which behaviours you need to trust. We will help define a testing engagement that gives your team useful evidence and a clear next step.
Discuss Your AI Testing Needs →
Start with one application or a planned deployment.