AI red team · offensive security
Offensive security for AI systems, rooted in red teaming — not ML. The jailbreak isn't the finding. The SSRF, the over-scoped token, and the pivot behind it are.
[01]The problem
An LLM in your stack isn't a chatbot. It's a new caller inside your perimeter — one that reads untrusted content, holds credentials, and invokes tools.
Instructions don't have to come from your user. A support ticket, a scraped page, a PDF in your RAG index — any of it can carry a payload your model will follow.
A poisoned document in the knowledge base tells the assistant to fetch an internal URL, and its answer comes back with your metadata endpoint attached.
Give a model tools and you've given it reach. If the agent runs with broader permissions than the user in front of it, the model becomes a confused deputy with an API key.
An agent scoped to "read the user's orders" is steered into calling an internal admin endpoint the user was never allowed to touch.
What the model was trained on, fine-tuned with, or handed at inference can be pulled back out — including data that belongs to another customer.
A carefully shaped prompt reconstructs a fine-tuning record, and one tenant reads another tenant's data.
[02]Services
Four engagements. Scope the one that matches where your AI actually is.
Architecture review, AI attack-surface mapping across your models, data flows and tool integrations, gap analysis against a recognized control set.
A surface map, a ranked list of exposure points, and a short brief on where an assessment would pay off first.
A working LLM/RAG application, end to end — direct and indirect injection, context and system-prompt leakage, RBAC on retrieval sources, and abuse of the application chain the model sits in.
Reproducible findings with proof-of-concept requests, business impact per issue, and concrete remediation you can hand to engineering.
Membership inference, model and training-data extraction, cross-tenant leakage, and the data-protection exposure that follows — mapped to GDPR obligations.
A data-exposure report, demonstrated extraction paths where they exist, and a privacy-risk view your DPO can act on.
Agents with real tools and MCP integrations — tool-call abuse, privilege escalation through agent permissions, and multi-step chains that turn one weak link into system access.
Full attack narratives from entry to impact, the exact chain reproduced step by step, and the containment changes that break it.
[03]Methodology
Every issue is tied to a public reference so it survives scrutiny — from your engineers, your auditors, and your customers running vendor security reviews.
[04]About
Injentik is an independent offensive-security firm. The people who scope your engagement are the ones writing the exploit and presenting the findings — no account managers, no junior handoff.
The background is classic offensive red teaming. That matters here: most AI red teaming comes from the ML side and stops at the jailbreak. Injentik comes from the attacker side and follows the chain behind it — into the app, the tokens, and the network.
Testing is done to the HTB COAE standard — Certified Offensive AI Engineer, a seven-day hands-on exam built with Google. Every finding is tied to a public framework, so it holds up under review.
[05]Get the sample report
The sample report is a redacted engagement writeup — one real chain, from indirect injection to internal access, with the reproduction steps and the fix. Leave a work email and it comes straight to your inbox.
Prefer to talk first? Use the same form and say so in the message.