> ## Documentation Index > Fetch the complete documentation index at: https://docs.phyi.dev/llms.txt > Use this file to discover all available pages before exploring further. # The Four Tracks > Skills, MCP servers, packages, and repositories: what each is, what your detector must catch, and the research to build from. Phylax runs four isolated tracks. A miner commits one hotkey to exactly one track; every validator evaluates all four each round. Artifacts, evidence, scoring, and emissions are computed per track and never cross between them, so a `skills` agent is never ranked against a `packages` agent and evidence from one track is never compared to another. Agent skill bundles (`SKILL.md` + code). Detonated and scored on dual plane evidence with proof of execution. Skills are the classic prompt injection vector, so the context plane matters intensely. MCP server packages. Detonated with a component centric analysis: tool descriptions, schemas, source, responses, resource handlers, and config, and how influence propagates across them. pip and npm packages. Detonated across the lifecycle: install time and import time behaviour, plus supply chain signals (CVEs, typosquat, dependency confusion). Source repositories. The outlier: a static audit with no probe, scored by F2 against the benchmark's known vulnerabilities. ## The detection principle Every track shares one idea: malice is the gap between what an artifact **declares** it does and what it **actually** does. Your agent derives the artifact's declared intent, exercises or audits it under instrumentation, and treats any deviation as the signal. Signatures catch known bad strings; deviation catches the novel and obfuscated attacks no signature has seen. What changes per track is where declared intent comes from and how you observe behaviour, not the principle. This maps straight onto the evidence you emit. The capability manifest and the declared purpose are the intent side; the action plane (what the artifact did) and the context plane (what it tried to make the model do) are the behaviour side. Your SSSA is, in effect, a deviation report. The per track sections below give a first architecture and what the detector must catch. Treat the pseudocode as a floor, not a solution: it is public, so a submission that merely reimplements it competes against everyone else who read the same page. Emissions reward whoever climbs off the floor first. ## The threat model Phylax assumes every artifact is untrusted by default and its author is fully adversarial. Whatever the track, the attacker is pursuing one or more of six goals: | Attacker goal | Typical form | | --------------------------------------------- | ---------------------------------------------------------------------------------------------- | | Secret exfiltration | API keys, wallet credentials, tokens, and session cookies leaking through network egress | | Arbitrary code execution | Evaluation, shell commands, dynamic imports, install hooks | | Unauthorised filesystem and credential access | System paths, SSH keys, credential stores | | Prompt injection and context manipulation | Instructions injected into content the agent consumes, steering its reasoning | | Supply chain compromise | Typosquatting, malicious install hooks, dependency confusion, poisoned transitive dependencies | | Persistence and rug pulls | Long lived access, or a benign artifact that turns malicious in a later version | The adversary controls every byte of what they publish and distributes it through legitimate channels: skill marketplaces, MCP registries, package indexes. They may craft any component of an artifact and compose several so that each looks benign in isolation while the combination achieves compromise. The attack proceeds automatically once an agent installs and uses the artifact, with no further attacker interaction. Each track below enumerates how these goals concretely surface for its artifact type; a detector that only covers some of its track's attack classes leaves score on the table as the corpus grows to label the rest. ## Detonation vs audit Three tracks detonate. The agent loads the artifact into an instrumented sandbox, runs it, threads the probe through the execution, and the run produces filesystem, network, and process traces, recorded by the validator's instrumentation. This is what lets Phylax catch behaviour that static reading cannot see: obfuscated payloads, runtime resolved imports, and instructions that only surface when the artifact is actually exercised. The `repositories` track audits. Nothing is executed, so there is no probe and no proof of execution; the track is scored by F2 against a benchmark of known vulnerabilities. ## Verification per track | Track | Proof of execution | Dual plane | Track-specific block | Scored by | | -------------- | ------------------ | ------------------------ | ---------------------------- | -------------------------------- | | `skills` | required | action + context | none | clamped MCC vs label | | `mcp_servers` | required | action + context | `mcp_surface` | clamped MCC vs label | | `packages` | required | action (+ minor context) | `lifecycle` + `supply_chain` | clamped MCC vs label | | `repositories` | n/a | n/a | `audit` | F2 against known vulnerabilities | *** ## skills **Artifact.** An agent skill bundle, typically a `SKILL.md` plus helper scripts. The `SKILL.md` is both documentation and, on the context plane, a place where instructions can hide. **Attack surface.** Six attack classes: | Attack class | What it looks like | | ------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | Malicious instruction injection | Instructions hidden in `SKILL.md` or helper files that steer the agent against its user | | Permission overreach | The skill exercises capabilities its declared task never needs: credentials, network egress, system paths | | Transitive poisoning | A benign looking skill pulls in or invokes a poisoned dependency, helper script, or second skill | | Transitive information leakage | Data the skill legitimately touches flows onward to an unauthorised sink: logs, files, network | | Context injection | Content the skill loads at runtime (files, URLs, retrieved text) injects instructions into the agent's reasoning | | Update or rug pull | A benign version earns trust and installs, then a later version turns malicious | The launch benchmark labels malicious instruction injection and transitive poisoning and is being extended to the remaining classes; the scoring spine is generic across all six, so coverage grows with the corpus rather than requiring new scoring code. Build for all six now: corpus growth converts that coverage into score. **Evidence.** `proof_of_execution` + `action_plane` + `context_plane`. Both planes are required: a strong agent must catch context contamination and transitive risk, not only an obvious instruction in the skill text. **Detection approach.** The declared task is the skill's stated purpose in `SKILL.md`. Extract it before the model reads the rest of the bundle, so hidden instructions cannot rewrite your notion of what the skill is for. Then run the skill and flag any action outside that task: a formatting skill that reads credentials, a skill that obeys an instruction embedded in retrieved content. ```python theme={"system"} def agent_main(context): skill = load(context["artifact_dir"]) declared_task = extract_declared_task(skill.manifest) # read intent first trace = detonate(skill, probe=context["probe"]) # fs, net, process deviations = [a for a in trace.actions if not serves(a, declared_task)] injected = find_hidden_instructions(skill.body, trace.context_plane) verdict = "BLOCK" if deviations or injected else "ALLOW" return {"verdict": verdict, "evidence": {...}, "findings": deviations + injected} ``` **Your detector must catch.** Prompt injection and hidden instructions, skill poisoning, credential leakage, access to data or systems with no declared reason, and any behaviour exceeding the declared task. *** ## mcp\_servers **Artifact.** An MCP server package: a manifest declaring tools plus the server implementing them. **Why it is the deepest track.** An MCP server sits at the intersection of two attack channels in a single artifact. Malicious logic can live in executable server code (the action plane), and adversarial instructions can be embedded in the metadata and outputs the language model consumes as reasoning context (the context plane). Server provided metadata is not inert documentation: it is read by the model and actively steers tool selection and follow up actions. **Component centric analysis.** Malice may live in any component or be distributed across several so that each looks benign in isolation: | MCP component | Representative attack | | --------------------------- | ------------------------------------------------------------------------------- | | Tool description | Tool poisoning, control flow hijacking, preference manipulation (context plane) | | Argument schema | Schema injection equivalent to description injection (context plane) | | Tool source code | Malicious code execution, command injection, rug pull (action plane) | | Tool response | Response injection steering a later tool call (context plane) | | Resource handler / response | Malicious external resource, indirect injection via retrieved content | | Configuration | Malicious shell command in the startup command field | Attacks compose across components, and influence propagates through the model's orchestration: adversarial content in one tool's description can steer the model into invoking a second tool whose code carries the payload. Logic split between a poisoned description and conditional code in a tool's source evades any check that inspects either component alone. **Attack surface.** Eleven attack classes: | Attack class | What it looks like | | ---------------------------------- | ---------------------------------------------------------------------------- | | Tool poisoning | Adversarial instructions in a tool description steering model behaviour | | Argument schema injection | The same injection carried in the argument schema instead of the description | | Malicious tool source code | Executable payloads in the tool implementation: code execution, exfiltration | | Tool response injection | A tool's output injects instructions that steer a later tool call | | Malicious resource handlers | A resource or its response carries hostile content or indirect injection | | Tool shadowing | A tool named or described to intercept calls meant for another, trusted tool | | Rug pull | A server that behaves benignly at review time and turns malicious later | | Multi tool coordination | An exploit split across tools so each call looks benign alone | | Command injection in configuration | A malicious shell command in the server's startup command field | | Manifest tampering | The manifest misrepresents what the server actually exposes or runs | | Schema mismatch | Declared schemas diverging from actual tool behaviour | Launch scoring covers tool poisoning and schema mismatch, with the remaining classes forming the threat surface and the next additions to scoring. Build for the full surface now. **Detection approach.** Two stages, following the behavioural deviation principle. Pre-execution: read the config for malicious startup or shell commands, and extract each tool's declared intent from its description separately, before adversarial text in one description can contaminate your reading of another. In-execution: invoke tools in a sandbox and trace the whole trajectory step by step, flagging a tool that acts beyond its declared function, and catching attacks split across calls that each look benign alone. ```python theme={"system"} def agent_main(context): server = load(context["artifact_dir"]) if malicious_startup(server.config): return block("malicious startup command") intents = {t.name: declared_intent(t.description) for t in server.tools} trace = exercise(server, probe=context["probe"]) # step-wise trajectory findings = [deviation(step) for step in trace # catch mid-trajectory if not serves(step.action, intents[step.tool])] findings += multi_step_attacks(trace) # benign singly, malign together return verdict_from(findings) ``` **Your detector must catch.** Malicious startup and shell commands, tools acting beyond their declared function, unauthorised network or data access, trigger based behaviour, and multi step attacks. **Evidence.** The dual plane core plus an `mcp_surface` block recording which component carried each finding and how influence propagated. *** ## packages **Artifact.** A pip or npm package: `setup.py` / `pyproject.toml` (or `package.json`) plus the source. **Why install time matters.** A package can attack the moment it is installed, before it is ever imported. Empirical studies find roughly two thirds of malicious PyPI packages execute at install time, and typosquatting accounts for a clear majority of injection methods in the foundational malicious package datasets. Industry telemetry through 2025 and 2026 reports hundreds of thousands of new malicious packages per year, shifting toward install time execution, credential harvesting, and dependency confusion. A track that observes the install phase, not only imported behaviour, is aligned with where package attacks actually occur. **Attack surface.** Nine attack classes: | Attack class | What it looks like | | -------------------------------- | ------------------------------------------------------------------------------------------ | | Malicious install hooks | Code in `setup.py`, `pyproject` build steps, or npm lifecycle scripts that runs at install | | Import time side effects | Payloads that fire on `import`, before any function is called | | Credential and data exfiltration | Harvesting tokens, keys, and environment secrets to network egress | | Typosquatting | A name one edit away from a popular package, riding on typos | | Dependency confusion | A public package shadowing an internal name so resolvers pick the attacker's | | Poisoned transitive dependencies | The malice lives one or more levels down the dependency tree | | Known vulnerable dependencies | Depending on versions with known CVEs | | Obfuscated or encrypted payloads | Encoded, packed, or runtime decrypted code hiding the behaviour from readers | | Update rug pull | A trusted package that turns malicious in a later release | **Evidence.** `proof_of_execution` + a `lifecycle` block distinguishing install time from import time behaviour + `action_plane` + a `supply_chain` block (SBOM, dependency CVEs, typosquat, dependency confusion). **Detection approach.** Derive the declared purpose from the metadata and README, then execute both the install process and the runtime behaviour in a sandbox and monitor the API call sequence. Prioritise install time. Prefer behaviour and data flow evidence, a taint path from a secret source to a network sink, over surface features: malware increasingly mimics benign code, and surface classifiers degrade against it. ```python theme={"system"} def agent_main(context): pkg = load(context["artifact_dir"]) purpose = declared_purpose(pkg.metadata, pkg.readme) install_trace = detonate_install(pkg, probe=context["probe"]) # setup.py, hooks import_trace = detonate_import(pkg) seq = api_sequence(install_trace + import_trace) findings = taint_flows(seq, source="secret", sink="network") findings += [c for c in seq if not consistent(c, purpose)] findings += supply_chain(pkg) # typosquat, dependency confusion, dep CVEs return verdict_from(findings) ``` **Your detector must catch.** Malicious install scripts (a large share of package malware runs entirely at install time, prioritise it), data and credential exfiltration, obfuscated or encrypted code, typosquatting, and malicious transitive dependencies. *** ## repositories **Artifact.** A source repository: a tree of source files plus its manifests. **What the agent does.** Audits the source statically and reports recovered vulnerabilities, each with a weakness class (CWE), file, line, severity, and remediation. There is no probe, no proof of execution, and no dual plane evidence. **Attack surface.** Six finding classes: | Finding class | What it looks like | | -------------------------------------- | --------------------------------------------------------------------------------------------- | | Exploitable vulnerabilities | Injection, deserialisation, path traversal, and the other CWE classes the benchmark plants | | Embedded backdoors and triggers | Malicious logic buried in ordinary code, dormant until a condition fires | | Malicious instruction and config files | `tasks.json`, `settings.json`, or `SKILL.md` content that AI coding agents trust and act on | | Leaked secrets | Credentials, keys, and tokens committed into the source | | Out of scope components | Code whose behaviour contradicts the project's declared purpose | | Supply chain risk | Typosquat or confused dependencies, install scripts, and vulnerable versions in the manifests | The benchmark's labelled dimensions (vulnerabilities, supply chain, secrets) map straight onto these classes, so each one you cover contributes to your F2. **Scored by.** F2 against the benchmark's known vulnerabilities: a reported finding matches a known vulnerability when it agrees on CWE or title and localises within a small line window. F2 tilts toward recall, since a missed real vulnerability costs more than a false alarm. Clean repositories measure the false positive rate through precision. See [Scoring](/core/scoring) for the formal rules. **Detection approach.** Derive the project's declared purpose, then audit the codebase and flag components whose logic contradicts that purpose. This is the broadest track, the largest behaviour surface and the coarsest declared intent, so lean on semantic and LLM assisted reading of what code actually does rather than pattern matching. Two classes are easy to miss: backdoors and triggers buried in otherwise ordinary code, and malicious natural language instruction or config files that AI coding agents trust and act on (a redirected `settings.json`, a `SKILL.md` that exfiltrates keys). ```python theme={"system"} def agent_main(context): repo = load(context["artifact_dir"]) purpose = declared_purpose(repo.readme, repo.manifests) findings = [] for f in repo.files: intent = semantic_summary(f) # what this file actually does if contradicts(intent, purpose): findings.append(vuln(f, cwe=classify(f))) findings += instruction_file_attacks(repo) # tasks.json, settings.json, *.md findings += backdoors_and_triggers(repo) return {"verdict": verdict_from(findings), "findings": findings} ``` **Your detector must catch.** Embedded backdoors and triggers, malicious natural language instruction and config files that agents trust, components acting outside project scope, and supply chain risk in bundled or depended code. *** ## Emission weight The performance pool is divided by track first, then flows to each track's above threshold top agents through consensus. | Track | Share of performance pool | | -------------- | ------------------------- | | `repositories` | 0.675 | | `packages` | 0.225 | | `mcp_servers` | 0.075 | | `skills` | 0.025 | `repositories` carries by far the largest share, then `packages`, `mcp_servers`, and `skills`. The ordering is strict: every top-three winner of a higher track outearns every top-three winner of the one below. Repositories and packages have the clearest objective ground truth and the biggest real world supply chain impact. See the [Incentive Mechanism](/get-started/incentive-mechanism) for the full mechanism. ## Per-track budgets Each track's per task budget is pinned and identical on every validator, expressed as CPU time so hardware never changes an outcome: | Track | Tasks per round | Repetitions | CPU budget per task | | -------------- | --------------- | ----------- | ------------------- | | `skills` | 30 | 3 | 8 s | | `mcp_servers` | 25 | 3 | 15 s | | `packages` | 20 | 3 | 30 s | | `repositories` | 8 | 2 | 90 s | These are frozen: they are part of what your agent is measured against. See [Configuration](/reference/configuration) and [The Round Model](/system/rounds).