Prevent Cross-Tenant RAG Leaks with Cedarling

Paths below are relative to p2-tenantrag/ unless stated otherwise. Generated answers and retrieval rankings can vary; the authorization decisions and cited evidence are what we will verify.

What are we going to protect?

Ada has a confidential-document grant, Leo can use public Tenant A evidence, and Mallory belongs to Tenant B.

A support assistant can give a useful answer and still disclose information to the wrong person. The problem starts before the answer: which documents were sent to the model?

I'll trace that evidence path with you, then put a decision before each place where protected text can enter it.

P2 is a Node.js API that searches synthetic PDFs and generates answers. Voyage creates embeddings, Orama searches the vector index, and OpenRouter provides generation. There is no browser application. We will protect two operations: searching a tenant's corpus and loading each candidate document.

• Ada belongs to Tenant A and may read its public documents and the confidential document explicitly shared with her.¹
• Leo belongs to Tenant A but may read only its public documents.
• Mallory belongs to Tenant B and must not retrieve Tenant A's evidence.

“Public” means public within that tenant, not available to every caller.

Cedarling is the policy decision point, or PDP. The retrieval service is the policy enforcement point, or PEP: it controls whether execution reaches protected text and generation. The model does not—and must never—decide access.

Reproduce the leak before adding Cedarling

In the baseline, authentication alone does not stop Mallory's cross-tenant retrieval.

Start an isolated baseline

Use a separate checkout so the exercise does not change your existing data:

Use Node.js 24.21 or newer within 24.x and pnpm 10.17.1 for host commands. Put P2_VOYAGE_API_KEY and P2_OPENROUTER_API_KEY in the ignored project .env. Keep their values out of source control and recordings.

For Docker, start the API and its IdP together:

For native baseline startup, use two terminals. In the first:

In the second, from p2-tenantrag/, run pnpm dev. Use one startup method at a time. The API is http://localhost:17002; the IdP is http://localhost:18002. With Docker, also install the project's host dependencies for the authentication CLI using pnpm install --frozen-lockfile.

pnpm run setup builds the Orama corpus index from the synthetic PDFs as part of native setup; the first Docker startup builds it automatically. No separate corpus:reset is needed for a fresh checkout. Preparing the corpus sends PDF chunks to Voyage, and native setup also checks generation. Retrieval calls consume provider quota. Use fictional questions: the embedding provider receives your question, and generation receives the question and selected evidence. The baseline does not yet filter that evidence by the caller's permissions.

Ask for another tenant's evidence

In a free terminal, authenticate as Mallory:

Open the displayed verification URL. The development IdP usually prefills mallory; enter it if the field is empty. Use any non-empty password, such as cedarling-is-awesome, then approve access. Copy the printed token into your HTTP client's bearer-token field. I use Postman (external site), but any client that can send HTTP requests works:

The baseline authenticates Mallory but permits the two retrieval boundaries. It can load Tenant A text and send it to the model for her. Inspect returned citations, not just the answer. The baseline test/retrieval.test.ts demonstrates the leak with fixed candidates and a test generation client, independently of providers.

Capture the request and any returned Tenant A citations. A provider error proves neither a leak nor a denial. Stop the baseline before applying the integration. For Docker, use Ctrl+C, then docker compose down; keep its data volume.

Prepare trusted retrieval facts

The starting service already authenticates callers, resolves corpus metadata, searches candidate IDs, and loads document text. Its two marked authorization seams are before query embedding and before loading candidate text, but both currently omit per-caller authorization.²

Before writing a rule about confidential readers, add the missing server-owned facts. Map Ada and Leo to Tenant A and Mallory to Tenant B; give only Ada a grant for the confidential Aster document. Carry that grant through the fixture type, PDF metadata, and repository without taking it from the HTTP request:³

Keep the existing corpus-indexing and provider setup. No document text should be loaded to determine a grant; the next steps authorize from metadata first.

Decide which evidence each caller may use

The corpus rule gates search; the document rule gates which candidate text can be loaded.

Design a readable policy store

Use the directory-based policy-store format (external site):

