Schedule icon
If icon
Fail icon
Compose icon
Docker icon
Queries icon
Script icon
CreateCollection icon
Upsert icon
Parallel icon
Query icon
Log icon
DeleteCollection icon
SlackIncomingWebhook icon

TenantShield, Multi-Tenant RAG Security Tester

Test RAG tenant isolation with Qdrant canaries, PostgreSQL evidence, parallel Python probes, Slack alerts, and a failing deployment gate.

Categories
AI

TenantShield turns cross-tenant retrieval into a repeatable release test using real Qdrant searches and a PostgreSQL audit decision.

How it works

  1. In demo mode, Docker Compose starts pinned Qdrant and PostgreSQL fixtures.
  2. Python creates deterministic hashing-trick embeddings for four canaries; native Qdrant tasks create a unique collection and upsert them.
  3. A Parallel task queries as alpha and beta for both tenants' canaries with payload filters. inject_leak: true removes beta's filter as a negative control.
  4. Python writes evidence, PostgreSQL records both probes, and an If fails the deployment on a wrong tenant_id. Error handlers clean up and optionally alert Slack.

What you get

  • A PASS/BLOCK decision with leaked IDs, hits and scores.
  • Markdown/JSON artifacts and a durable tenantshield.isolation_audits row.
  • Retries, timeouts, fail-closed behavior, and cleanup on either outcome.

Who it's for

AI security, platform, and MLOps teams shipping shared RAG infrastructure.

Why orchestrate this with Kestra

Kestra makes fixtures, parallel probes, secret-backed connections, audit writes, retries, failure gating and Slack escalation one reviewable execution.

Prerequisites

The provided Docker task runners need Docker access; demo mode also needs socket-backed volume mounts. Production mode needs reachable Qdrant gRPC and PostgreSQL endpoints. The demo binds loopback ports 16333/16334 and 15432.

Secrets

  • QDRANT_API_KEY: production Qdrant authentication key.
  • POSTGRES_USERNAME and POSTGRES_PASSWORD: production audit-ledger login.
  • SLACK_WEBHOOK_URL: incoming webhook used only when notify_slack is true.

Inputs and outputs

demo_mode selects fixtures; inject_leak enables the negative control; endpoint, collection, result-limit and notification inputs tune the run. Outputs expose verdict, leak_count, audit_row, and report_uri.

Quick start

  1. Give the worker Docker access and enable runner volume mounts, then execute with defaults; expect PASS and zero leaks.
  2. Re-run with inject_leak: true; expect PostgreSQL to retain BLOCK and the execution to fail deliberately.
  3. For production, set secrets, use demo_mode: false, test manually, then enable the schedule.

How to extend

Replace the hashing fixture with your embedding API, add role/region payload dimensions, or call this flow from CI and allow deployment only after a successful execution.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.