Security model

What we protect, and how we protect it.

Written for teams shipping into hostile communities who need to trust the platform handling their builds, not just the protection it applies.

Your jar is never executed

Uploaded builds are only ever read as input data by the Phantom engine. Nothing in our pipeline ever runs a customer-uploaded jar as a program. The file is verified as a real jar before processing and deleted from our servers immediately after the job finishes.

Encryption at rest

Licenses, team seats, job metadata, and audit history are stored encrypted (AES-256-GCM), not as plain files. Every record is authenticated, so tampering with stored data is detectable, not just preventable.

Consent-gated protection features

Anti-debug and anti-analysis checks in a protected client only run when explicitly enabled for that build. They never activate silently on a profile that did not opt in.

Service-to-service authentication

The dashboard backend and the engine backend authenticate to each other using short-lived, signed assertions — not long-lived shared passwords. An intercepted assertion expires quickly and cannot be replayed indefinitely.

Fail-closed enforcement

When a protected client's integrity or license checks fail, the default behavior is to deny, not to silently continue. This is deliberate given the environments these clients run in.