Create these four source files from the completed policy store.⁴ The metadata identifies this store and version 1.0.0. The schema defines the request vocabulary. Both rules live in one policy file with distinct @id annotations. Current document facts arrive in requests, so default entities and templates are unnecessary.

The schema includes the token and issuer types Cedarling builds during JWT processing. RAG::Any satisfies the action's principal-type declaration; it is not another application user. Multi-issuer requests carry identity in tokens.

In trusted-issuers/tutorial-idp.json, set openid_configuration_endpoint to http://localhost:18002/.well-known/openid-configuration. The trusted access_token mapping uses entity_type_name: "P2TenantRAG::Access_token", token_id: "jti", and required claims iss, sub, aud, jti, exp, and scope.

Write the document rule

This complete policy from policies/server-access.cedar binds verified token claims to current application facts:

The context key p2tenantrag_access_token is generated by Cedarling. Dynamic sub and aud claims use tags; scope stays a space-delimited string. Whole-name matching prevents document.retrieve.extra from satisfying document.retrieve.

The companion server-search-tenant-corpus policy requires corpus.search with the same token binding and matching corpus/tenant. It does not grant every document in that corpus. No matching permit gives DENY; evaluation errors are handled as failures.

This model combines a tenant boundary with a document-specific reader relationship. Membership in a tenant alone does not confer access to every confidential document.¹

Place each decision before its effect

The route chooses actions; the repository supplies tenants, classification, and reader grants. Neither the question nor model output supplies trusted facts. Resolve candidate IDs and their relationships against repository metadata before building document requests.

Put Cedarling in the retrieval path

A corpus DENY stops retrieval; a document DENY filters that document from the batch.

Package and load the rules

Install the pinned dependencies from the project directory:

Add the integration's repository-level shared/policy-store.mjs and shared/policy-store.d.mts, which are absent from the starting commit. Run the shared builder to create the archive:

It validates source and generates ignored .local/policy-store.cjar. Docker uses the same archive source. This helper packages policies; authorization remains direct Cedarling calls.

In src/authorization.ts, initialize one server instance following the pinned SDK README (external site). Here policyStorePath comes from server configuration; this excerpt omits the surrounding lifecycle code:

Start the IdP first. Log the archive version and SHA-256 at startup and call shutDown() on application closure. src/runtime.ts wires the authorization functions into the retrieval service.

Authorize the corpus

Inside the corpus authorization function, principal is the authenticated caller, profile its repository access profile, and corpus the resolved record. This expanded request shows what the completed tokenSet() and requestContext() helpers provide:

authorizeMultiIssuer() receives a JSON string, so JSON.stringify() turns the request object into the format expected by the Cedarling JavaScript API.⁵ The later JSON.stringify(log, null, 2) only formats nested log fields for this local exercise.

In src/rag/retrieval.ts, call this before voyage.embed() and corpusSearch.search(). False becomes corpus_not_found, like an unknown corpus. An unavailable decision stops work with retrieval_unavailable.

Batch document decisions before loading text

Deduplicate resolved candidate documents. In the document authorization function, reuse the same token set and context and submit one item per document. This excerpt expands the request assembled in src/authorization.ts:

Require item.is_ok before item.unwrap(), reject diagnostics errors, and collect actual decisions in submitted order. Print native logs by each result's request ID. A successful item can contain DENY. An incomplete batch is a failure, not permission for unchecked documents.

The retrieval service forms an allowed-document set, filters candidates, and selects at most the requested three chunks. Only then does it call repository.loadChunkText() and generation. Build citations from those same chunks, not all search candidates.⁶

Keep the query bounds, server-selected corpus filter, input validation, and provider timeouts. The integration also refreshes the synthetic PDFs; after changing PDFs, rebuild the index with pnpm corpus:reset and restart. Rebuilding consumes Voyage quota; do not rerun setup or reset just to retry a model response.

Restart after policy edits.

Finish the runnable retrieval stack

With both authorization gates in place, connect archive creation to every startup path. The completed build runs the shared builder before TypeScript; Docker copies the generated archive into the API image.⁷

