Ai Cost Guardrail Designer

---
name: ai-cost-guardrail-designer
description: Design cost and consumption guardrails for a large language model (LLM) feature, covering spend and unbounded-consumption abuse (Open Worldwide Application Security Project identifier LLM06). Specify token caps, per-user/tenant/plan budgets, cost-aware rate limits, task-aware model choice, concurrency and queue bounds, agent loop limits, input limits, a fail-closed spend kill switch, degraded fallback, and telemetry. Compose saas-cost-architect for unit economics and observability-operator for metering. Use for budgets, quotas, rate limits, token drain, denial of wallet, or stolen-key model abuse. Do NOT use for whole-product cost models, plan feature gating, alert implementation, or model routing.
---

# AI Cost Guardrail Designer

**Reading key:** A large language model (LLM) generates responses using
metered tokens. Open Worldwide Application Security Project (OWASP) code
LLM06 (2026 edition; LLM10 in 2025) names unbounded consumption. Common
Weakness Enumeration (CWE) item 636 describes a control that fails open instead of securely denying a call.
An application programming interface (API) is a software call boundary;
continuous integration (CI) runs automated checks. “LLMjacking” means abuse
of a stolen model-provider credential to consume the owner's allowance.
First in, first out (FIFO) is a queue order that serves earlier arrivals
before later ones. Denial of wallet means forcing the owner to pay for
excessive model use; denial of service means making the feature unavailable.

## Purpose

Design the guardrails that keep an LLM feature from becoming a denial-of-wallet
or denial-of-service vector (LLM06) and keep its spend attributable and
bounded. The deliverable is a layered control set: per-request token caps,
per-user/tenant/plan budgets and rate limits, task-appropriate model
selection, concurrency/queue bounds, agent loop limits, input-size limits, a
kill switch, a degraded-mode fallback, and telemetry that alerts BEFORE the
budget is exhausted. Two disciplines run through all of it: every guardrail
must FAIL CLOSED — a cost/rate/budget check that errors DENIES the call, or it
becomes the denial-of-wallet vector it was meant to stop (CWE-636) — and a
STOLEN provider credential (LLMjacking) turns your own account into the
attacker's, so key custody and per-model restriction are in scope. Unit
economics come from `saas-cost-architect` and the metering implementation from
`observability-operator`; key-custody mechanics defer to
`secrets-identity-hardener` and the general fail-closed discipline to
`error-handling-security-reviewer`. This skill composes all four and focuses on
the guardrail design. `observability-operator`, `secrets-identity-hardener`
and `ai-router-architect` are manual-only: this skill names the handoff, and a
person runs that skill by name; it is never invoked automatically.

## Use When

- Use when: adding token caps, budgets, quotas, rate limits, or concurrency
  limits to an artificial intelligence (AI) feature.
- Use when: defending against unbounded consumption — token-drain,
  denial-of-wallet (attacker makes you spend), context stuffing, agent
  loops, retry storms.
- Use when: a request-count rate limiter is not stopping cost abuse, or a
  stolen/leaked provider key (LLMjacking) could run up your inference bill.
- Use when: an AI feature's cost is unpredictable or a spend spike already
  happened and needs structural controls.
- Do NOT use when: modeling the whole product's cost drivers and unit
  economics — `saas-cost-architect` (this skill composes it for the numbers).
- Do NOT use when: the task is key custody/rotation/storage mechanics —
  `secrets-identity-hardener` (this skill composes it and owns only the
  AI-spend blast radius); or a general fail-closed review of error paths —
  `error-handling-security-reviewer`.
- Do NOT use when: deciding which PLAN includes which feature/limit —
  `plan-entitlement-architect`; implementing alert rules —
  `observability-operator`; or designing model fallback/routing —
  `ai-router-architect` (this skill sets the budget the router enforces).

## Inputs to Inspect

1. The feature's call pattern: how many model calls per user action, input and
   output sizes, whether it's agentic (loops/tool calls multiply cost).
2. Who can trigger inference and how: authenticated vs public endpoints,
   per-request cost, ability to trigger many calls cheaply.
3. Current limits (if any): token caps, rate limits (and whether they count
   REQUESTS or actual token/cost consumed), concurrency, timeouts, input-size
   validation — and where they're missing.
4. Cost model inputs: model prices, `saas-cost-architect` unit economics,
   the budget envelope per tenant/plan.
5. Existing telemetry: what token/cost/latency data is emitted per call and
   whether it's attributable to a user/tenant/feature.
6. Failure behavior: what happens at the limit today — hard error, silent
   drop, unbounded retry, or fail-open (the dangerous default).
7. Provider credential handling: where the key lives (server-only vs
   client-reachable), how narrowly it's scoped (per-model, least-privilege),
   and rotation posture — the LLMjacking surface (custody detail →
   `secrets-identity-hardener`).
