Security

RunMat Server's security boundary combines authenticated requests, tenant-aware authorization, project isolation, protected content storage, scoped service credentials, auditable mutations, and deployment hardening.

Shared responsibilities

RunMat enforces application identity, roles, project checks, and policy. Deployment operators remain responsible for TLS, OIDC configuration, network exposure, database and blob permissions, encryption and backup policy, secret rotation, monitoring, patching, and incident response. Project owners remain responsible for the code, packages, datasets, and Agent permissions they introduce.

Validate tenant context at every resource lookup. Authorization comes from the authenticated request context and policy decision. Use short-lived signed blob operations and prevent path traversal at the project filesystem boundary. Separate compute-node credentials, CI keys, and human sessions. Redact secrets and sensitive content from logs while retaining trace and audit identifiers.

Remote execution and Agent increase the executable-code surface. Isolate workers, restrict egress where required, inject secrets narrowly, and preserve reviewable source and run evidence. Send suspected vulnerabilities and sensitive reproductions through the security contact.

Authentication and request boundaries

Validate JWT signature, issuer, audience, expiry, and subject. Store API-key secrets as peppered message-authentication codes and expose the plaintext once. Construct request context in the authentication middleware and pass it into domain services. Domain services authorize that context for every resource; resource IDs, slugs, signed URLs, and client-supplied organization headers carry no independent access grant.

Rate limits use authenticated identity or a client IP resolved from a configured trusted-proxy model. Forwarded headers are untrusted unless the operator defines the proxy hops. Streaming endpoints authenticate at connection and enforce organization/project scope on every emitted signal.

Data protection

Use TLS for client traffic and encrypted transport to managed dependencies. Give Server separate least-privileged database and blob credentials. Signed upload/download URLs have short expiry, narrow method/object scope, and no general bucket authority. Normalize filesystem paths before policy or storage access and block traversal outside the project root.

Backups carry the same sensitivity as production. Encrypt them, restrict restore access, test restore, and document deletion/retention behavior. Key rotation plans must cover active Server instances, background jobs, and rollback windows.

Logs and audit

Application logs contain request IDs, trace IDs, stable resource IDs, result codes, and timings. They omit bearer tokens, API-key secrets, authorization headers, signed query strings, file bodies, prompts, model responses, and sensitive variable values. Hash or redact client identifiers according to deployment policy.

Audit records cover credential lifecycle, role and membership changes, SSO/SCIM administration, project lifecycle, policy overrides, package publication, snapshot restore, and remote worker administration. Audit storage needs controlled access and retention independent of debug-log sampling.

Executable workloads

Packages, project code, Agent edits, and remote jobs are executable inputs. Review package provenance, isolate worker processes, bound CPU/memory/disk, restrict mounts and egress, and provide run-scoped secrets. Keep the source revision, target, actor, and artifacts linked to the run for investigation.

For a vulnerability report, include affected version, deployment mode, impact, and a minimal private reproduction. Remove customer data and credentials, then send it to the published security contact.