We publish how AI breaks. Not opinion pieces or threat forecasts — teardowns of real systems we were authorized to attack, showing where the system broke first, the exact chain that got us there, and the fix that closed it. The first write-up is being written now.
What a Phixe write-up is
Every write-up is a field report from an assessment, not a marketing story. It carries the same evidence bar as the work: reproducible request traces, not screenshots of a vibe. If a claim cannot be reproduced against the target, it does not go in.
Each one includes:
- A single, real attack chain — the sequence of steps from an untrusted input to an outcome that mattered (data leaving a boundary, a tool call the user never authorized, a retrieval that poisoned an answer). One chain explained fully teaches more than ten findings listed.
- Reproducible evidence — the prompts, the request and response traces, and the exact conditions, so an engineer on the other side can rerun it and confirm.
- Framework mapping — the finding located against the OWASP LLM Top 10 (for example LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure), the OWASP Agentic Security Initiative Top 10 where an agent is involved, and MITRE ATLAS techniques. Where governance context matters, we tie it to NIST AI RMF.
- The fix, and its limits — what we changed, why it holds, and what it does not cover. We reduce risk and prove exactly what we tested. We will never claim a system is “safe” — no one can.
In progress: the first write-up
Red-teaming a production AI workflow: where it broke first. A working AI workflow that passed its own demo — taken apart the way an attacker would, starting from the cheapest untrusted input and following it until something gave. The write-up walks the full chain, the request traces behind it, the OWASP and ATLAS mapping, and the remediation.
It will publish here soon. To get it the day it lands, email us and we will send it on release.
What we research
Six areas. Until the write-ups land, each links to a working guide you can use today.
- Production readiness. What separates an AI feature that survives real traffic and an enterprise security review from one that only survives the demo — see the AI production-readiness checklist.
- LLM red-teaming. How we attack a model and its surrounding application: jailbreaks, system-prompt extraction, and abuse of the trust boundary between instructions and data — see the LLM red-teaming guide.
- RAG security. Retrieval as an attack surface: poisoned documents, injection through retrieved context, and disclosure across tenants and permission boundaries — see the RAG security guide.
- Agent security. What changes when the model can act: tool misuse, confused-deputy chains, and unauthorized actions taken on a user’s behalf — see the AI agent security guide.
- Prompt-injection testing. Turning LLM01 from a headline into a repeatable test suite over direct and indirect injection — see the prompt-injection testing guide.
- Evals. Measuring whether a fix actually held and whether behavior regresses over time, with graded test sets instead of gut feel — see the LLM evals guide.
Our rules for publishing
Research that is not disciplined is just exposure. We hold three lines without exception:
- Authorized targets only. We attack systems we own or are explicitly authorized to assess. Our own product, faben, is one such target. We never test a system we were not invited to test, and nothing in a write-up implies otherwise.
- No client identification. A published write-up never names, hints at, or fingerprints a client. Findings are generalized to the pattern — the attack chain and the lesson — never to the company. If a detail would identify the target, it is removed or changed until it cannot.
- Coordinated disclosure. Nothing publishes while a real system is exposed. Findings against a live target go to the owner first, with time to fix, and reach the public only once the risk is resolved or the owner has cleared it.
Until then, the guides are the research surface
The write-ups are how we show a single system breaking end to end. The guides are how we show the method that finds it. They are the most useful thing we have published so far, and they are free to use:
- AI production-readiness checklist
- LLM red-teaming
- RAG security
- AI agent security
- Prompt-injection testing
- LLM evals
How the guides turn into an engagement is on the methodology page, and the shape of the deliverable is in the sample AI assessment report. When you want the first write-up the moment it publishes, email us and we will send it on release.