Protections

Everything Tenet enforces on your agents' calls, and how to tune it: the cost cap, trust levels, per-function overrides, and the built-in safeguards.

Every tenet.execute() call is evaluated against your protections before anything reaches the downstream service. They're active from your first call — nothing to configure — and everything tunable lives on one page in the dashboard: Protections (/protections).

Always on

Two protections run on every call and can't be turned off:

Tenet Shield

An agent holding your Tenet key could try to use Tenet itself to remove its own limits — editing protections, revoking keys, changing governance config. Shield blocks those calls at the gateway. It guards what flows through Tenet; it can't see changes made outside it.

Inference Cost Cap

Caps your agent's LLM spend over a rolling window. When the accumulated spend exceeds the cap, the next call returns 429 cost_limit_exceeded — the downstream call is never made. The default is $50 per 24-hour window per agent; edit the amount and window from the cost cap card on /protections. The cap covers LLM inference spend (Anthropic/OpenAI-shaped calls); non-LLM calls don't accrue against it. The cost cap guide covers it in depth.

The cap is orthogonal to everything below: no trust level or override can spend past it.

Trust levels (per service)

Every service you connect gets a trust level, set from its card on /protections:

  • Locked — every call escalates for your approval. This is the default for every newly connected service: nothing runs on a fresh credential until you affirmatively relax it.
  • Gated — the working default once you've relaxed a service: reads and reversible writes are allowed, irreversible actions escalate for approval.
  • Trusted — reads and writes run without review. Irreversible actions still escalate: Trusted never disables the approval gate.

Per-function overrides

One level deeper, each function on a service card can carry its own posture: allow, escalate, or block — plus amount conditions on money-moving functions (for example, auto-approve refunds up to $N, escalate above). An override beats the service trust level, including Locked. Setting allow on an irreversible function requires an explicit confirmation, because it skips the approval gate for that function.

Dry-run

Each service card has a dry-run toggle. While it's on, calls are enforced under the Gated rules, and every decision is also logged with a WOULD_* preview code showing what your current trust settings would have done. Useful for testing a trust change before committing to it.

Built-in safeguards

A few classifications are built into the catalog and apply at every trust level:

  • Irreversible actions escalate. Tools that change something you can't easily undo — github.repos.delete, stripe.refunds.create, deletes, deploys — pause for human approval. The classification lives in the catalog and isn't user-editable (though a per-function override can tighten it to block).
  • Production is stricter. When the SDK call includes context.env = "production" and the tool is irreversible, the call is hard-blocked — no approval path. Dev and staging calls pass through to the normal approval flow.
  • Money movement over $100 escalates. Stripe charges, refunds, and payment intents above $100 wait for approval even when the call would otherwise pass.

How a decision resolves

For each call, the engine works top-down; the first layer that decides, decides:

  1. Tenet Shield and the cost cap — always evaluated, can't be bypassed.
  2. Per-function override, if you set one.
  3. Service trust level (Locked / Gated / Trusted).
  4. Built-in safeguards — irreversible classification, production blocking, payment thresholds. If multiple match, the most restrictive outcome wins: BLOCK over ESCALATE over ALLOW.

Every decision row in the audit log carries reason codes naming the layer that decided — SERVICE_LOCKED, FUNCTION_OVERRIDE_BLOCK, and so on — so you can always reconstruct why a call was allowed, paused, or refused.

What's not yet available

  • A free-form rule editor (per-function overrides and amount conditions are the current customization surface)
  • Per-team / per-user variations
  • AI-assisted policy authoring

What's next