Permission Policies

Implement the Permission Policies pattern in this codebase, using the LLM client and language we already use.

## Goal

Put a policy check between an agent and its tools, so every proposed call is allowed, escalated to a person, or denied by declarative rules, and the run stops when a spend or step budget is used up.

## How it works

1. Load the policy from a config file: ordered deny, ask and allow rules, each a tool name plus an optional argument pattern, and a budget with a spend cap and a step cap.
2. Run the agent with the Agent prompt with a permission policy, which tells it that some calls may be denied or need approval and how to react.
3. When the agent proposes a tool call, deny it at once if its tool is not declared in the policy. Otherwise match it against the rules in the order deny, then ask, then allow; a declared tool whose arguments match no rule goes to ask.
4. On allow, run the tool and return its result to the agent. On deny, do not run it; return an error naming the rule that matched, and count the denial as a step toward the step cap.
5. On ask, send the person a message built from the Approval request message and wait up to a timeout (default 10 minutes). Run the tool only if they approve. A rejection, a timeout, or a run with no person attached is a denial, reported to the agent like any other.
6. Keep one budget meter for the run: add the agent's own model-call spend after each turn and each tool call's estimated cost before it runs. If the next call would pass the spend or step cap, stop the run instead of calling the tool.
7. Record every decision (the call, the matched rule, the verdict, who approved it and the running spend) in an audit log.

## Prompts

### Agent prompt with a permission policy

```markdown
You are a coding agent working in {{repo}}. Your task:
<task>{{task}}</task>

Every tool call you make is checked against a permission policy before it runs.
- Some calls run at once. Some need a person's approval, so say why you need them;
  if nobody answers in time, the call is denied.
- Only the tools listed for you exist. Calls to any other tool are denied.
- A denied call returns an error naming the rule. Do not retry it or try to
  reach the same effect another way; find a different approach or explain
  why the task cannot be finished.
- The run has a budget of {{budget}}. Prefer cheap, read-only calls first.

Before each call that changes anything, write one line saying what it will
change and why it is needed.
```

### Approval request message

```markdown
**The agent wants to run a call that your policy marks as "ask".**

Tool: `{{tool_name}}`
Arguments: `{{arguments}}`
Matched rule: `{{rule}}`
Agent's reason: {{rationale}}
Spent so far: {{spent}} of {{budget}}

Reply approve or reject within {{timeout}}. A rejection is passed to the agent
with your reason; no reply in time counts as a rejection.
```

## Stop rule

Stop when the agent returns a final answer, or when the spend or step cap is reached (denials count as steps). On a cap, return the partial work with a status naming the cap. An unanswered ask never blocks the run: it times out as a denial.

## Requirements

- Keep the policy in data (a file or a table), not in prompt text, and never let the agent change it.
- Evaluate deny before ask before allow, so a broad allow rule can never override a specific deny.
- Fail closed: deny any tool not declared in the policy, send a declared tool with unmatched arguments to ask, and turn an ask that times out or has no person to answer into a deny. Never fall through to allow.
- Match rules on the parsed tool name and arguments, not on the raw text, so that 'git status; rm -rf ~' does not match an allow rule for 'git status'.
- Test with no approver attached and rules allow 'git status', deny 'rm *', npm declared with no rule: a stub LLM proposes 'git status', 'rm -rf /', 'npm install x' and the unlisted http_post. Assert the shell ran once, three denials came back, and 4 steps were counted.