AI Security Testing / FOCUSED SERVICE

RAG Pipeline & Data Boundary Testing

RAG security testing checks document access, retrieval poisoning, and permission changes, with evidence of where an AI assistant can expose data.

WHAT THIS SERVICE ADDRESSES

The challenge behind the engagement.

Retrieval-augmented generation (RAG) lets an AI assistant answer from your documents. This security test checks whether those answers respect access permissions. We map how content flows in and find where each user's permissions are enforced: in the search service or application code. Then we ask questions as users in different groups, using paraphrase and tampered queries, and inspect citations for data leaks. We add a document carrying hidden instructions through an agreed upload path and test whether it is retrieved and obeyed. We remove someone from a group and measure whether access changes reach the assistant. You receive an entitlement matrix, poisoning test evidence, and a measured timeline. Your real documents are not copied; we use test documents and users where possible.

WHEN THIS IS THE RIGHT FIT

For teams that have connected content sources such as wikis, file shares, or a ticketing system to an assistant. Schedule it before opening the assistant to the whole company, before a customer asks how document permissions are enforced, or after a report that someone saw a file they should not have.

THE WORK BEHIND THE SERVICE

What we do.
What you can use.

Map the pipeline and permission model

We work from a map of how content moves from its sources through to an answer, and match your permission model, whether groups, folder permissions, or custom access lists, to test users across groups and tenants. We agree permission to add one test document and change one access rule, and we get the index configuration and its refresh schedule.

Probe entitlements, poison, and time propagation

We query as each test user with plain language, paraphrase, closely related wording, and tampered filters, and press on filters built in application code. We add a document carrying instructions through a connected source such as a wiki, shared drive, or ticket and confirm it is retrieved and obeyed. Then we change a group membership and measure when the results change.

Deliver the entitlement matrix and timeline

You receive an entitlement matrix of expected versus observed access for each user and document type, the planted document and the response it produced, and a measured timeline. Pipeline findings carry fixes by control point: where permissions are enforced, how they attach to each piece of content, how often the index refreshes, and who can write to the sources. We retest after the changes land.

IS THIS THE RIGHT ENGAGEMENT?

Who it’s for.
When you need it.

BEST SUITED FOR
  • Teams that connected wikis, file shares, or ticketing systems to a retrieval assistant
  • Organizations whose retrieval corpus mixes content with different access permissions
  • Product teams preparing to open a retrieval assistant to the whole company
  • Security teams that must prove document entitlements are enforced at retrieval time
WHEN IT’S TIME TO ENGAGE
  • A retrieval assistant is about to expand from a pilot group to everyone
  • Someone reported seeing a document through the assistant they should not access
  • A customer asks how per-document permissions are enforced inside the assistant
  • A new content source or permission model was just connected to the index
AGREED AROUND YOUR ENVIRONMENT

What the scope can include.

  • Entitlement checks per group and tenant using plain, paraphrased, and closely related queries

  • Where each user's permissions are enforced: the search service, or filters built in code

  • Shared indexes and caches, and steps that run over everything before the permission filter

  • Poisoning the index by adding an instruction-bearing document through a connected source

  • Content that loses its permission tags when it is broken into pieces for the index

  • How long a permission change in the source takes to reach the assistant's answers

TRANSPARENT PRICING

What it typically costs.
One rate: $150/hour.

Every engagement is priced by the hours it takes at one flat rate, with scoping, the work, and reporting, plus a retest of your fixes, included. Find the size closest to yours.

Small
$6,000–$9,000

One assistant answering from one document source with a few permission groups

About 40–60 hours
Mid-size
$10,500–$16,500

One assistant drawing on several sources, such as a wiki, shared drives, and tickets, with many groups

About 72–110 hours
Large
$19,500–$28,500

A company-wide or customer-facing assistant over many sources with separate customer data

About 130–190 hours
WHAT MOVES THE PRICE
  • Number of connected document sources
  • How many permission groups and customer accounts must be checked
  • Whether permissions are enforced by the search service or by custom code
  • How long the index takes to refresh, which sets the permission-change timing test
TYPICAL TIMELINE

2–5 weeks

Get a fixed quote for your scope

Ranges are planning estimates at $150/hour, not a quote. Your price is confirmed in writing after a scoping call, before any work begins.

TANGIBLE DELIVERABLES

What you take forward.

  • Entitlement matrix of expected versus observed access for each test user and document type
  • Poisoning proof: the planted document, the query that retrieved it, and the response that followed it
  • Measured timeline from a source permission change to the change in the assistant's answers
  • Fixes by control point: where permissions are enforced, how they attach to content, refresh timing, and source controls

Final coverage, deliverables, timing, and any retesting or implementation work are confirmed before the engagement begins.

SERVICE-SPECIFIC QUESTIONS

Before we get started.

We filter by group ID in code; is that enough?

It can be, but it is the weakest place to enforce it, and we test it hardest. A filter built in code depends on that code reading the right groups, applying them on every path a query can take, and never letting a prompt or a parameter change the filter. We also check what runs before the filter, since a step that ranks or rewrites across the whole collection can pull restricted content into view. Where the search service can enforce permissions itself, we show what moving enforcement there would change.

When we remove someone from a group, how fast does the assistant stop showing them documents?

We measure it rather than quote a vendor's figure. During the test we change one group membership or access rule in the source system, then keep asking as that user on a schedule until the results change, recording the elapsed time against your index's refresh cycle. Permission changes usually reach an assistant only after the index re-synchronizes, and some sources need an explicit refresh before inherited changes take effect. Others leave enforcement to your own code entirely. The timeline in your report is the number you can give customers and auditors.

REFERENCE POINTS
START AT THE SOURCE

Let’s find your next move.

A focused conversation. A clear scope. A practical path to stronger security.

Let’s talk security