Security Overview

Architecture summary: 11 August 2026

Control model

• Explicit engagement, tenant, asset, job, and policy boundaries.
• Authorization and Rules of Engagement precede execution.
• Destructive actions are disabled by default and require explicit policy.
• Evidence is linked to execution context with timestamps and hashes.
• Findings require evidence and a human release gate.

Customer runner

The runner makes outbound control-plane connections and does not publish a runner service port. Credentials are bound to a tenant and runner; assignments are signed and bound to the intended runner; leases, cancellation, offline recovery, and capability checks constrain execution. Docker Compose and Kubernetes manifests are provided, including a restricted profile.

Data handling

Runner policies support local/findings-only behavior and controlled evidence or full-artifact upload where approved. Raw source and artifacts should remain in the customer environment unless the signed data-flow register permits transfer. Local tenant-aware secret storage uses AES-256-GCM authenticated encryption.

Production readiness boundary

A customer deployment is not production-ready merely because the code or container starts. Before use, RedCore and the customer complete TLS and identity configuration, secret provisioning, image and dependency review, tool licensing review, runner capability certification, egress and target controls, backup/retention decisions, emergency stop testing, and an acceptance exercise.

Current assurance

The repository includes automated runner, API, tenancy, evidence, policy, reporting, and deployment checks. Formal third-party certifications, penetration-test attestations, SLAs, insurance coverage, and regulatory mappings must not be assumed unless supplied in the executed procurement package.

Report a vulnerability

Follow the responsible disclosure process. Do not test RedCore infrastructure without written authorization.