# Why the Tool Grants Look Like That

Background for the `allowed-tools` block and step 1-C of `perform-security-review`. The
operative rules are in `SKILL.md`; this file holds the reasoning.

## A `*` in a Bash rule absorbs whole flags

This is the fact everything below rests on, and it is easy to get wrong. A rule containing `*`
is compiled to an anchored regular expression with each `*` replaced by `.*` under the `s` flag.
`.*` therefore spans spaces, quotes, and entire arguments — it does not stop at a path
separator, a word boundary, or a closing quote.

So a rule cannot pin "this argument is the endpoint and nothing else may follow." Wherever a
`*` appears, an attacker-influenced command can insert flags into it and satisfy the literal
part of the pattern from inside a later argument.

Concretely, this rule looks endpoint-scoped and is not:

```
Bash(gh api --method GET -H "X-GitHub-Api-Version: 2026-03-10" "repos/*/*/code-scanning/alerts?*)
```

It compiles to:

```
^gh api --method GET -H "X-GitHub-Api-Version: 2026-03-10" "repos/.*/.*/code-scanning/alerts\?.*$
```

and matches all of these:

| command                                                                                            | effect              |
| -------------------------------------------------------------------------------------------------- | ------------------- |
| `gh api --method GET -H "…" "repos/O/R/code-scanning/alerts?state=open" --jq '.[]'`                | intended            |
| `gh api --method GET -H "…" "repos/O/R" -X DELETE --jq '"/code-scanning/alerts?y"'`                | `DELETE /repos/O/R` |
| `gh api --method GET -H "…" "repos/O/R" --method DELETE --template '{{.}}/code-scanning/alerts?z'` | `DELETE /repos/O/R` |

The second `*` swallows `R" -X DELETE --jq '"`, and the required literal
`code-scanning/alerts?` is satisfied inside the `--jq` program. `gh` resolves `--method` and
`-X` last-wins, so the request that goes out is a `DELETE` — and `DELETE /repos/{owner}/{repo}`
deletes the repository.

## So `gh api` is not granted at all

There is no `gh api` rule in `allowed-tools`. No pattern could be written that constrains the
verb, and this skill's entire input is a diff an attacker may have influenced, so a rule the
model is merely asked to follow is not a control. Step 1-C's two `gh api` scan-evidence calls
(secret scanning and Dependabot) therefore prompt, and in CI they are denied. Step 1-C's Aikido
call does not go through `gh api`, so it is unaffected.

That is a real capability loss: GHAS evidence is unavailable on the unattended path unless the
deployment grants it. **The control at that level is the token, not a permission rule** — run
the workflow with a read-only `GH_TOKEN` and minimal `permissions:`, and the destructive verb
is unavailable no matter what command is composed. A deployment that has done that can add its
own narrow allow rules with the residual risk understood.

Step 1-C is written to degrade rather than fail: each scanner records its own outcome, and for
the two `gh api` scanners a denial is recorded as `Not checked (permission denied)` so it never
reads as `None`, which would say the scanner ran and found nothing. Aikido cannot reach that
state — its grant is pre-approved, so the call never prompts and is never denied.

## Why the default-branch lookup does not use `gh api`

The endpoint that answers it is `repos/{owner}/{repo}`, whose `DELETE` deletes the repository,
so candidate 2 uses `gh repo view --json defaultBranchRef` instead. `gh repo view` has no
`--method` or `-X` flag at all, so the last-wins problem cannot arise. This is the general
shape of the fix: prefer a subcommand that cannot express the dangerous operation over a rule
that tries to forbid it.

## Why the `rm` grant went too

`Bash(rm -f /tmp/security-review-*)` was kept at first on the reasoning that a cleanup step
is lower stakes than an API call. That reasoning was wrong in the same way the `gh api` rules
were: the `.*` absorbs flags, not just path characters, so
`rm -f /tmp/security-review-x -rf <any-path>` matches the rule and is a recursive tree delete. The identifiers are chosen per run, so no literal rule can enumerate
them. The grant is gone. Step 7 clears the diff with the granted `Write` tool instead, which is
the better answer anyway: it removes the content without needing a shell at all, and it runs
unattended. The file stays on disk, empty.

## Why the `git` grants stay

`Bash(git diff:*)` and `Bash(git log:*)` both accept `--output=<file>`, verified, so a prefix
rule over either is an arbitrary-file-write primitive. They are kept anyway, and the reason is
specific rather than general: this skill already holds `Write`, so the capability adds nothing
an attacker-steered run could not already do. Removing them would cost the skill its diff and
leave the exposure unchanged. That argument does **not** extend to a grant whose flag reaches a
capability the skill lacks — which is exactly why `gh api` and `rm` went.

`Bash(git branch --show-current:*)` is not in the same class. `git branch --show-current -D <br>`
is a usage error and deletes nothing, so the prefix does not admit branch deletion.

Every future grant here should be reasoned about the same way: by what an inserted flag can do
inside each `*`, never by how specific the pattern looks.