Drasi threat model - {project name}
Use this template to record the threat model for a Drasi deployment. Pair it with templates/drasi-architecture-decision-record.md (for the runtime/architecture decisions) and templates/drasi-risk-register.md (for ongoing risk tracking).
The threat model is a living document. Update it at every Drasi minor version bump or quarterly, whichever is sooner.
Scope
Define what is in scope for this threat model. Be explicit; an out-of-scope component is one no one will own.
- Project name: {project name}
- Drasi runtime form: { Drasi Server | Drasi for Kubernetes | drasi-lib (embedded) }
- Drasi platform version: { e.g., 0.9.x - pin exact version }
- Sources in scope: { e.g., PostgreSQL
orders, SQL Serverinventory, Kubernetesevents} - Reactions in scope: { e.g., HTTP webhook to
payments-svc, MCP Reaction atdrasi://query/...} - MCP exposure: { none | internal only | gateway-fronted to agents | other }
- Tenancy posture: { single-tenant | multi-tenant (link to primitives) - see
bundles/security/guide.md"Multi-tenancy stance" } - Out of scope: { explicitly list - e.g., the source DB's own internal security, downstream reaction destination's internal security }
Trust boundaries
Enumerate each trust boundary this deployment actually crosses. Start from the reference list in bundles/security/guide.md "Trust boundaries and STRIDE mapping" and remove or add as appropriate.
| # | Boundary | Description | In scope? |
|---|---|---|---|
| 1 | Operator ↔ control plane (REST API) | { who calls, from where, over what network } | Yes / No / N/A |
| 2 | Drasi ↔ source DB | { which source, which DB, which network } | Yes / No / N/A |
| 3 | Drasi ↔ reaction endpoint | { which reaction, which destination, which network } | Yes / No / N/A |
| 4 | Agent ↔ MCP Reaction | { which agents, which gateway, which scopes } | Yes / No / N/A |
| 5 | Secrets at rest | { Key Vault / Kubernetes Secret / other } | Yes / No / N/A |
| 6 | drasi-lib host process ↔ embedded library | { only if runtime form is drasi-lib } | Yes / No / N/A |
| ... | { additional project-specific boundary } |
STRIDE per boundary
Fill in mitigations for each in-scope boundary. Use "N/A by design" for boundary-category combinations that do not apply (and justify briefly).
| Boundary | S | T | R | I | D | E |
|---|---|---|---|---|---|---|
| Operator ↔ control plane | { mitigation } | { mitigation } | { mitigation } | { mitigation } | { mitigation } | { mitigation } |
| Drasi ↔ source DB | ||||||
| Drasi ↔ reaction endpoint | ||||||
| Agent ↔ MCP Reaction | ||||||
| Secrets at rest | ||||||
| drasi-lib host process |
Data classification
Classify every field that flows through this Drasi deployment using the scheme in bundles/security/guide.md "Data classification and redaction".
| Field | Source | Class (Public / Internal / Confidential / Restricted) | Allowed in result | Allowed in logs | Allowed in metrics |
|---|---|---|---|---|---|
| { field } | { source } | { class } | { yes/no/redacted } | { yes/no/redacted } | { yes/no/redacted } |
Reference: bundles/security/guide.md "Data classification and redaction" table.
Identified risks
Number each risk. Rate severity using templates/drasi-risk-register.md rubric if your project uses one; otherwise use Low / Medium / High / Critical.
| # | Risk | Boundary / Component | Severity | Likelihood | Status |
|---|---|---|---|---|---|
| R1 | { e.g., Compromised reaction exfiltrates source rows over unrestricted egress } | Drasi ↔ reaction endpoint | High | Medium | Open / Mitigated / Accepted |
| R2 | { e.g., Unbounded join in query Q-... exhausts node memory } | ContinuousQuery | High | Low | |
| R3 | { e.g., Prompt injection via free-text source field reaches agent tool call } | Agent ↔ MCP Reaction | Medium | Medium | |
| R4 | { ... } |
Mitigations and validation
For each numbered risk above, record the mitigation and how it was validated.
| Risk # | Mitigation | Validation evidence |
|---|---|---|
| R1 | NetworkPolicy default-deny egress + per-reaction allowlist (see bundles/security/guide.md "Network egress controls") |
Output of egress-leak verification command attached as evidence |
| R2 | Per-query CPU/memory limits; pre-merge review gate (see bundles/security/guide.md "ContinuousQuery resource quotas") |
PR review record; load-test report |
| R3 | Source-field provenance tagging; agent treats tagged strings as data (see bundles/agent-integration/guide.md "Untrusted content") |
Agent contract test with adversarial payload |
| R4 | { ... } |
Review cadence
- Review trigger: at every Drasi minor version bump or quarterly, whichever is sooner.
- Additional triggers: new source added, new reaction added, MCP exposure changes, tenancy posture changes, any sev-1 or sev-2 incident touching Drasi components, any change to the audit-log destination or retention.
- Review owner: { name / role }
- Last reviewed: { YYYY-MM-DD }
- Next review due: { YYYY-MM-DD }
Owner
- Primary owner: { name, role, contact }
- Secondary / on-call: { name, role, contact }
- Security reviewer: { name, role, contact }
Last reviewed date
{ YYYY-MM-DD }