Direct & indirect prompt injection
Challenge instructions arriving through chat, retrieved pages, uploaded documents and tool responses.
Can untrusted content redirect the workflow, expand authority or cause an unintended disclosure?
Services / AI Safety & Reliability
AI red teaming.Challenge the boundaries.
We assess how an adversary could manipulate your AI application, expose protected information or misuse connected tools. Authorised testing, verified evidence and practical fixes for the boundaries that matter.
Written authorisation. Controlled impact. Actionable findings.
The business case
What happens when the input is hostile?
AI applications increasingly read external content, retain context and act through business systems. A useful assessment follows those connections to understand what a malicious input can actually reach, not merely whether a model can be persuaded to say something unexpected.
When to assess
Before exposing private knowledge or privileged tools, after material changes to permissions or agent workflows, or when a pilot reveals suspicious behaviour. Existing applications can also be assessed against a clearly defined threat model.
What the result provides
A scoped view of attack paths, verified weaknesses, reachable impact and prioritised remediation. It is evidence for engineering and risk decisions, not a promise that the system is attack-proof or a substitute for broader security work.
Threat scenarios
Test the paths an attacker could use.
These are illustrative assessment areas, not claims about customer incidents. We select relevant scenarios based on your application's assets, authority and exposure.
Sensitive data exposure
Probe retrieval, conversation memory, cached responses and tool results using authorised test records.
Can one user obtain another user's data, protected documents or secrets the application should never expose?
Tool misuse & excessive agency
Test ambiguous instructions, manipulated parameters and attempts to bypass approval or permission checks.
Can the agent perform an unauthorised operation or claim success without a confirmed action?
Cross-session & multi-agent attacks
Examine how state, messages and delegated work move across sessions or collaborating agents.
Can a lower-trust participant contaminate shared context or exploit a more privileged agent?
Unsafe output & workflow abuse
Assess prohibited requests, misleading claims and risky downstream handling of generated content.
Are refusals and escalation appropriate, and is generated output validated before another system consumes it?
Resource & reliability abuse
Assess bounded long-context requests, recursive tool behaviour and repeated attempts within agreed limits.
Can an input produce unbounded work, unexpected cost or a failure that leaves the system in an unsafe state?
Boundary-led testing
Trace the probe. Verify the consequence.
Controlled inputs approach an application through different trust boundaries. We inspect whether a probe is rejected, causes a disclosure or reaches a tool, and capture evidence for review. The diagram illustrates the assessment model, not a guarantee that every attack will be blocked.
01
Define the starting position
Establish the attacker's permitted access and the target boundary. Use controlled records, accounts and tools so the test has an interpretable, safe outcome.
02
Observe the whole path
Inspect relevant prompts, sources, tool calls and side effects where authorised. Distinguish an alarming response from a confirmed violation of data or action permissions.
03
Record and retest
Preserve minimal reproduction evidence, explain impact and propose a fix. Retest the original case and meaningful variants, then keep confirmed cases in a regression suite.
Threat modelling
Start with assets, access and consequences.
We map the application rather than treating the model as the whole system. The useful question is which attacker-controlled inputs can reach sensitive data, privileged tools or consequential outputs.
Trust boundaries
Identify users, tenants, document sources, model calls, memory, tools and external services. Distinguish information that may inform a response from information allowed to authorise an action.
Attacker capabilities
Define realistic starting access: an anonymous visitor, a logged-in user, a document contributor or a compromised lower-trust source. Test those assumptions explicitly.
Impact & priorities
Prioritise disclosure, unauthorised actions, deception and operational disruption according to your workflow. A jailbreak with no reachable asset is different from a confirmed business impact.
Scope & visibility
Agree black-box, grey-box or code-informed testing based on available access. Document what cannot be verified, including third-party model internals and systems outside your authority.
Rules of engagement
Authorised testing. Bounded impact.
Before testing, we agree written authorisation, target systems, allowed techniques and operating limits. Ownership of an application does not automatically authorise testing every connected provider or customer environment.
Targets & exclusions
Specify environments, accounts, endpoints, integrations and prohibited actions. Obtain any required third-party permissions; keep unrelated infrastructure and accounts out of scope.
Controlled fixtures
Prefer staging, sandbox tools, synthetic records and seeded canary values. Simulate consequential actions rather than sending real payments, destructive changes or unsolicited messages.
Traffic & spend limits
Set request rates, concurrency, time windows and cost budgets. Bound adaptive testing and resource-abuse simulations rather than running an uncontrolled attack campaign.
Stop & escalation procedures
Name operational contacts, define immediate stop conditions and agree how critical findings are communicated. Unexpected exposure or impact is handled through the agreed incident process.
Assessment methods
Automation for breadth. Human investigation for depth.
Automated probes help explore known failure families, while manual investigation follows context-specific attack paths. We verify findings against the actual application contract instead of equating a provocative model response with a confirmed vulnerability.
Single-turn & multi-turn probes
Test direct attempts, gradual context manipulation and changes in intent within an agreed scope. Repeated trials help distinguish reproducible weaknesses from isolated behaviour.
Indirect-source testing
Use controlled documents and tool responses to examine instruction-following across trust boundaries. Trace whether attacker-controlled material reaches sensitive actions or outputs.
White-box-informed review
Where authorised, inspect prompts, tool contracts, retrieval filters and state handling to guide tests. Code review and runtime evidence complement each other.
Benign controls
Retain legitimate requests beside adversarial cases. A defence that blocks every user or breaks useful workflows is not a satisfactory fix; assess false refusals and degraded completion.
Application boundaries
Follow the attempted attack through the system.
We inspect retrieval, model output, tool requests and side effects where visibility permits. A refusal message is not sufficient if a tool already performed the prohibited action.
Retrieval & isolation
Test permission filters, tenant boundaries, revoked access and caching. Use controlled records to verify that sensitive context never reaches an unauthorised model request.
Tool authority
Check identity scope, typed arguments, business rules and approval enforcement at execution. Prompts and tool descriptions must not be the only protection.
Memory & delegation
Test whether persistent context or agent handoffs can introduce unauthorised instructions or data. Verify that delegation does not silently inherit excessive privileges.
Output consumption
Assess how applications render, parse or execute generated output. Validate the boundary to downstream systems and distinguish AI-specific weaknesses from conventional web or API issues.
Findings & evidence
A finding should be reproducible and actionable.
We report what was attempted, what happened and which boundary failed. Results include the tested configuration and limitations so your team can interpret the evidence without false certainty.
Reproduction & trace
Document prerequisites, controlled inputs, relevant outputs and confirmed side effects. Preserve application, model, prompt and source versions where available, with sensitive evidence redacted.
Severity & confidence
Assess reachable impact, required access and observed reliability. Separate suspected behaviour from confirmed exploitation, and show repeat counts rather than unsupported universal success rates.
Coverage & omissions
Provide an attack-surface map, tested scenarios and exclusions. Framework categories are organising aids, not proof that every vulnerability in a category has been assessed.
Decision-ready reporting
Give engineering teams remediation detail and business owners a concise risk summary. Critical issues follow agreed notification procedures rather than waiting for the final report.
Remediation & retesting
Fix the authority boundary, not just the wording.
A stronger system prompt can be useful, but it is rarely sufficient protection for a privileged workflow. We help prioritise structural fixes and verify that they address the observed failure without breaking legitimate use.
Reduce reachable impact
Scope credentials, minimise retrieved data, narrow tool capabilities and separate untrusted content from control logic. Require accountable approval for consequential actions.
Validate outside the model
Enforce permissions, schemas, business rules, rate limits and confirmed action states in application code. Treat model-generated arguments and output as untrusted.
Retest & generalise
Reproduce the original case against the fix, then test relevant variants and benign controls. Track unresolved findings and accepted residual risk separately.
Regression & response
Turn confirmed failures into controlled regression cases. Agree pause, rollback, incident triage and future reassessment after changes to models, sources, tools or permissions.
Tools & frameworks
A toolkit shaped by the threat model.
These are options we can evaluate, not a mandatory bundle. We select tools according to supported targets, operating limits and data-handling requirements, then combine their output with application-specific investigation.
Adversarial test tooling
Microsoft PyRITpromptfoo red teaminggarak
Choose supported probes and orchestration for the assessment. Automated output needs review; tool coverage is not a complete assessment or a safety guarantee.
Scenario & contract tests
Python / pytestTypeScript / VitestPlaywrightCustom tool fixtures
Reproduce complete workflows, permission boundaries and confirmed side effects in controlled environments.
Trace & evidence capture
OpenTelemetryLangfuseLangSmithVersioned test artefacts
Record enough evidence to understand an attack path with agreed access, redaction and retention. Hosted tools require approved processing terms.
Threat taxonomies
OWASP Top 10 for LLM ApplicationsMITRE ATLASNIST AI RMF
Use relevant threat categories and risk practices to organise coverage. These references do not confer certification or establish compliance by themselves.
Safe test environments
DockerSandbox APIsSynthetic datasetsCI regression suites
Isolate tools and accounts, use canary data and bound spend. Keep proof-of-concept artefacts private and scoped to remediation.
Model providers and testing frameworks have their own terms and limitations. Any generated attack content, evidence storage or external judging path must fall within the agreed authorisation and processing rules.
Delivery & outputs
From an attack surface to a remediation plan.
We work with your engineering and security owners to agree a safe scope, investigate credible threats and leave usable evidence. Testing and remediation responsibilities are explicit, including who accepts any unresolved risk.
- 01
Agree scope & authorisation
Map owners, environments, integrations, attacker access and permitted methods. Set safety limits, data rules and emergency contacts.
Output: Written rules of engagement and an authorised target inventory.
- 02
Model threats & prepare fixtures
Identify assets and trust boundaries, prioritise credible attack paths and prepare controlled records and tool substitutes.
Output: A threat map, coverage plan and safe test setup.
- 03
Probe & verify
Combine bounded automation with manual investigation. Reproduce suspected findings and inspect downstream effects where visibility permits.
Output: Verified evidence, coverage notes and early critical notifications.
- 04
Prioritise & remediate
Explain root causes and business impact, recommend controls and work with your team on agreed fixes.
Output: A prioritised findings report and remediation plan.
- 05
Retest & hand over
Validate agreed fixes, preserve regression cases and document unresolved risks, ownership and reassessment triggers.
Output: Retest results, controlled test artefacts and an operating handover.
A bounded first sprint
Start with a paid two-week sprint and one agreed goal, without a required long-term commitment. A first scope can map threats and assess selected critical paths; a comprehensive assessment, fixes and retesting may require further work.
What your team brings
A system owner, written authorisation, architecture and access constraints, controlled test accounts and contacts for critical escalation. We also need a safe approach to connected tools and sensitive data before testing starts.
Scope & limitations
Useful evidence without false assurance.
The assessment reflects the application configuration, access and attack families tested during the engagement. Unseen techniques, provider changes and future integrations can alter the risk. We state exclusions and confidence alongside findings.
Not just a jailbreak score
A model refusal rate does not capture data isolation or action integrity. We prioritise real boundary failures and business impact, and report the tested conditions and repetition rather than an unexplained overall security percentage.
Keep the knowledge with your team
Your code belongs to you from day one. We agree access to reports, controlled test artefacts and regression cases, subject to data rights and third-party licences. Ongoing retesting and incident support are scoped separately.
Related engineering & guides
Connect adversarial findings to daily reliability.
Explore evaluation and practical guidance for secure agent design and operational evidence.
Questions before testing
The practical details.
How is red teaming different from AI evaluation?
Evaluation measures whether the system does its intended job. Red teaming deliberately explores how an adversary could make it violate boundaries or cause harm. They complement each other: confirmed attack cases should become regression tests alongside normal quality evaluations.
Is this a penetration test or a security certification?
This service focuses on adversarial behaviour and trust boundaries in AI applications. Conventional web, network and infrastructure penetration testing may require a separate specialist scope. The assessment is not a certification, legal opinion or proof of compliance.
Can you test an application built by another team?
Yes, with written authorisation and agreed access. Black-box testing can reveal externally observable weaknesses; deeper permission and action-path testing may require code, traces or controlled tool access. We state those limitations in the report.
Do you attack production systems?
Controlled staging and sandbox environments are preferred. Any production assessment requires explicit approval, narrowly defined methods, safe fixtures and stop procedures. We do not assume permission to test external providers, unrelated accounts or live destructive actions.
Will this prove the application is safe?
No. It provides evidence about selected attack paths under a defined configuration and scope. Models, integrations and user behaviour change, and untested attacks may remain. Findings, exclusions and residual risks are documented explicitly.
What if an automated tool says an attack succeeded?
We verify whether the result crossed a real application boundary and what impact was reachable. Automated judges can misclassify refusals, harmless output or partial failures. Findings distinguish model behaviour from confirmed data disclosure or unauthorised action.
How do you handle sensitive evidence?
We agree access, storage, retention and approved processing paths before testing. Synthetic or canary data is preferred, and reports minimise sensitive content. Unexpected exposure is handled through the agreed escalation process, not copied into uncontrolled artefacts.
How do we start and what is included?
Start with a paid two-week sprint, one agreed goal and no required long-term commitment. A bounded first scope can cover threat mapping and selected attack paths; a comprehensive assessment and remediation may need further work. Your code belongs to you from day one, while evidence access and third-party licences follow agreed terms.
Start with the exposed boundary
Bring the application.
Let's challenge its assumptions.
Tell us what the AI can access, what it can change and which outcomes concern you. We'll define an authorised assessment and a sensible first scope.