RAG Formation · Lesson · Reliability & product readiness
Security, permissions, and deployment boundaries
Keep client data, secrets, tenant boundaries, and production services out of unsafe demo assumptions.
$ lesson --status
▸ course RAG Formation
▸ lesson 15 / 16
▸ phase Reliability & product readiness
▸ status Complete
● build → measure → learnStandalone lesson
Learn the full lesson and test your understanding here.
The 16-lesson RAG Formation curriculum is complete. This page contains the complete lesson content, local reference material, and instant browser exercises.
Today’s tangible win
A lightweight MVP checklist of threats and permissions, with one negative test proving each boundary actually holds.
Watch the walkthrough
1 · The skill
Walk the demo boundary, how environment variables get loaded, your CORS and logging assumptions, and run one negative access test — all without opening a single secrets file.
- Least privilege: Users, services, tools — each one gets only the access it actually needs.
- Data boundary: A real, technical wall between demo, staging, and production — covering both the data and the credentials that unlock it.
- Prompt/data injection: Untrusted document or user content trying to hijack system behavior or leak information it should not.
- CORS, concretely:
api/app.pysetsallow_origins=["*"]— not an assumption to go verify, an observable fact to read for yourself. Decide whether that's acceptable for this demo's threat model, and what would have to change for a real multi-tenant deployment.
Primary reading: OWASP — Top 10 for Large Language Model Applications
2 · Run the evidence loop
Start with the ingestion boundary — this is a dry run, it changes nothing:
cd demo
python3 setup_demo.py ingest --dry-runRead the printed commands and confirm the secret path: .env.demo.local (demo-only, git-ignored) is a separate file from demo/.env (a copy of the production env) — the demo stack never reads the latter.
Then test the query-time boundary live. With the stack up (python3 setup_demo.py up), call /api/v1/qa twice — same question, same everything, except workspace:
curl -s -X POST http://localhost:8000/api/v1/qa \
-H "Content-Type: application/json" \
-d '{"question": "What changed between V3 and V4 of PR-QA-MRD-009?", "workspace": "meridian_demo"}'
curl -s -X POST http://localhost:8000/api/v1/qa \
-H "Content-Type: application/json" \
-d '{"question": "What changed between V3 and V4 of PR-QA-MRD-009?", "workspace": "not-a-real-workspace"}'Compare the two responses' stats.graph_context_chars and the citations under sources. If the graph-related evidence changes — or disappears — between the two calls while the vector/summary/fulltext citations stay identical, you've just watched the actual boundary live: real for the graph channel, absent for the other three.
For each boundary, write down what is protecting it right now, a safe command that proves it, and where the enforcement gap is.
It does not matter how accurate the answer is — if it exposes a restricted document or a secret, that is a failure.
3 · Decision worksheet
| Baseline evidence | One hypothesis/change | Metric | Regression check | Bounded conclusion |
|---|---|---|---|---|
| _____ | _____ | _____ | _____ | _____ |
4 · Retrieval practice
Question: A secret never makes it into Git, but it still gets printed in a debug log. Is that boundary safe?
Mission connection
A company chatbot fails the moment it exposes a client document, a production key, or a restricted procedure — even if every word of the answer is factually correct.
5 · Deliverable and next action
- Save the command output, or the report.
- Fill in the decision worksheet.
- Write down one failure case, and the next verification to run.
A lightweight MVP checklist of threats and permissions, with one negative test proving each boundary actually holds.
Next: Lesson 16 — Pilot review and 30-day implementation plan.
Ask me follow-up questions about the evidence, the metric, the failure case, or what to try next — I am your teacher for this course.