Security • Architecture

Threat Model & Honest Limitations

RTQ's threat model defines explicit trust boundaries, identified threats, concrete mitigations, and what RTQ explicitly does not attempt to solve.

Trust Boundaries

RTQ Runtime ProcessTRUSTED

Capability RegistryTRUSTED

Policy EngineTRUSTED

Ticket Signing KeyTRUSTED

Operating System KernelTRUSTED

Caller / Host ProcessUNTRUSTED

Tool Arguments & InputsUNTRUSTED

Network PeripheralsUNTRUSTED

Threats & Concrete Mitigations

All mitigations link directly to exact source lines at commit e179d2b.

Capability Spoofing / Name Collisions

capability-registry.ts (L40-85)

An untrusted caller attempts to register a capability mimicking a system operation or override an existing registration.

Mitigation:CapabilityRegistry enforces immutable schemas and rejects name collisions at registration time.

Authorization Ticket Replay

ticket-store.ts (L180-206)

Reusing a valid authorization ticket for a second execution attempt.

Mitigation:TicketStore atomically transitions ticket status to 'redeemed'. Replays return ok: false with code 'replay'.

Caller Risk Manipulation

index.ts (L337-347)

Caller claims a low risk (claimedRisk: 'low') to bypass mandatory human or device confirmation.

Mitigation:Authoritative risk evaluator ignores caller downgrade claims; risk is calculated independently from declared base and context factors.

Implicit Policy Bypass

index.ts (L365-382)

Executing a capability when no matching allow rule has been defined.

Mitigation:Strict default-deny policy evaluator. Missing rules evaluate to refusal (INV-03).

Uncontained Execution Fallback

index.ts (L220-280)

Executing unsandboxed when platform sandbox tools are missing or misconfigured.

Mitigation:Sandbox adapters fail closed. If Seatbelt or bubblewrap cannot be initialized, execution is blocked.

Audit Record Tampering & Secret Leakage

index.ts (L85-125)

Hiding unauthorized activity or leaking sensitive credentials into audit streams.

Mitigation:Structured events with HMAC signatures. Environment variables and secrets are redacted prior to emission.

Honest Limitations & Explicit Non-Goals

Documenting limitations is an essential requirement of technical honesty. RTQ does not claim to solve these threats:

1. Compromised Operating System Kernel

RTQ delegates execution isolation to kernel mechanisms (Seatbelt on macOS, bubblewrap namespaces on Linux, AppContainer on Windows). If the host kernel has been exploited or backdoored, userland sandboxes can be bypassed.

2. Human Approver Inattention ("Rubber-Stamping")

Cryptographic challenge-response guarantees that an authorized device signed the operation nonce. It cannot guarantee that the human operator read or understood the side effects of the action before tapping approval.

3. Microarchitectural & Side-Channel Attacks

RTQ does not protect against speculative execution vulnerabilities (Spectre, Meltdown) or CPU cache timing attacks between processes sharing identical hardware cores.

4. Code Running Outside the RTQ Runtime

RTQ only governs operations that pass through rtq.authorize() and rtq.execute(). Host software that launches binaries directly without passing through RTQ cannot be constrained.

5. Supply Chain & Third-Party Audits

Security-critical RTQ packages currently declare zero third-party npm dependencies. However, zero npm dependencies does not eliminate all supply-chain risk (e.g. Node.js binary integrity, operating system utilities, compilers). RTQ has not undergone an independent third-party audit.

View Evidence Matrix →12 Tested Properties →