Syntony / Services / Red teaming / AI cybersecurity

Red teaming · Security

Cybersecurity of AI products Security testing for systems with a model inside

AI products add new attack surface to familiar infrastructure: model endpoints, prompts, retrieval stores, plugins and the identities that tie them together. We test that surface with a security focus, and we brief leadership on how advanced models change the organization's cyber risk.

Discuss your system Enter the 3D environment

Track record: Past engagements in technology and banking, including advice to a leading global bank on cyber risk from advanced AI models.
Who runs it: Core team with security specialists from the Trusted Red Team Network, including top performers on HackerOne and Hack The Box.
Format: Scoped security testing under written authorization, plus briefings for risk and leadership teams.

First-person walkthrough

Security operations center

Walk the site in first person and run a red team test at each station: inspect, disrupt, limit, retest. 4 stations, about five minutes.

Model API
Vector store
Identity provider
Security operations

Enter the environmentKeyboard and mouse · Touch · VR headsets

Illustrative environment

01 / What we test

Where AI changes the security picture

Model endpoints and keys
Exposed APIs, leaked keys, missing rate limits and endpoints that answer more than they should.
Retrieval and data stores
Vector stores and indexes that return another tenant's data or accept poisoned entries.
Plugins, tools and integrations
Third-party connectors with broader access than the feature needs.
Identity and access
Service accounts, tokens and delegated permissions that let a model act as someone it shouldn't.
Output handling
Model output passed into browsers, databases or shells without checks.
Logging and monitoring
Whether attacks on the AI layer show up in your security tooling at all.

See an example campaign plan

A fictional plan for a bank's customer-facing assistant. Each engagement sets its own rows, phases and depth.

Example campaign planFictional plan for illustration

Example campaign plan: attack families by phase
AI layer
	Architecture review	Pre-launch test	Launch	Quarterly retest
Model API and keys	Covered	Primary focus	Light check	Covered
Retrieval store isolation	Covered	Primary focus	Light check	Primary focus
Prompt injection into tool use	Light check	Primary focus	Covered	Primary focus
Surrounding infrastructure
Identity and delegation	Primary focus	Covered	Light check	Covered
Output into downstream systems	Light check	Primary focus	Light check	Covered
Detection and logging	Covered	Covered	Primary focus	Covered
Leadership
Board and risk briefing	Primary focus	Not applicable	Light check	Covered

Primary focus
Covered
Light check
Not applicable

02 / In depth

How these failures work, and how we test for them

Public research, standard frameworks and a simplified look at our method. Working tools, attack libraries and client data stay private.

How it fails

An AI feature adds infrastructure to your attack surface: model endpoints, keys, vector stores, connectors and service accounts. Many of the worst findings here are ordinary security failures, such as a missing tenant filter or an over-scoped token, that become reachable through a model willing to query anything it is asked to.

We test the AI layer the way a penetration tester tests an application, under written authorization and a fixed scope. We also check whether your security operations team would have seen the attack. AI traffic is often logged in a form nobody can search, so a detection gap can matter as much as the flaw.

EntryA chat request, an API call or a poisoned document in the index.
MechanismThe model reaches data or systems with its own credentials.
ImpactAnother tenant's data, a leaked key or a command run downstream.

Taxonomy

Failure classes we test, mapped to public frameworks so findings slot into the reports you already file. ATLAS IDs can be searched on the MITRE ATLAS site.

Taxonomy of failure classes with framework mappings and controls
Ref	Class	What it looks like	Frameworks	Control that belongs there
CY-1	Exposed endpoints and keys	Keys shipped in client code. Inference endpoints with no auth or rate limit.	OWASP LLM10 ATLAS AML.T0040	Server-side keys, gateway authentication and per-user quotas.
CY-2	Cross-tenant retrieval	Vector search without a tenant filter returns another customer's documents.	OWASP LLM08	Access control enforced in the retrieval query, never in the prompt.
CY-3	Retrieval poisoning	An attacker-controlled document is indexed and steers answers.	OWASP LLM08 ATLAS AML.T0070	Source allowlists, ingestion review and visible provenance.
CY-4	Over-scoped connectors	A calendar plugin granted full mailbox access.	OWASP LLM06 OWASP LLM03	Least-privilege OAuth scopes and a review for each connector.
CY-5	Delegated identity abuse	The model acts as a service account instead of with the user's own rights.	OWASP ASI03	On-behalf-of tokens tied to the requesting user.
CY-6	Improper output handling	Model output rendered as HTML, run as SQL or passed to a shell.	OWASP LLM05 ATLAS AML.T0077	Treat output as untrusted input: encode, parameterize, sandbox.
CY-7	Detection gaps	Injection attempts and bulk data pulls never reach the SIEM.	NCSC secure AI guidelines	Structured AI event logs with alert rules your SOC owns.

