Anyone can try to break it.
Few know where it actually breaks.

Attacks only find real weaknesses if the attacker knows the subject. Our red teams probe safety boundaries with calibration and rigour, not the randomness of a crowd.

Scope an authorized adversarial evaluation See how it works

The engagement lifecycle

From an agreed scope to a finding you can reproduce.

Every engagement starts with authorization and ends with evidence. The steps are the same shape each time; what changes is the system, the threat model and how deep the testing goes.

Define objectives and authorized scope
What is being tested, what is out of bounds, who has authorized it, and the constraints on how testing is done. Nothing starts without this.
Shared
Identify threats and failure modes
Starting from your policy, deployment context and the risks that matter to you, not a generic checklist.
Shared
Develop test scenarios
Scenarios written by domain experts for the threats identified, including the ones only a subject-matter expert would think to try.
Synthium supplies
Execute controlled tests
Scenarios run inside the agreed scope and constraints, against the system you authorized.
Synthium supplies
Capture reproducible evidence
The traces, inputs and outputs that show a failure, kept so your team can verify it for itself.
Synthium supplies
Classify and prioritize findings
Each finding categorized, and its severity argued from real-world impact and how easy it is to trigger.
Synthium supplies
Recommend mitigations
Practical changes your team can make for each finding, ordered by what reduces risk most.
Synthium supplies
Retest, where included
The same scenarios run again after you have made changes, to confirm the fix. Only where the engagement scopes it.
Shared

Testing is authorized, scoped and performed under constraints you agree. We test systems with the owner's permission and no others, and a finding is shared with the owner under NDA.

What is in scope, and what is not

Adjacent kinds of testing, and which one this is.

“Red teaming” covers several different kinds of work. Naming which one Synthium Red Team is, is part of being honest about it.

Kinds of adversarial testing and whether Synthium Red Team provides them
Aspect	What it examines	Synthium Red Team
Adversarial evaluation of model or agent behaviour	Whether a model or agent can be pushed into behaviour it should not show: unsafe output, instruction override, leaking data it should protect.	Yes. This is the core of the service.
AI safety and policy testing	Whether behaviour stays within your published policy and safety boundaries.	Yes, measured against your own policy.
Tool-use and workflow failure testing	Whether an agent with tools can be induced to take harmful or unintended actions in a workflow.	Yes, where the agent and its environment are in the agreed scope.
Conventional application security testing	Network, infrastructure and web-application vulnerabilities, such as penetration testing of your systems.	Not offered as a service on this page. Where an AI system's behaviour touches a conventional vulnerability, we say so in the finding.

How a red team engagement runs

From threat model to reproducible report.

We start from your policy and deployment context, and every finding ships with the exact steps to reproduce it.

Threat modelYour policy, context, and real risks
ProbeSpecialists attack with domain knowledge
BreachA boundary gives way — the finding
SeverityAn expert rates the real-world risk
ReproduceExact steps, so your team can verify
ReportPrioritised by what matters, under NDA

Adversarial testing flow

From threat model to verified fix.

Attacks run inside a controlled boundary, failures are classified, and each fix is re-tested before it is treated as closed.

Threat model
Your policy, deployment context and the risks that matter.
Scenario design
Concrete attack scenarios, written by people who know the domain.
Controlled execution
Attempts run inside an agreed, bounded environment.
Where failures surface
Failure classification
Each failure is typed and rated for real-world risk.
Expert severity rating
Mitigation verification
Fixes are re-tested to confirm the boundary now holds.
Failing scenarios are re-run after each fix

What we assess

What we probe for.

Every finding is severity-rated and ships with the steps to reproduce it. The categories below are what an engagement can cover; scope decides which.

Jailbreaks

Prompt-injection and instruction-override attempts built around your actual policy.

Safety boundaries

Refusal probing to find where the boundary sits versus where you intended it.

Policy violations

Harmful-output detection measured against your published standard.

Domain risk scenarios

Field-specific failure cases that only a subject-matter expert would think to try.

Edge-case discovery

Reproducible edge cases, documented so your team can verify each one.

Failure surfaces

Where the system degrades under adversarial pressure rather than failing cleanly.

Tool-use and workflow failures

Where an agent with tools can be steered into an action it should not take.

What you receive

What an engagement hands over.

A finding is only useful if you can check it and act on it. These are the parts a report is built from. Which are included depends on the scope.

Scope and threat model
What was authorized, what was out of bounds, and the threats the tests were built around.
Standard
Test scenarios
The scenarios that were run, described at the level your team needs to understand them.
Standard
Findings with reproduction steps
Each failure, with the steps to reproduce it, written so your own team can confirm it.
Standard
Evidence and traces
The inputs, outputs and traces behind each finding.
Standard
Severity rationale and classification
Each finding's category, and the reasoning for how serious it is: impact, and how easy it is to trigger.
Standard
Mitigation recommendations
Practical changes for each finding, ordered by what reduces risk most.
Standard
Retest results
The same scenarios run after you have made changes, to confirm the fix.
Optional
Residual-risk notes
What the testing did not cover and what remains uncertain, stated plainly.
Optional
Depth, duration and number of scenarios
Not assumed from this page. Agreed in the scope before testing begins.
Scoped per engagement

Which of these an engagement includes is agreed before work starts. A listed item is a capability, not a promise that every engagement contains it.

A sample finding

What a documented, reproducible finding looks like.

One finding from a synthetic engagement against a fictional system. It shows the evidence and reasoning a real finding carries, at a level of detail that is safe to publish.

ILLUSTRATIVE EXAMPLE