8. Provider-account billing controls: whether a hard spend cap and
   billing-anomaly/spike alerts are configured — both are typically optional
   and OFF BY DEFAULT.

## Workflow

1. **Map the consumption surface.** Per user action, count model calls, token
   sizes, tool calls, and any loops. Identify the cheapest way an attacker (or
   a bug) can maximize spend. No feature/call pattern to inspect → Stop
   Conditions.
2. **Set per-request bounds.** Cap input tokens (reject/ truncate oversize
   input) and max output tokens; bound context assembly; set a timeout. An
   uncapped request is an open-ended bill.
3. **Set per-principal budgets and cost-aware rate limits** using
   [references/cost-guardrail-patterns.md](references/cost-guardrail-patterns.md):
   per-user, per-tenant, and per-plan token/spend budgets and rates — limit on
   TOKEN/COST consumed per window, not request COUNT, since one request can
   cost hundreds of times another. Estimate cost before the call (input tokens
   + `max_tokens` as a provisional reservation), then true-up to actual output
   tokens after the response (true cost is only known then). Give each
   tenant/user its own FIFO queue so one can't starve the shared budget.
   Tenant-scoped so one tenant can't exhaust another's capacity
   (noisy-neighbor). Compose `plan-entitlement-architect` for the plan
   dimension.
4. **Bound concurrency and loops.** Concurrency/queue limits per tenant; for
   agents, a hard cap on iterations, tool calls, and recursion depth so a loop
   can't run away. Cap retries with backoff — no unbounded retry storms.
5. **Choose model by task.** Route cheap/simple tasks to smaller models;
   reserve expensive models for where they're needed (design intent handed to
   `ai-router-architect` to enforce). Over-using a frontier model is a
   self-inflicted cost.
   When presenting model tiers or limit values for an owner to choose, define
   the terms (including input/output tokens, reservation, and true-up), show
   the reason for each viable option, its benefits and drawbacks, and its
   estimated per-call and monthly cost at the inspected call volume. Use
   verified current prices or mark the dollar estimate unknown; do not invent
   prices or imply that a request-count cap bounds spend. Recommend a tier
   and limits with the workload evidence that supports them. Without verified
   provider unit prices, only provisional token/volume limits can be chosen;
   defer a dollar budget until unit economics are available. Then ask exactly
   one atomic owner question; the answer sets the design only and does not
   authorize enforcing limits or changing provider-account settings. If step
   10's budget, degraded-mode or backstop choice is also open, ask only the
   more blocking of the two this turn and list the other as pending for a
   later turn.
