$ neti propose -r d.ndjson
[exit 0]
Proposed ceilings, derived from YOUR observed traffic.

These are a starting point for review, not a configuration. Edit the numbers, then paste
them into your policy file. Nothing here is applied automatically and nothing computed
here is ever read at decision time — the gate only ever compares against numbers you
committed.

send_email /to:
  observed  n=40  p50=25  max=41,203  [recipients]
  proposed  confirm above 50   block above 500
  rationale 2x and 10x the observed p50 (25). p95 was 41,203 here — your large calls are more than 5% of the traffic, so they *are* the p95, and multiplying it proposes a ceiling above everything you have ever done. Anchored on the median instead; expect a higher interrupt rate. The observed maximum (41,203) is far beyond this ceiling — check that it was intended
  IMPACT    over the observed window this would have blocked 4 call(s) and asked about 4
            largest affected: 41,203, 41,203, 41,203 recipients

# merge these bands into the gates you already have, keeping each
# existing `resolver:` line, once you are satisfied with the numbers:

tools:
  send_email:
    gate:
      /to:
        bands:
          - { above: 50, verdict: confirm }
          - { above: 500, verdict: block }

Not enough traffic to propose a cumulative budget for:
  recipients per day — only 1 day(s) observed; 5 needed before a cumulative ceiling means anything. Keep observing.
  recipients per session — only 1 session(s) observed; 5 needed before a cumulative ceiling means anything. Keep observing.

──────────────────────────────────────────────────────────────────────────────

Provenance — the axis this command will not propose for you.

A prompt injection is small at both ends: the ingest is one support ticket and
the payload can be one file. No ceiling reaches it. What does is one mechanical
question — *has this session already read something you declared untrusted?* —
which an attacker cannot write the answer to. The injected text can claim
anything; it cannot change that the session read customer_data/ two calls ago.

Every other number here came from your traffic or your disk. This one cannot:
whether `uploads/` holds a stranger's files or your build output is a fact about
your business, not your filesystem. So the patterns are yours to write. The shape:

  provenance:
    untrusted: ["**/customer_data/**", "https://forum.example/**"]
    tools: ["mcp__scraper__*"]      # a whole MCP server, whatever it grows
    bands:
      - { above: 50, verdict: confirm }   # applied ON TOP of each gate's own bands

Escalate-only, so a pattern written too widely costs a confirmation and never a
silent allow. A call cannot taint itself: reading the first ticket is an ordinary
read, and the tightening applies from the next call onward.
