Skip to content

Runtime Sentinel

Jump to bottom
Kairo edited this page May 25, 2026 · 1 revision

Runtime Sentinel

The Runtime Sentinel is Layer 5. It is Kairo's active watchdog — running alongside every request, monitoring the runtime state of application code, and acting on what it observes without interrupting the developer's logic.

Taint tracking

Every value that originates from user input — request body fields, query parameters, URL parameters, headers, file upload content, WebSocket messages — is tagged at the entry point with an invisible taint marker.

This marker propagates through every function call, variable assignment, and data transformation. If tainted data flows through five functions and three transformations before reaching a database query, the taint marker follows it the entire way.

When tainted data reaches a dangerous sink — a database query, a shell command, a file path, an HTML template, a redirect target, an eval call — the Sentinel checks whether the data has passed through a recognized sanitization function. If it has not, the Sentinel intercepts and neutralizes the operation.

The interception is silent:

  • The dangerous operation does not execute
  • The handler does not receive an exception
  • The attacker receives no error signal
  • A security event is logged
  • The session's entropy score rises

During development, the developer also receives an inline coaching message explaining what happened and showing the safer pattern.

What this protects against: SQL injection, command injection, path traversal, reflected XSS through server-rendered responses, open redirect attacks, and any other vulnerability class where the root cause is unsanitized user input reaching a dangerous operation.

Canary stack frames

Kairo inserts invisible synthetic frames into the JavaScript call stack at key points during request handling. These frames are structurally designed to detect specific classes of runtime attack:

Prototype pollution — modifications to Object.prototype or Array.prototype during request handling. These attacks typically arrive through deeply nested JSON payloads and can affect the behavior of all subsequent code in the process.

Stack smashing — attempts to unwind the call stack past expected boundaries, which can occur during certain deserialization attacks.

Eval injection — dynamic code evaluation (eval(), new Function()) where the source originates from tainted data.

Canary frames carry zero performance cost when nothing is wrong. They are inert under normal conditions and only fire when tampering is detected.

Hot-patch bus

The hot-patch bus is a signed update channel that allows security patches to be delivered to running Kairo instances without requiring redeployment.

When a vulnerability is discovered in a Kairo framework component, the Kairo team:

  1. Prepares a narrow, surgical patch that modifies only the affected framework behavior
  2. Signs the patch with Kairo's private key
  3. Publishes it to the patch channel

Running instances:

  1. Receive the patch notification
  2. Verify the cryptographic signature
  3. Apply the patch to in-memory framework behavior
  4. Log the patch application to the audit trail

What patches do and do not touch: Patches modify framework behavior only — the security layers, the entropy scoring algorithm, the taint tracking rules. They never modify application code. They are not software updates in the traditional sense; they are behavioral overrides applied to a running process.

Patch behavior is configurable per deployment:

  • channel: 'stable' — tested patches only
  • channel: 'beta' — early access
  • channel: 'off' — no automatic patches
  • autoApply: false — patches are listed and must be applied manually via kairo patch apply

Memory pressure alarms

The Sentinel monitors heap allocation patterns on a per-session basis. A sudden spike in allocations from a single session — consistent with:

  • ReDoS (Regular Expression Denial of Service) attacks
  • Billion laughs XML attacks
  • Memory exhaustion via deeply nested payloads
  • Other allocation-based DoS patterns

...triggers load shedding for that specific session before the Node.js process heap is affected. The session receives a plausible response (not an error). All other sessions continue operating normally and are unaffected.

What the developer does not need to do

Because of the Runtime Sentinel, a Kairo developer does not need to:

  • Manually sanitize user input before using it in queries, commands, or templates
  • Install or configure a separate injection detection library
  • Write logic to detect or respond to prototype pollution
  • Monitor memory usage per request to prevent DoS
  • Manage a vulnerability patch schedule and redeployment pipeline for framework-level CVEs

The Sentinel handles all of this transparently, in the background, for every request.

← Data Shield · Hardening Mode →

Clone this wiki locally