# Security

> Understand the trust boundaries and protections of the open-source runtime.

## Reporting a vulnerability

Report security issues privately through
[GitHub security advisories](https://github.com/labscommunity/cascadia/security/advisories/new),
not public issues. We'll acknowledge your report within a few days and keep
you updated on the fix.

## Threat model

Cascadia is designed to run on a trusted LAN, such as a rack of Intel AI PCs
on an isolated subnet. It isn't designed for the public internet. Hardening
covers malformed input, so bad requests can't cause panics or unbounded
allocations. It doesn't cover authentication or transport encryption.

### Built-in protections

* HTTP API: requests are limited by body size and rendered prompt size (both
  set by `--api-max-body-mb`, default 1 MiB) and by a 16-request concurrency
  limit. An oversized prompt returns 413, and a request over capacity returns
  503. Engine errors return 5xx responses instead of crashing the worker.
* Engine queue: the OpenVINO engines hold at most 256 pending tasks. Past
  that, requests return 503.
* TCP relay: tensor payloads are capped at 256 MiB and raw control messages
  at 64 KiB. Shapes are checked for overflow before allocating, and every
  receive times out after 60 seconds. A stalled or hostile peer can't tie up
  a worker thread or force a multi-gigabyte allocation.
* C++ shim: every exported function checks for null pointers, property
  dictionaries are limited to 256 pairs, and C++ exceptions are caught
  before they reach Rust. Tensor shapes are checked for overflow.
* Numerics: `argmax` handles NaN and logs a warning instead of silently
  returning token 0 after a broken forward pass. Rotary embeddings clamp
  `start` to 16M positions and `seq_len` to 1M tokens.
* Model registry (`cascadia-download`): writes are atomic (temporary file,
  fsync, rename), a symlink at the registry path is rejected, the file is
  capped at 16 MiB, and parse errors fail instead of being ignored.

### Not included

* TLS on the HTTP API or the inter-stage TCP relay
* Client authentication on the HTTP API
* mDNS authentication
* Supply-chain pinning beyond `Cargo.lock`

## Deploying beyond a trusted LAN

Put a reverse proxy that handles TLS and authentication in front of the
`--api` port. Firewall the inter-stage ports (`--listen` and `--next`) so
only the other workers in the pipeline can reach them.
