Engineering and AI

AI-Native Systems

RAG pipelines and agents built with evals and permission boundaries from the start, and LLM red teaming for systems your own team has built. Both done by the same engineers.

An LLM feature fails in two different ways. It gives wrong or unhelpful answers, which only shows up when someone reads real outputs at volume. Or it does what an attacker tells it to, because a model with tools reads untrusted text and then acts on it. The first is an evaluation problem. The second is an authorisation problem, and no amount of prompt wording solves it.

We build these systems and we attack them. On a build, we read outputs early and often, sort the failures into categories, and turn them into evals that gate each release. Tools run with the user's permissions, not the model's, and risky actions wait for a person. On a red-team engagement, we test your deployed system with its real retrieval sources and tools connected, and report what an injected instruction can actually reach.

Usually, one of these is true

An internal RAG assistant works in demos, but nobody can say how often it answers wrongly or which documents it should never see.
You are about to give an agent tools that write: sending email, updating records, issuing refunds or running code.
A customer's security review asks how your LLM feature handles prompt injection and data leakage, and a policy statement will not be enough.
A prompt change or a model upgrade quietly made answers worse, and nothing caught it before users did.

What we build and test

Architecture and red teaming cover the same ground from opposite sides. Each area below is something we design when we build and something we attack when we test.

RAG and retrieval. Chunking, indexing and retrieval quality measured on your own questions, citations back to source, and document permissions enforced at query time so the model never sees what the user could not open.
Agents and tools. Narrowly scoped tool definitions, calls made with the end user's credentials, confirmation steps for writes and payments, and limits on loops, spend and data leaving the system.
Evals and error analysis. Trace review with your domain experts, a catalogue of failure modes, pass/fail checks and LLM judges calibrated against human labels, run in CI before each release.
LLM red teaming. Direct and indirect prompt injection, jailbreaks, system prompt and data extraction, and tool misuse, run against the deployed system with its real retrieval and tools connected.
Guardrails. Input and output checks, schema validation on every tool call, output handling that treats model text as untrusted, and a defined fallback when a check fires.
Model governance. Model and prompt versioning, an inventory of models and data sources, trace logging with retention rules, and the records an AI management system or a regulator will ask for.

How the work runs

A build runs through all five stages. A red-team engagement on a system you built maps it, attacks it and retests it. Either way, scope, price and dates are fixed in writing first.

Map the system. We document the models, prompts, retrieval sources and tools, the permissions behind each, and every place untrusted text enters: user input, documents, web pages, emails and tool output.
Error analysis. We read traces with the people who know what a good answer looks like, write down how the system fails, and rank the failure modes by how often they occur and how much harm they do.
Build with evals. Retrieval, tools and guardrails are built in small increments, each failure mode tied to an eval, and the suite runs in CI so a prompt or model change cannot ship a regression unnoticed.
Red team. We attack the deployed system with its real tools and data connected: injection, extraction, jailbreaks and tool abuse. Findings reach your channel as they are confirmed, and anything critical within the hour.
Retest and handover. We retest once fixes land, then hand over the eval suite, the attack cases and the runbooks so your team keeps running them after we leave.

What you get

System and trust map. A diagram of models, data sources, tools and permissions, showing where untrusted text enters and what it can reach.
Eval suite. Failure-mode catalogue, test cases and calibrated judges in your repository, wired into CI for your engineers to extend.
Red-team findings. Each finding with a working reproduction (the exact prompt, document or payload), mapped to CWE and the OWASP Top 10 for LLM Applications, rated with CVSS v4.0.
Retest and attestation. A retest after fixes land and a letter of attestation for the red-team engagement, for your customers' security reviews.
Governance record. A model, prompt and data-source inventory with versioning and logging decisions written down, for your risk owner and your assessor.

What we need from you

The deployed system or a staging copy with the same models, retrieval sources and tools connected, plus test accounts at each permission level.
System prompts, tool definitions and retrieval configuration, or repository access so we can read them.
A sample of production traces or logs shared under the NDA, or realistic test inputs if the system is not live yet.
A domain expert who can say whether an answer is right, available to label outputs during error analysis.
Your rules for what the system must never do or reveal, and any regulatory context that applies to it.

What we can show you

Builders who red-team. We design agents and retrieval pipelines and we attack them, so the permission boundaries in a build are ones we have tried to cross on other systems.
Injection rated by reach. An injected instruction is rated by what it can do through the tools, not by how strange the output looks, the same way we rate an access-control bug in a web test.
Security research depth. 70+ CVEs published by our researchers, and research acknowledged by Apple, Microsoft, Google OSS VRP, Facebook, Twitter, Adobe, Intel and the U.S. Department of Defense. The same engineers write the attack cases for your system.
Your traces stay private. Mutual NDA and PGP before any trace or prompt is shared. Evidence is encrypted, limited to the engineers on the engagement, and destroyed after the retest on request.

Standards we work to

The threat catalogues and governance frameworks that AI reviewers, customers and regulators reference, so findings and design records map onto them directly.

OWASP Top 10 for LLM Applications
MITRE ATLAS
NIST AI RMF
NIST AI 600-1
ISO/IEC 42001
EU AI Act

Common questions

Can you red-team a system we built ourselves?

Yes. That engagement skips the build: we map your system, attack it with its real tools and data connected, report findings as they are confirmed, and retest after your fixes. A letter of attestation is included once the retest is complete.

Which models and frameworks do you build with?

Whatever fits the problem and your constraints, including hosted APIs and self-hosted open-weight models. We keep the model behind an interface so it can be swapped, and the eval suite is what tells you whether a swap is safe. The design is not tied to one provider.

Do guardrail products solve prompt injection?

They reduce it; they do not remove it. Classifiers and filters catch known patterns, and a determined attacker can phrase around them. The controls that hold are architectural: tools that run with the user's permissions, untrusted content kept away from privileged tools, and a person confirming actions that matter.

Do we need evals if the demo already looks good?

A demo runs on inputs someone picked. Evals show what happens on the inputs nobody picked, and whether a prompt or model change made things worse. We build the smallest suite that covers your real failure modes and grow it as new ones appear.

Will this satisfy the EU AI Act or ISO/IEC 42001?

We do not issue certifications and we are not a certification body. We provide the testing evidence, risk records and system documentation those frameworks ask for, written so your assessor or legal team can use them. Which obligations apply depends on how your system is classified, which is a question for your counsel.

Related services

Tell us about the system in the chat or on the contact page. Yaali, our AI agent, answers first and brings in an engineer.