Security Evidence & Verification
RTQ is experimental security infrastructure (Alpha). We replace marketing assertions with an unbroken evidence chain: Claim → Implementation → Test → CI Run → Platform/Commit.
CI Verification Disclaimer & Status
Green CI indicates that the repository's automated checks passed for a particular commit and environment. It does not constitute an independent security audit, formal mathematical verification, or guarantee that the implementation is free of vulnerabilities.
Rule of Claim Strength: The strength of a security claim must never exceed the strength of its evidence.
Verification Methodology
Every claim in RTQ documentation is tagged with an Evidence Level indicating the rigor of the verification behind it. We never describe a unit test as an OS enforcement proof.
Behavior is documented in architecture specifications but is not yet asserted by an automated test.
Isolated in-process logic is asserted by automated unit tests. Does not establish OS kernel containment.
Multiple RTQ pipeline components (registry, policy, ticket store) are exercised together.
Test launches the platform’s actual sandbox mechanism and verifies the OS rejects the tested unauthorized operation.
Explicit red-team or bypass payloads (symlink traversal, path tampering, replay) attempt to violate boundary.
Publicly verifiable audit report by a reputable third-party security firm. (RTQ has NOT yet been audited at Level 5).
12 Security Properties Tested in CI
These 12 standalone checks execute in tests/invariants/invariants.test.ts on every push and scheduled CI run. Below is the complete evidence mapping for each property.
Explicit surface: An unregistered capability is denied (no implicit surface).
Calling rtq.authorize() with an unregistered capability name returns decision: 'denied' with code 'capability.not_registered'.
Does not prove that registered capability handlers themselves are free of internal logic errors or memory corruption.
Explicit surface: A registered capability requested with the wrong version is denied.
Version numbers must match registered definitions exactly (integer equality check).
Does not verify schema migration safety or semantic version range compatibility across deployments.
Default-deny policy: No matching policy rule results in a denial, never an allow.
When the policy engine evaluates an operation against an empty or non-matching rule set, it yields decision: 'deny'.
Does not prevent human operators from inadvertently authoring overly permissive allow rules.
Authoritative risk: Caller claims to lower risk are ignored; declared risk takes precedence.
A caller passing metadata.claimedRisk = 'low' for a high-risk capability still triggers approval_required with risk = 'high'.
Does not prove the declared risk rating matches real-world exploitability or side effects of arbitrary commands.
Origin is a hint: Unknown origin is never treated as local and escalates approval requirements.
An untrusted origin 'unknown' is not granted automatic approval for low-risk capabilities.
Relies on host integration accurately passing caller origin identifiers without spoofing outside RTQ.
Approval strategy defaults: High or critical risk is never automatic.
Default approval strategy resolution for high or critical risk capabilities rejects automatic execution.
Operators can explicitly override defaults with custom policy rules if configured to do so.
Sandbox network deny-by-default: Generates --unshare-net and rejects unsupported allowlists.
Verifies bubblewrap command line construction unshares the network namespace and throws if network allowlist cannot be enforced.
This unit check does not execute live network sockets in kernel space (real network blocking is tested in macOS darwin.test.ts).
Sandboxed processes do not inherit ambient secrets matching sensitive key patterns.
buildSandboxEnvironment() strips environment keys matching 'secret', 'token', and 'API_TOKEN' from child processes.
Does not prevent child processes from reading secrets stored on accessible disk paths or over authorized sockets.
Single-use tickets: The second redemption of an authorization ticket is denied (replay rejection).
rtq.execute(ticketId) marks ticket redeemed; subsequent execution attempt with identical ticketId returns ok: false.
Relies on in-memory ticket store state within a single Node.js process; does not establish distributed cluster synchronization.
Tickets are replay- and tamper-resistant via HMAC-SHA256 signatures.
Modifying any ticket body attribute causes signature verification to fail prior to redemption.
Assumes the HMAC signing key is kept strictly confidential in host memory and never leaked.
Replacing a capability invalidates its previously issued, outstanding tickets.
Bumping capability version causes redemption of tickets issued for the previous version to fail.
Tickets for other unchanged capabilities remain redeemable until their standard expiration timestamp.
Approval substitution is rejected: An approval signed for challenge A cannot authorize challenge B.
Device approval signature bound to challengeId A is rejected when submitted against challengeId B.
Does not protect against an attacker with physical access to an unlocked approval device or compromised private keys.
Operating System Sandbox Evidence
Platform isolation claims are tested on their respective GitHub Actions runner operating systems in .github/workflows/sandbox.yml.
macOS (Apple Seatbelt): Kernel-level Seatbelt sandbox blocks unauthorized filesystem writes and network egress.
Executes /usr/bin/sandbox-exec live on macOS runner; verifies /usr/bin/touch fails to write outside allowed directory and /usr/bin/curl fails egress when network=none.
macOS Seatbelt is deprecated by Apple in modern macOS; this test does not prove resistance against local kernel privilege escalation.
Linux (bubblewrap): Generates correct bubblewrap argument vector with namespace unsharing and ro/rw binds.
Verifies argv construction includes --unshare-pid, --unshare-net, --unshare-user, --ro-bind for system dirs, and --bind for writable workspaces.
This test file verifies argument assembly and binary probing; it does not spawn a long-running adversarial rootkit payload in this test suite.
Windows (AppContainer): Windows runner script exits 1 on failure and output parser reports sandboxed: false if markers missing.
Verifies windows-runner.ps1 contains no bypass flags and that parseWindowsRunnerOutput correctly interprets AppContainer job markers.
Does not prove AppContainer integrity tokens prevent Win32 GDI or font driver elevation bugs on Windows.
Honest Security Contract
To maintain rigorous credibility, we separate what is built, what is tested, and what has explicitly not been established.
- • Explicit capability registration with JSON Schema checks.
- • Default-deny policy engine with declarative rules.
- • Authoritative risk calculation ignoring caller claims.
- • Single-use HMAC-SHA256 authorization ticket minting and consumption.
- • macOS Seatbelt profile generator & execution wrapper.
- • Linux bubblewrap namespace argument generator.
- • Windows PowerShell AppContainer runner script.
- • Redacted audit log emitter with HMAC integrity.
- • 12 automated invariants on ubuntu-latest in tests/invariants.
- • Replay rejection of consumed tickets (INV-09).
- • Override rejection of caller risk demotion (INV-04).
- • Approval substitution rejection (INV-12).
- • Real macOS Seatbelt file-write and network denial on macos-15 (OS-DARWIN).
- • Bubblewrap argument construction with namespace unsharing (OS-LINUX).
- • Windows runner fail-closed script contract (OS-WINDOWS).
- • Independent Security Audit: Not yet audited by third-party firm.
- • Formal Proofs: Automated tests are not mathematical proofs.
- • Compromised Kernel: Kernel rootkits can bypass OS sandboxes.
- • Side-Channel Resistance: No defense against microarchitectural timing leaks.
- • Out-of-Runtime Code: Code executing outside RTQ is unconstrained.
- • Blind Human Approval: Cannot force humans to read what they approve.
Active GitHub Actions Workflows
Workflows run on push to main and on pull requests: