# Threat Model The Overra Threat Model defines the types of adversaries considered within scope, their capabilities, and the boundaries of protection provided by the system. Overra is designed to mitigate specific classes of risk at the execution layer. It does not claim protection against all forms of compromise. *** ### Adversary Classes Overra considers the following adversary types within scope. #### 1. Unauthorized External Actor An external entity attempting to trigger containment without valid authority. **Capabilities may include:** * Sending forged authorization requests * Replaying previously valid authorization messages * Attempting to bypass dashboard logic * Attempting direct communication with the local agent **Mitigation:** * Ed25519 signature verification * Authority binding to registered public key * Nonce replay protection * Timestamp and expiration enforcement Unauthorized requests cannot mutate state. *** #### 2. Replay Adversary An actor attempting to reuse a previously valid signed authorization. **Capabilities may include:** * Intercepting signed payloads * Replaying old containment or release requests * Delaying execution beyond intended time window **Mitigation:** * Unique nonce enforcement * Persistent nonce store * Expiration window validation Replay attempts are deterministically rejected. *** #### 3. Dashboard Compromise An adversary gaining control over the dashboard interface. **Capabilities may include:** * Injecting malicious UI logic * Attempting to submit unauthorized requests * Modifying frontend payload construction **Mitigation:** * Dashboard is not trusted for enforcement * All verification occurs inside the local agent * Unsigned or invalidly signed payloads are rejected Compromised UI cannot bypass signature verification. *** #### 4. Network-Level Manipulation An adversary attempting to modify or inject traffic between dashboard and agent. **Capabilities may include:** * Payload modification * Message injection * Traffic replay **Mitigation:** * Signature verification ensures payload integrity * Nonce enforcement prevents replay * Expired messages are rejected Payload integrity is cryptographically protected. *** ### Out-of-Scope Adversaries The following adversary types are considered outside the containment model. #### 1. Compromised Wallet Private Key **If the registered wallet’s private key is compromised:** * An adversary can generate valid signatures. * Containment authority may be abused. Overra cannot distinguish between legitimate and illegitimate signatures from a compromised key. *** #### 2. Full System Compromise **If an adversary gains:** * Kernel-level access * Root-level control * Direct modification of the local agent binary The security guarantees may no longer hold. Overra assumes agent integrity. *** #### 3. Physical Device Compromise **Physical access to hardware may allow:** * Direct tampering * Storage modification * Binary replacement This threat falls outside the logical containment boundary. *** ### Security Boundary Definition **Overra’s protection boundary includes:** * Authorization verification * Replay protection * Deterministic state transition * Local enforcement * Audit logging **It does not extend to:** * Hardware security * OS kernel integrity * Private key protection mechanisms The containment primitive assumes cryptographic authority and agent integrity. *** ### Risk Mitigation Summary Within its defined boundary, Overra mitigates: * Unauthorized containment triggers * Replay attacks * Expired authorization execution * Cross-device authorization reuse * Centralized override abuse The system strengthens endpoint containment by introducing deterministic, cryptographically bound state control. *** ### Threat Model Summary Overra is not a general-purpose endpoint defense system. It is a cryptographically governed containment primitive. **Its threat model is intentionally scoped to:** * Authorization abuse * Replay attacks * State mutation attempts * Trust boundary violations By limiting scope and defining explicit assumptions, Overra maintains predictable and auditable security guarantees. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://overra.gitbook.io/overra-docs/threat-model.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.