Weekly security audit
Review a repository and its exposed surface for newly introduced risk, every week, with evidence.
A security audit is the clearest case for a routine: it matters every week, it is easy to postpone, and its value comes from noticing what changed rather than restating what has always been true.
What you get: a prioritised brief with evidence, severity, ownership, and recommended next actions — and no unapproved changes to the repository.
Prerequisites
- A GitHub connection with the
reposcope. - A tool-capable model. See Models.
Configure it
Start from the template
Routines → New routine → Weekly security audit. The template ships with a
suggested schedule of 0 9 * * 1 — 09:00 every Monday — and one variable.
Set the variable
| Key | Example | Why it is a variable |
|---|---|---|
repository | acme/web-app | The instructions stay identical across repositories. |
Reference it in the instructions as {{repository}}.
Sharpen the instructions
The template's instructions are a starting point. The three edits that matter most:
- Define "new." Say what window counts — "changes merged since the last Monday" beats "recent changes," which the model has to guess at.
- Demand evidence. Require a file path and line reference, or a commit, for every finding. Findings without a citation are opinions.
- Forbid remediation. This routine reads. If you want it to open pull requests, that is a deliberate second grant — see SEO audit that opens a pull request for the shape of a routine that writes.
Approve the minimum tools
Discover tools on the GitHub connection, then enable only what the audit needs to read: repository contents, commits or pull requests for the window, and security findings if you have them.
Leave every write tool disabled. See Tool permissions.
Prove it, then activate
Run it once by hand and read the trace. Check that the tool_call steps
actually fetched the window you asked for, and that the run finished
comfortably inside maxSteps.
Tuning
- Too much noise. Ask for a maximum number of findings, ranked. A brief that lists forty issues gets skimmed; one that names the five that changed gets fixed.
- Repeating the same finding weekly. Add an instruction to state whether each finding is new, unchanged, or resolved since the previous run. The model cannot see prior runs, so tell it what the prior state was through a variable, or accept that "new" means "new in the diff window."
- Runs hitting
step_limit. Large repositories need either a narrower scope (one directory, one service) or a higher step ceiling — up to 25.