Research / Threat model
Threat model
Every serious security or AI-safety project should be explicit about what it protects against, what it detects, what it records, and where it stops. This model applies to the Sidian Labs stack as a whole.
Scope
The model covers POLICY.md, MAP, OVARA, DASH, and Sidian. It assumes an increasingly autonomous agent that can call tools, modify code, access infrastructure, and make consequential decisions.
General trust boundary
The control layer can only enforce actions that pass through it. A host application, a compromised runtime, or an action that bypasses the gateway is outside the enforcement boundary. Cryptographic receipts prove what the control layer decided, not what morally or semantically should have happened.
Threats
Ten threats, each with what the stack prevents, what it detects, what it cannot prevent, and the assumptions each answer depends on.
| Threat | Prevents | Detects | Cannot prevent | Required assumptions |
|---|---|---|---|---|
| T1Unreliable model | Only execution, not correctness of intent. | Anomalous action patterns via OVARA trust scoring. | Model hallucination or misunderstanding. | Policy covers the action class. |
| T2Prompt injection | MAP/OVARA can deny high-risk actions regardless of how the request was produced. | Unusual capability/resource combinations; trust degradation. | All possible social-engineering or context-manipulation paths. | Action is routed through the enforcement layer. |
| T3Malicious agent | Actions outside granted capabilities/leases. | Signature/lease/identity failures; policy violations. | A malicious agent with valid, unexpired credentials. | Identity and lease verification are enforced. |
| T4Malicious tool | MAP can gate the call; OVARA can deny the surface. | Tool output is not directly inspected for maliciousness. | A tool that returns correct-looking but harmful output. | Tool is registered and policy covers its actions. |
| T5Compromised host | Nothing, if the host bypasses the control layer. | Receipts can show the bypass did not occur through the gateway. | Direct execution by the host OS or another process. | The gateway runs on a separate, less-trusted host or enclave. |
| T6Compromised policy engine | Detection via hash-chained logs if tampered after the fact. | Audit chain and signed receipts. | Real-time tampering of the engine itself. | Engine runs on a trusted host with restricted access. |
| T7Credential compromise | Short-lived, scoped leases reduce blast radius. | Lease misuse, anomalous delegation patterns. | Use of a stolen but unexpired credential. | Credential material is stored and rotated securely. |
| T8Privileged human | MAP/OVARA can require human approval for sensitive actions. | Approval logs and receipts. | An authorized human making a bad approval. | Approval workflow is configured and followed. |
| T9Policy admin compromise | POLICY.md can be versioned and audited; POLICY.md does not enforce tamper resistance. | Git history and signed policy bundles (if implemented). | A malicious or coerced administrator changing policy. | Strong repository access controls and multi-party review. |
| T10Infrastructure compromise | Limited to the boundary of the gateway/runtime. | Audit logs may survive on separate storage. | Anything the host kernel, hypervisor, or network can do. | Hardened hosts, network segmentation, and off-box telemetry. |
Per-project notes
- POLICY.md
- Defines rules but does not enforce them; enforcement is host-dependent. Default-allow for unmatched capabilities is a residual risk.
- MAP
- Enforces before execution for registered adapters; it does not inspect or sanitize LLM-generated intent. Default dev keys make receipts non-verifiable after restart.
- OVARA
- Verifies identity strings in V1, not signatures; hardening artifacts are not loaded at runtime;
fail_closeddefaults to false. - DASH
- Records provenance, not truth; single-node deployments lack quorum/failover;
usearchHNSW is future work. - Sidian
- Has no public threat model or build artifact to evaluate.