Security design boundaries

Security is release and environment specific

These are design considerations, not a claim of certification, compliance, completed hardening, or production suitability. Runtime’s release-specific security controls have not been verified for publication here.

Separate trust zones

Identify callers, connector destinations, management tools, build systems, and operators. Define which identity each boundary uses and the minimum actions it needs. A public website should not hold Runtime credentials or offer execution through a browser.

For outbound integrations, define approved destinations and how name resolution, redirects, and internal addresses are handled. For inbound work, set payload limits and authentication ownership.

Protect sensitive material

Keep credentials out of source, URLs, copied snippets, and diagnostic output. Use isolated test identities and synthetic fixtures. Secret redaction must cover errors and retries as well as the success path.

Transport security needs trusted certificate validation, hostname verification, and a rotation procedure. Do not disable validation to make an example succeed.

Establish evidence before making claims

A release security reference should state the supported configuration, known limitations, tested protections, dependency audit date, and reporting process. No public vulnerability-report mailbox is configured yet; see contact availability.

AI tools add another boundary

A planned MCP tool should expose the smallest useful action and require appropriate review before changing a live system. Retrieved content should be treated as data, not authority. See MCP and Developer Skills.