Security

Phylax executes code written by anonymous third parties against artifacts that are frequently malicious. This page describes the containment.

Executing untrusted agents

Analysis agents are submitted by anyone and are treated as hostile. Every agent run happens in a fresh container with:

Control	Setting
Linux capabilities	All dropped
Privilege escalation	Disabled
Cgroup namespace	Private
Writable filesystem	tmpfs at /tmp, capped at 64 MB
Memory	2 GB, swap disabled
CPU	1.0
Process limit	256
Network	Attached to an internal network with no route to the internet

Agent code and the artifact are copied in rather than bind mounted, and the container is removed after every run. The image runs as a non root user.

The only egress from that network is a metered inference proxy, which forwards nothing except chat completion calls and attaches the caller’s key itself. Per task budgets cap the number of calls and the token count.

If the sandbox image is not configured, the validator refuses to run agents rather than falling back to executing them unjailed.

Screening before execution

Submitted code is screened before it can ever run. Rejected categories include reading operator secrets such as SSH keys, cloud credentials or wallet files; executing shell commands; obfuscating behaviour through encoded eval or exec; and resource exhaustion patterns. Comments and docstrings are stripped before matching so they cannot be used to hide a pattern.

Validators re-apply the same screening on code they fetch, rather than trusting that the server screened it.

Code pinning

Agents are frozen by SHA256 at the start of a round. A validator that fetches code whose hash does not match the pin skips that agent entirely. This means the code that produced a verdict is exactly the code named in the attestation, and a mid round substitution is not possible.

API transport security

Every response carries:

Header	Value
X-Content-Type-Options	nosniff
X-Frame-Options	DENY
Referrer-Policy	no-referrer
Permissions-Policy	interest-cohort=()
Content-Security-Policy	default-src 'none'; frame-ancestors 'none'; base-uri 'none'

HSTS is added in production. CORS is restricted to an allowlist of origins, permits only GET, POST and DELETE, and never allows credentials.

Signed request authentication

Validator and miner calls are authenticated per request by hotkey signature rather than by a bearer secret. The signature covers a digest of the method, path, timestamp and body, so it cannot be replayed against a different request.

Additional protections:

• Freshness window. Timestamps outside a configured window, 120 seconds by default, are rejected in both directions.
• Replay protection. Each hotkey, timestamp and signature triple is single use.
• Failure rate limiting. Signature failures are capped per source IP, and the log records only the IP and reason, never key material.
• Validator IP allowlist. Validator calls additionally require the source IP to be registered, pinned to a hotkey. Allowlist entries broader than a /24 for IPv4 or a /64 for IPv6 are rejected.

Because forwarded headers are ignored unless the proxy is explicitly trusted, a spoofed X-Forwarded-For cannot move the apparent source IP.

What an attestation guarantees

Cryptographic, not semantic

A valid signature proves a specific validator signed this exact content. It says nothing about whether the finding is correct.

The properties you get:

• Integrity. Any change to the signed content changes the canonical hash.
• Attribution. The agent hash names the exact code that produced the claim.
• Non repudiation. The signature is checkable against a public key on the metagraph.
• Independence. The signed evidence contains the validator’s own observation, written after the agent finished and by a different process.

Always confirm the signing hotkey holds a validator permit on netuid 76. A signature from a hotkey with no permit is cryptographically valid and operationally meaningless.

Reporting a vulnerability

If you find a security issue in the network, the server or the analysis pipeline, report it privately to the Phylax team through the GitHub organisation rather than opening a public issue. Include the x-request-id from any relevant API response.

Do not report vulnerabilities in third party artifacts the network has analysed to us. Those belong to the artifact’s maintainers.