OUR METHODOLOGY

How we actually do the work.

A five-phase process for AI security work. Mapped to the standards your auditors, regulators, and insurers already use — without the alphabet soup that usually comes with them.

THE PROCESS

From "we don't know what could go wrong" to "we've fixed it, and we can prove it stays fixed."

Every engagement runs the same five phases. Each one builds on the last, and the work doesn't close until the original problem can no longer be exploited.

  1. 01

    Scope and threat model.

    We sit down with you and map what the AI system actually does — what data it touches, what actions it can take, and where things would hurt your business if they went wrong. We agree on what's in scope and what's off-limits. The output is a short written threat model that everyone signs off on before any testing begins.

    Aligns to NIST AI RMF "Map"
  2. 02

    Learn the system from the outside in.

    Before we attack anything, we use your system the way a curious customer would. We map its real behaviour, the guardrails it has, the tools it can call, the documents it can read, and the memory it carries between conversations. This is where we find the edges that public benchmarks always miss.

    Application enumeration
  3. 03

    Try to break it.

    We combine hand-crafted attacks built from your threat model with automated test suites covering the well-known failure patterns: hidden instructions in retrieved content, tool misuse, leaked system prompts, poisoned memory, and the rest. Every working attack ships with a script that re-runs it on demand — no reproducer, no finding.

    OWASP LLM Top 10 · MITRE ATLAS
  4. 04

    Chain the small problems into the real one.

    A single quirky behaviour is rarely the real story. Impact comes from chains — a hidden instruction in a document triggers a tool call, which exposes a credential, which unlocks a customer record. We try those chains the way a motivated attacker would, so what you see at the end is business risk, not technical curiosities.

    Impact amplification
  5. 05

    Fix it, then prove the fix held.

    Each finding comes with a recommended fix, and we pair with your engineers to land the change. Then we re-run the exact same attack. The engagement closes only when the original exploit no longer works — and the test that proves it stays in your CI pipeline, so a future change can't quietly bring the issue back six months later.

    Closed-loop remediation
NON-NEGOTIABLES

How you can tell the real work from the theatre.

A lot of "AI security" services produce slide decks that age out within weeks. These are the rules we hold ourselves to, so what you buy is something engineering can actually act on.

01 — Evidence

No reproducer, no finding.

Every issue ships with the exact script that triggers it. If we can't reproduce it on demand, we don't report it. This is the single biggest filter between real work and a glossy deck — and it's what the current OWASP guidance for AI testing explicitly requires.

02 — Deliverable

Tests, not PDFs.

The thing you keep at the end isn't a report — it's an executable test suite that runs in your CI. Each finding is a test that's red while the issue is open and green once it's been fixed. If anything quietly regresses later, you'll know on the next build.

03 — Scope

The whole system, not just the model.

Most real AI failures don't live inside the model. They live at the seams — the tool calls, the document retrieval, the memory, the way model output is handed off to the rest of your stack. That's where we look, because that's where the bugs are.

04 — Cadence

Continuous, not annual.

A point-in-time audit ages out the moment you ship the next change to a prompt, a tool, or a retrieval source. We design every engagement so the test harness can be re-run on demand — by us or by your team — and we re-engage on a cadence that matches how fast your AI surface is moving.

05 — Definition of done

Done means the exploit fails.

The work isn't finished when the report is delivered. It's finished when re-running the original attack against your production system no longer succeeds. That's a higher bar than the industry usually holds itself to, and we think it's the only bar that matters.

06 — Standards

Mapped to language your auditors already speak.

Every finding is tagged with the relevant frameworks, so your security, legal, and compliance teams can each read the same report and find the language they need — without us inventing a new taxonomy that nobody else uses.

Mapped to OWASP LLM Top 10 (2025) MITRE ATLAS NIST AI RMF Google SAIF

Frequently Asked Questions

With a 30-minute scoping call. We cover what's deployed, what you're worried about, and what success would look like. We send a short written brief afterwards — phases, time on team, cost — and nobody commits until you've read it.

Most engagements run between one and six weeks. A single-product audit usually lands in two to three weeks; a deeper embedded engagement on an agent platform is typically four to six. We size to the scope, not the calendar.

An executable test suite — not a PDF. Each finding is a red test in your CI while the issue is open, and a green test once it's been fixed. You also get a short written report with the threat model, the exploit chains, and the recommended remediations, but the test suite is the thing you keep.

Yes — that's the design. The harness lives in your repository, runs in your CI, and is yours to extend. If you want us to keep adding to it on a cadence, we can — but you're not locked in.

Production-facing LLM applications: agents, copilots, customer-facing chat, retrieval pipelines, and any system that wraps a model with tools, memory, or data access. We don't generally work on raw model alignment — that's a different field.

Mostly the application — that's where the real failures live. Most "AI bugs" today aren't inside the model; they're at the seams: the tool calls, the retrieval boundary, the memory store, the way model output is handed off to the rest of your stack. We test those seams thoroughly. We'll also run targeted model-level probes where the system exposes them.

We work on pre-launch systems all the time, and it's usually the cheapest place to catch the worst bugs. If you have a staging environment we can test against, we can run the same engagement before launch.

Most of the time, that's the default. Your security team has context we don't, and we'd rather pair than gatekeep. We share findings as they come up, not in a single big reveal at the end.

Every finding is tagged against the OWASP LLM Top 10 (2025), MITRE ATLAS, NIST AI RMF, and Google's Secure AI Framework. Whichever one your auditors, insurers, or board already speak, the report's language matches.

Yes. We deliberately avoid inventing new taxonomies. The threat model, findings, and remediation guidance all map to the standards your assurance teams already use, so the report can be handed straight to them.

For high-risk systems under the EU AI Act, the cybersecurity and robustness obligations map cleanly onto the testing we do. We can structure the deliverable so it's directly consumable as evidence for those obligations — talk to us if that's the use case.

Still have questions? Reach out and we'll walk through your specifics.

Get in touch
STARTING POINT

One scoping call. One short brief.

A 30-minute call covers what's deployed, what you're worried about, and what success would look like. We follow up with a short written brief — phases, time on team, cost — and only then does anyone commit. Most engagements run between one and six weeks.

Reach us at hello@ryvane.com.

Where AI security gets practiced.

Knowledge that translates innovation into outcomes.

LEARN MORE