6. **Make every guardrail fail closed, and design the kill switch and degraded
   mode.** A switch to disable the feature/model/tenant on a spend spike, and a
   degraded fallback (cached answer, smaller model, queue, or "temporarily
   unavailable") so hitting the limit fails safe. If any cost/rate/budget check
   errors, times out, or its backing store is unreachable → DENY the call,
   never allow it through; a check that fails open turns your own limiter into
   the denial-of-wallet vector (CWE-636). The kill switch inherits the same
   rule: a broken budget-state check ENGAGES it, never disengages. The general
   fail-closed discipline is `error-handling-security-reviewer`'s; this is its
   AI-spend application. Route confirmed live abuse to the human incident
   owner and approved response runbook; this skill designs the control.
7. **Add the provider-side backstop.** Application controls are not the last
   line: set a HARD spend cap on the provider account itself (a ceiling that
   stops inference) and billing-anomaly/spike alerts that fire before a large
   invoice lands. Most major LLM providers offer both, but they are usually
   OPTIONAL and OFF BY DEFAULT — an account set up once and never revisited is
   exposed — so the design must explicitly VERIFY they are configured. These
   are config actions the skill FLAGS as verify-at-design-time, not
   architecture it builds.
8. **Protect the provider credential (LLMjacking).** A stolen API key is a
   denial-of-wallet weapon: keys leaked from public repos or CI are exploited
   within minutes and resold cheaply. Hold the key server-side only (never in a
   client bundle or any browser-reachable path), and scope it per-model /
   least-privilege so a leak's cost blast radius is bounded to what that key
   may invoke. Custody, scoping, and rotation MECHANICS are
   `secrets-identity-hardener`'s; this skill owns the AI-specific angle — the
   per-model invocation restriction and the cost blast radius of a leaked key.
9. **Design telemetry, attribution, and alerts.** Per-call emission of model,
   tokens (in/out), estimated cost, tenant/user/feature, latency, and error
   class — attributable. That attribution is what tells a denial-of-wallet
   attacker, a looping agent, and an honest-but-expensive workload apart: they
   look IDENTICAL on the invoice, so don't judge a spike malicious (or benign)
   without it. Alerts fire on budget burn rate BEFORE exhaustion (compose
   `observability-operator` to implement, `slo-reliability-architect` for
   burn-rate thinking). Redact prompt content from cost telemetry; alert on
   tampering with invocation/usage logging itself — disabling cost logging to
   hide activity is a near-certain compromise signal.
10. **State the residual exposure.** The worst-case spend with these guardrails
    in place, and the named acceptor for it via `human-approval-boundary`.
    If an owner must select a MECHANISM option for the policy the business has
    chosen — a budget cap level, how the degraded mode behaves, or the
    provider backstop — explain the terminology, why the choice is needed,
    setup and operating costs (including denied legitimate work), benefits and
    drawbacks of each viable option, and which option is recommended and why.
    When the open question is WHICH degradation policy the business adopts
    from tenant-tagged cost and margin evidence, hand that choice brief to
    `saas-cost-architect` and design the mechanism for the option chosen.
    Preserve the fail-closed floor: no option may allow inference when a
    budget check fails.
    Then ask exactly one atomic owner question; the answer sets the design
    only and does not authorize enforcing a guardrail or the provider backstop.
    If step 5's tier-and-limit choice is also open, ask only the more
    blocking of the two this turn and list the other as pending for a later
    turn.

## Output Format

```
AI COST GUARDRAILS — <feature>
Consumption surface: <calls/action, token sizes, loops, cheapest abuse path>
Per-request bounds: <input cap | output cap | context cap | timeout>
Per-principal limits: <user | tenant | plan — token/COST budget + rate, not request-count> (tenant-scoped)
Rate-limit mechanics: <pre-call estimate (input + max_tokens) → post-response true-up | per-tenant FIFO queue>
Concurrency/loops: <concurrency cap | agent iteration/tool/recursion caps | retry policy>
Model selection: <task → model tier> (→ ai-router-architect enforces)
Fail-closed: <check error/timeout/store-down → DENY | kill switch ENGAGES on broken budget-state check> (CWE-636)
Kill switch / degraded mode: <trigger → switch | fallback behavior (fail-safe)>
Provider backstop: <hard spend cap | billing-anomaly alert — configured? (off by default, verify)>
AI credential: <server-side-only | per-model/least-priv scope | logging-tamper alert> (custody → secrets-identity-hardener)
Telemetry & alerts: <per-call metrics, attribution that distinguishes attacker/loop/honest, burn-rate alert> (→ observability-operator)
Residual exposure: <worst-case spend + named acceptor>
Owner choices: <term definitions | options and reasons | verified/unknown dollar
                and operational costs | pros/cons | recommendation and why>
```

## Validation Checklist

- [ ] Every request has input and output token caps and a timeout; oversize
      input is rejected/truncated, not silently processed.
- [ ] Rate limits are on TOKEN/COST per window, not request count; cost is
      estimated pre-call and trued-up to actual output post-response, and each
      principal has its own queue so one can't starve the shared budget.
- [ ] Per-user, per-tenant, and per-plan budgets/rate limits exist and are
      tenant-scoped (no cross-tenant exhaustion).
- [ ] Agent loops/tool calls/recursion and retries are hard-bounded.
- [ ] Every cost/rate/budget check FAILS CLOSED — an error, timeout, or
      unreachable store DENIES the call (never allows), and the kill switch
      ENGAGES on a broken budget-state check (CWE-636).
- [ ] A kill switch and a degraded-mode fallback exist; the limit behavior
      fails SAFE (bounded), never fail-open (unbounded).
- [ ] A provider-side hard spend cap and billing-anomaly/spike alerts are
      configured and VERIFIED on (they are optional and off by default).
- [ ] The provider credential is held server-side only, scoped
      per-model/least-privilege, and tampering with invocation/usage logging
      alerts as a compromise signal.
- [ ] Per-call cost telemetry is attributable (tenant/user/feature) so an
      attack, a loop bug, and honest heavy use can be distinguished; prompt
      content is redacted from it.
- [ ] Alerts fire on burn rate BEFORE the budget is exhausted, not after.
- [ ] Worst-case residual spend is stated with a named acceptor.
- [ ] Each owner-facing choice defines terms, costs, reasons, pros/cons, and a
      workload-based recommendation; unverified dollar amounts are unknown.

## AI Security Rules

- Denial-of-wallet is a security risk, not just a finance one: any path where
  an attacker can cheaply trigger expensive inference is a finding (LLM06).
- Every guardrail FAILS CLOSED. If a cost/rate/budget check errors, times out,
  or its store is unreachable, DENY the call — never let it through. A
  guardrail that fails open is not a guardrail: an attacker (or a bug) that can
  force the check to error has disabled your limiter and turned it into the
  denial-of-wallet vector (CWE-636). The kill switch obeys the same rule — a
  broken budget-state check ENGAGES it. `error-handling-security-reviewer` owns
  fail-closed generally; this is its AI-spend application.
- Rate-limit on tokens/cost, not request count. One request can cost hundreds
  of times another (a cache hit vs a multi-step agent run), so a request-count
  limiter lets an attacker drive the most expensive paths while staying under
  it — estimate cost before the call and true-up after.
- A stolen provider key is a denial-of-wallet weapon (LLMjacking). Keys leaked
  from repos or CI are exploited within minutes and resold — hold the key
  server-side only, scope it per-model/least-privilege to bound the blast
  radius, and alert on any tampering with invocation/usage logging (a
  near-certain compromise signal). Custody and rotation are
  `secrets-identity-hardener`'s; this owns the per-model restriction and the
  cost blast radius.
- Attribution decides intent — don't guess without it. A denial-of-wallet
  attacker, a looping agent, and an honest heavy user look identical on the
  invoice; only per-tenant/user/feature attribution tells them apart, so don't
  declare a spike malicious (or benign) until it can.
- Tenant isolation applies to capacity and budget: one tenant (or attacker)
  must not be able to consume another tenant's quota or starve the platform.
- Public/unauthenticated inference endpoints are the highest-risk surface —
  they need the tightest per-Internet Protocol (IP) address and per-session
  caps and a kill switch.

## Gotchas

- Output tokens are the expensive half and the easiest to forget to cap — a
  prompt that says "repeat forever" or a model that rambles runs up the bill.
- Request-count limiters are cost-blind: capping requests/minute does nothing
  when one request (a multi-step agent run) costs hundreds of times another (a
  cache hit) — an attacker just triggers the expensive path while staying under
  the count. Limit on tokens/cost.
- Agent loops multiply: one user action → N iterations × M tool calls ×
  tokens each. Cap the loop, not just the single call.
- Retry storms: a transient provider error plus naive retry-all can double or
  triple spend under load; use bounded retries with backoff and a circuit
  breaker.
- Fail-open is the silent killer: "if the budget check errors, allow the
  request" turns a bug — or an attacker who can force the check to error — into
  unlimited spend, making your own limiter the denial-of-wallet vector
  (CWE-636). Fail closed; defer the general discipline to
  `error-handling-security-reviewer`.
- Provider billing controls are off by default: an account set up years ago
  with no hard spend cap and no billing-anomaly alert is exposed until someone
  turns them on — verify, don't assume.
- A stolen key spends at machine speed: LLMjacking exploits leaked keys within
  minutes, and attackers disable cost logging first — so treat any
  invocation-logging gap or tampering as a compromise signal, not noise.
- A budget with no pre-exhaustion alert is a post-mortem, not a guardrail —
  alert on burn rate, not just at 100%.
- Blocking legitimate heavy users: guardrails tuned only to attackers can cut
  off a real power user — tier the limits (compose
  `plan-entitlement-architect`), don't just clamp globally.

## Stop Conditions

- No feature or call pattern is available to bound — stop; guardrails need a
  concrete consumption surface.
- The unit economics/budget envelope is undefined — get it from
  `saas-cost-architect`; caps need a number to enforce.
- A spend spike is happening NOW — route to the human incident owner and
  approved response runbook. The owner decides whether to activate the kill
  switch or rotate a suspected compromised key under the applicable live
  authority; this skill designs those controls. Use
  `incident-response-runbook` to author or improve the procedure and
  `secrets-identity-hardener` to design credential custody and rotation.
- The ask is really key custody/rotation/storage mechanics
  (`secrets-identity-hardener`) or a general fail-closed review of error paths
  (`error-handling-security-reviewer`) — hand to the owning skill; this skill
  sets the AI-spend requirement, not those mechanics.
- The ask is really plan feature-gating, whole-product cost modeling, alert
  implementation, or router logic — hand to the owning skill.

## Supporting Files

- [references/cost-guardrail-patterns.md](references/cost-guardrail-patterns.md)
  — the layered limit catalog (per-request/per-principal/concurrency/loop),
  cost-aware token-based limiting (estimate + true-up), fail-closed guardrails
  (CWE-636), the provider-side backstop, AI-credential/LLMjacking custody,
  denial-of-wallet abuse paths, fail-safe degraded-mode and kill-switch design,
  and cost-telemetry/attribution requirements.
- `evals/evals.json` — trigger + behavior cases.
- `evals/trigger-evals.json` — discrimination within the AI-platform-ops
  cluster and against `saas-cost-architect`, `plan-entitlement-architect`,
  `observability-operator`, `secrets-identity-hardener` (key custody), and
  `error-handling-security-reviewer` (fail-closed review).