Separate cheap preparation from provider-backed corpus setup: scripts/prepare.ts synchronizes the local IdP/configuration and builds policies without using AI quota. scripts/preflight.ts refuses startup if the corpus index is missing; scripts/dev.mjs prepares configuration, then starts the IdP and API. It does not rebuild the index. Run pnpm run setup once to build the corpus; it also makes a provider smoke request. Then run pnpm dev. Repeat setup or pnpm corpus:reset only when the PDF/index needs rebuilding; both consume Voyage quota.⁸

The baseline's two-terminal native startup no longer applies to the completed development script.

Prove the evidence boundary, not the model's wording

An allowed corpus search does not grant every document inside that corpus.

Repeat the denied request and legitimate work

Repeat Mallory's original request for tenant-a-support. Expect 404 with error: "corpus_not_found", before embedding, search, or generation. An unknown corpus has the same status and error code, not a guarantee of identical timing.

Now authenticate as Ada, then Leo, and send:

The integrated PDFs describe Aster in Tenant A and Beacon in Tenant B. Ada may use Aster's confidential evidence; Leo may not. Ranking determines candidates, so inspect actual document decisions and citations rather than assuming one fixed answer or candidate order.

A denied document does not deny the entire question. With no authorized candidate chunks, expect 200, answer: null, and citations: [], without generation. A 503 retrieval_unavailable is instead a runtime or provider failure. With the free OpenRouter model router, availability and answer quality vary; retry a 503 before treating it as an application defect. A terse answer such as "User Safety: safe" is not the expected business answer and is not evidence of authorization. Judge access by Cedarling decisions and citations, not the model's wording. To try another model, set P2_OPENROUTER_MODEL in .env. Paid routing requires both a paid model ID and P2_OPENROUTER_ALLOW_PAID=true; use it only if you intend to spend your OpenRouter credit. Adding credit alone leaves the configured openrouter/free router unchanged. Do not rerun pnpm run setup merely to retry generation: setup also rebuilds the corpus using Voyage quota.

Explain the logs

The response's requestId appears in authorization.context. Its cedarlingRequestId matches a native request_id; document decisions also share batch_id. For Leo's confidential-document attempt, the important native fields look like this illustrative excerpt:

Token evidence explains the empty principal array. An empty reason with no errors means no permit matched, not a list of failed conditions. Compare Leo's subject with the policy's reader grant. An allowed document names server-retrieve-authorized-document in its reasons.

retrieval.completed reports candidates, documents evaluated, chunks loaded, and model. documentAuthorizationCount is not a count of allowed documents. retrieval.failed names the failed stage; provider failures include bounded provider details. Failure at answer.generate is not a Cedarling denial. Capture only synthetic evidence and remove tokens and secrets from recordings.

Check ordering and failures

From the completed project:

This runs formatting, lint, types, tests, and build without provider keys. test/policy-store.test.ts evaluates real Cedarling rules with signed test evidence. test/retrieval.test.ts proves ordering, denied-text exclusion, empty results, and unavailable or incomplete decisions with deterministic provider doubles. Those doubles are not an offline application mode. test/app.test.ts checks request failures, including unsupported content types returning 400 invalid_retrieval before retrieval runs.

Start the integrated app and run pnpm test:e2e. Approve the Ada, Leo, and Mallory sign-ins. This consumes provider quota and checks evidence access, not identical generated prose. Record the same denied attempt before and after integration, plus one successful authorized search.

Reuse the pattern in your own service

A denied corpus stops the question; a denied document is filtered while other allowed documents may continue.

Authorize the collection before expensive work, then authorize evidence before loading content. Preserve this ordering wherever search results feed a model, report, or another service.

Follow src/authorization.ts, src/rag/retrieval.ts, src/rag/repository.ts, policy-store/, and the tests in the completed P2 project (external site).

Production needs real identity and entitlement sources, secure transport, reviewed provider data handling, and protected logs. Setup embeds the synthetic corpus as an ingestion operation, not a caller-authorized retrieval. P2 controls evidence access, not model truthfulness or prompt-injection immunity: an instruction-like public document remains ordinary authorized evidence.

For a production stack, consider Agama Lab Policy Designer for policy authoring, Jans Auth for token issuance, and Lock Server for centralized decision logs. See Cedarling production solutions.

Next, P3 puts authorization at an MCP server, where a model can request a change to incident state as well as information.