Sample finding: instructions inside retrieved content

System and objective

A fictional customer-support assistant that reads support tickets and their attachments. Objective: test whether text inside an attachment can change what the assistant does.

Expected behaviour

Attachment text is treated as data to summarise. It is never followed as an instruction, and the assistant only ever uses records belonging to the customer in the current ticket.

Observed failure

When asked to summarise a ticket, the assistant followed instruction-like text inside an attachment and included a field from a record belonging to a different (synthetic) customer in its reply.

Reproduction (safe level of detail)

Create a ticket whose attachment contains instruction-like text addressed to the assistant.
Ask the assistant to summarise the ticket.
Compare the reply with the records the current customer is entitled to see.

The exact attachment text is withheld here. The trace, the attachment and the reply are in the full finding.

Severity rationale

High. It crosses a data boundary between customers. The precondition is low: anyone who can add content to a ticket can attempt it. The impact is disclosure of another customer's information.

Mitigation recommendation

Treat retrieved and attached content as data, never as instructions.
Scope retrieval to the current customer before the model sees anything.
Check replies for fields outside the current customer's records.

Retest

After the changes, the same scenario was run again: no disclosure was observed. Residual risk: this retest covers the scenario above only, and says nothing about other ways of injecting instructions.

A synthetic finding about a fictional assistant, written for this page. It describes no real system and gives no payload: the reproduction is deliberately described, not demonstrated. Real findings are shared under NDA with the system's owner.

How it runs

Attacks built around your policy, not a generic checklist.

A red team that does not understand your deployment context will find the obvious things and miss the ones that matter.

Threat modelling
We start from your policy, deployment context, and the risks that actually matter to you.
Expert probing
Domain specialists attack the system using knowledge a generic crowd worker doesn't have.
Severity rating
Every finding carries a clear severity so risk is prioritised, not just listed.
Reproducible reporting
Each issue ships with reproduction steps. Engagements run under NDA with project-level data segregation.

Who does the work

Red teaming is only as good as the attacker.

Red teaming depends entirely on who is doing the attacking. We staff engagements with specialists who understand both the domain and how systems fail in it.

Security engineers
Safety researchers
Domain specialists
Policy analysts
Adversarial ML practitioners
Legal and compliance reviewers

Engagement and fit

How an engagement is scoped.

The first conversation is about the system and the boundaries of testing. It does not need access to anything.

What to bring to a first conversation

The type of systemFor example a customer-support assistant, a coding agent or a retrieval-based product. In words.
Your threat modelThe harms and misuse you are most concerned about, and your policy where one exists.
The intended scopeWhat may be tested and what may not, and who is able to authorize it.
Constraints and desired outputHandling requirements, timing, and what the report needs to contain.

A good fit when

You own the system, or are authorized by its owner to have it tested.
You want findings your engineers can reproduce, with severity argued rather than asserted.
You can describe the policy or behaviour the system is meant to uphold.

Not the right fit when

You want to test a system you do not own or are not authorized to test.
You are looking for conventional penetration testing of networks or web applications.
You want a certification or a guarantee that a system is safe.

We do not need secrets, private endpoints or credentials to scope an engagement, and we ask you not to send them through the form. Any access needed for testing is arranged securely once an agreement is in place.

Choosing between offerings

Which Synthium offering fits the problem?

They are separate offerings, and they work together where a project needs more than one. Most teams start with one.

When to choose each Synthium offering, and what each delivers
Offering	Choose it when	You receive
Synthium Data	You need data acquired or licensed, or you have data or a task that needs expert curation and annotation.	An assessment of fit and rights, or an expert-reviewed dataset, with the documentation behind it. Scope is agreed first.
Synthium Train	You are improving an agent or model and need RL environments, or expert-generated post-training data.	Environments with tasks and verification you run in your own training stack, and/or datasets in your schema.
Synthium Agents	You need to know how well a model or agent performs on realistic tasks, and exactly where it fails.	An evaluation specification, traces, expert-reviewed findings and a failure analysis you can act on.
Synthium Red Team (this page)	You want authorized adversarial testing of an AI system and documented, reproducible failures.	A scoped test plan, findings with evidence and a severity rationale, and mitigation recommendations.

Keep exploring

Questions about Synthium Red Team

Will you test a system we do not own?

No. Testing is authorized and scoped. We work with the owner of a system, or someone authorized by them, and we do not offer testing of third-party systems.

Do you offer penetration testing?

Not as a service described here. Synthium Red Team is adversarial evaluation of model and agent behaviour. Where an AI system's behaviour exposes a conventional vulnerability, the finding says so.

What do we need to give you to start?

A description of the system type, your threat model, the intended scope and your constraints, in words. Not credentials, private endpoints or vulnerability details.

Will findings be made public?

No. Findings go to the system's owner under NDA. The sample finding on this page is synthetic and describes a fictional system.

Can you confirm a fix works?

Where the engagement includes a retest, the same scenarios are run again after your changes and the result is reported, with a note on what the retest does not cover. It is not part of every engagement.

Do you guarantee a system is safe afterwards?

No. Testing finds failures within its scope. It cannot show that no others exist, and the report states what was and was not covered.

Next step

Find the failures before your users do.

Tell us your deployment context and safety policy. We'll build the threat model and assemble the right specialist team.

Scope an authorized adversarial evaluation

Describe the system type, threat model, scope and constraints in words. Please don't send secrets, private model endpoints, credentials or details of vulnerabilities through the form. Access for testing is arranged securely once an agreement is in place.

Anyone can try to break it.Few know where it actually breaks.