/lyrik

name: lyrik
description: Security assessment of a codebase, minimal mode for runner validation
disable-model-invocation: true
permissions:
  tools:
    allow: [exec, read_file, write_file, list_files]
  egress:
    mode: deny
  filesystem:
    read_paths: ["<workspace>"]
    write_paths: ["<workspace>/.lyrik"]
  inference:
    allow: ["*"]

Lyrik (recon + multi-framing + scoring)

Run a security assessment of the codebase under `<workspace>` across two framings, `auth` and `injection`, and emit one finding per identified vulnerability per applicable framing. Each finding is scored across four axes by two independent passes. The runner aggregates the staging directory into the canonical `findings.json`.

Out of scope in this mode: Phase 0 (context document, separate rubric file), framings beyond `auth` and `injection`, two-pass framing union (the two passes here are *scoring*, not framing), three-pass scoring-disagreement gate and resolution, dedup, concentration index, gate-routed disclosed, exploit adapter. They return as separate slices.

Recon (mandatory, before any finding)

**Before emitting any finding, you must read at least one source file in scope, and every path you cite in `location.file` must be a file you have actually opened in this turn.** Inventing paths is the failure mode this section exists to prevent.

Recon steps:

1. **Read scope.** Open `.lyrik/config.json` if present; honor `scope.include` and `scope.exclude` glob lists. Otherwise treat the whole workspace as in-scope. Skip `.git/` and `.lyrik/` regardless.

2. **List files in scope.** Use `list_files(<dir>)` starting at the workspace root. For tiny workspaces (a handful of files), one `list_files(".")` suffices. For larger ones, descend into subdirectories whose names suggest content under either framing: auth-relevant (`auth/`, `session/`, `acl/`, `permission/`, `admin/`, `user/`, `login/`, `token/`, `crypto/`) or injection-relevant (`api/`, `handler/`, `parser/`, `eval`, `exec`, `shell`, `query`, files exposing string-interpolated commands or SQL).

3. **Read the candidate files** via `read_file(<path>)`. For tiny workspaces, read every source file. For larger ones, read at least one file matching each framing's heuristics. If `read_file` returns an error, pick a different file. Do not synthesize content; do not cite a path you couldn't read.

4. **Select which framings apply.** From what you read, decide which framings have signal in the codebase:

• **`auth`** activates if the code contains anything that affects who can do what, or how privileges propagate (callable surfaces with no per-caller authorization, hardcoded credentials, weak comparison of secrets, untrusted input folded into elevated-authority scope such as a system prompt, broken-by-default access posture).
• **`injection`** activates if the code contains an interpreter-shaped sink that can take attacker-influenced data (`eval`, `exec`, `shell=True` subprocess, dynamic SQL string concatenation, format-string-on-user-input, deserialization of untrusted data, command construction via string concatenation).
• Both can apply to the same file. Both can apply to the same line in different framings (e.g., `eval(user_input)` is an `injection` concern and is also an `auth` concern under "untrusted input inheriting elevated authority"). When the same line carries weight under both framings, emit one finding under each framing rather than picking one; the runner will see two findings sharing a `location` and that is the correct shape.
• If recon shows neither framing applies, stage no finding. Write the no-findings marker instead: `write_file(path=".lyrik/state/runs/<run-id>/staging/no-findings.json", content=<JSON object>)`. The object has `framings_checked`, the framings you checked (a non-empty list of strings), and `files_read`, the files you read (a non-empty list of strings). The marker is the only accepted way for a run to end with no findings; a run with neither findings nor the marker fails. Record the same absence in the journal's notes (see Run journal). Do not invent vulnerabilities to fill the output.

5. **Route each observed vulnerability to a `write_file` call, immediately.** When you observe a vulnerability matching an active framing, your next action is `write_file(path=".lyrik/state/runs/<run-id>/staging/findings/finding-NNN.json", content=<finding object>)`. Then continue to the next vulnerability or the next file. Do not list, summarize, describe, or annotate vulnerabilities in your assistant message; every vulnerability is a `write_file` call, no exceptions.

Recon's only artifacts are the file paths, line ranges, and framing assignments cited inside the staged finding objects. No separate context document, no per-component history. Those return in later slices.

Override feedback (fire-once)

If your invocation prompt carries feedback from a prior run or an external reviewer (for example, "the prior recon missed X, focus on Y this round"), treat it as authoritative scoping for THIS run only:

1. Read the feedback before recon. 2. Let it override recon defaults. If the feedback names a file or framing to focus on, prioritize that over the heuristics in Recon step 2. 3. Do not re-inject the feedback into your reasoning across multiple turns within the run. The feedback applies once, at the top of the working set. 4. The feedback is not carried into future runs. Each invocation starts fresh; the runner does not persist override feedback between runs.

Absent such feedback in the invocation prompt, proceed directly to recon.

Framings

`auth`

Anything that affects who can do what, or what privileges propagate without verification. Worked classes: missing access check before a privileged operation; hardcoded credentials; weak comparison (`==` of secrets); broken-by-default permission posture; untrusted input inheriting elevated authority (e.g., user-controlled string folded into a system prompt scope); too