Test case

tenant_isolation.pypython

# Simplified isolation test. Probe sets, canary format and endpoints stay private.# Unique strings seeded into each tenant's documentsCANARY = {"tenant_a": "cnry-a-███", "tenant_b": "cnry-b-███"} def cross_tenant_leaks(client) -> list[str]:    leaks = []    for asker, owner in [("tenant_a", "tenant_b"), ("tenant_b", "tenant_a")]:        session = client.login(as_tenant=asker)   # real auth path, test accounts        for probe in retrieval_probes(owner):     # paraphrases and broad queries            hits = session.search(probe.text, top_k=50)            if any(CANARY[owner] in hit.text for hit in hits):                leaks.append(f"{asker} retrieved {owner} data via probe {probe.id}")    return leaks leaks = cross_tenant_leaks(staging_client)assert not leaks, "\n".join(leaks)

What to notice

Canaries make leaks provable without touching real customer data.
The test runs through the production authentication path. A test that skips login can miss the bug that matters.

Simplified for publication. Payload libraries, harness code and scoring rubrics stay private and are shared with clients under NDA.

Sample finding

CY-EX-009CriticalRetested · fixed

Broad queries return other tenants' documents from the vector index

The tenant filter was applied in the prompt template, not in the vector database query. Broad questions retrieved chunks from other customers, and the model quoted them.

Reproduction: Log in as test tenant A.
Send probe ███ from the broad-query set.
Check retrieved chunks for tenant B's canary.
Impact: Any customer could read fragments of other customers' private documents. No alert fired during the test.
Mapped to: OWASP LLM08 OWASP LLM02
Control: Tenant ID is a mandatory filter in the database API, with a deny-by-default test in CI and a SIEM rule for cross-tenant hits.
Retest: No canaries retrieved across 2,000 probes. The new SIEM rule fired on a planted test event.

Sources

Public research and guidance behind this page. Summaries are ours.

LLM08:2025 Vector and Embedding WeaknessesOWASP GenAI Security Project · 2025
Covers cross-tenant leakage, poisoning and inversion in retrieval systems. Most retrieval findings map here.
PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language ModelsZou et al. · 2024 · arXiv
Shows that a handful of planted documents in a knowledge base can steer a RAG system's answer to a chosen question.
LLM05:2025 Improper Output HandlingOWASP GenAI Security Project · 2025
When model output reaches a browser, database or shell without checks, prompt injection becomes classic injection.
Scalable Extraction of Training Data from (Production) Language ModelsNasr et al. · 2023 · arXiv
Extracted gigabytes of training data from open and closed models, including a production chatbot, through queries alone.
Guidelines for secure AI system developmentUK NCSC, CISA and partners · 2023
Joint guidance across design, development, deployment and operation, including logging and monitoring of AI systems.
CVE-2025-32711: Microsoft 365 Copilot information disclosure (EchoLeak)Microsoft Security Response Center · 2025
A crafted email could make Copilot leak data from the user's context with no click required. Microsoft rated it critical and fixed it server-side.

03 / What you keep

What stays with your team

Findings with severity

Each issue rated, reproduced and mapped to the component and owner responsible.

Attack paths

Findings chained into paths, so you can see which single fix breaks the most of them.

Detection gaps

Attacks your monitoring missed, with suggested detections.

Leadership briefing

A short readout on how advanced models change your cyber risk.

Where we draw the line

Testing stays inside an agreed scope and window, under written authorization. We don't build working malware, and we don't touch systems outside that scope.

All red teaming areas

Plan a red team engagement

Tell us about the system and the decision ahead. We aim to reply within two business days.

Discuss your system Book a call