Skip to content

concepts

Intended Documentation

Policy Safety Controls — Structural Policy, Catastrophic Floor, Read/Write Signal

How Intended's authority engine decides on the raw structure of an action, enforces an always-on catastrophic floor with a counsel-gated Danger Zone, and derives a read/write signal from the classified intent. Plus customer-managed keys and the multi-provider gateway.

intermediate4 min readimplemented

Policy Safety Controls#

This page describes four safety and integrity controls in the authority engine, plus the multi-provider gateway. For the exact shipped status of each, see the Capability Truth Matrix.

Structural policy on raw arguments — Implemented#

Policy conditions evaluate the raw structure of an action's arguments, not just its risk labels. A condition can address a value by path and match it structurally:

  • resolveArgsPath() walks dot/bracket notation into the raw arguments — for example args.body.path or args.items[0].name.
  • The MATCHES operator runs a compiled regular expression (compilePolicyRegex) against the resolved value; CONTAINS does a substring match.
  • A bare args field recursively scans all string leaves of the argument object against the predicate (depth-bounded), so a policy can catch a dangerous string wherever it appears in the payload.

This means you can write a rule that fires on the content of what an agent is trying to do, not only on its declared category.

Always-on catastrophic floor + Danger Zone — Implemented#

A catastrophic floor rule is prepended to every evaluation — under your custom policy or the bootstrap policy alike. It is priority 1 (evaluated first) and matches destructive argument patterns (for example DROP, TRUNCATE, DELETE FROM, rm -rf, git push --force, --no-preserve-root). When it matches, the action ESCALATEs to a catastrophic-review queue — it is never silently allowed.

The floor is always on unless a tenant explicitly disables it through an audited Danger Zone:

  • The disable flag lives in persisted tenant state (TenantAuthorityConfig.catastrophicFloorDisabled) — it is sourced from stored config, never from request input, so a request cannot turn the floor off.
  • Disabling it records who disabled it and when (catastrophicFloorDisabledBy / …At) and the version of the liability agreement accepted (catastrophicFloorAgreementVersion).

Danger Zone is counsel-gated

Disabling the catastrophic floor is a config-only, counsel-gated action tied to a signed liability agreement. Do not present the floor as optional-by-default anywhere — it is on by default and stays on unless a tenant deliberately and accountably turns it off.

Read/write signal — Implemented#

The engine derives a read vs write signal from the classified Open Intent code (resolveOperationType → getOperationType(oiCode)). It is fail-safe: anything not explicitly tagged read is treated as write. Policy conditions read the signal via field: "risk.operation_type", and the bootstrap allow-rule auto-approves only confirmed reads that are also non-production, non-sensitive, and low-risk. The signal is derived from the classification, never taken from caller input.

Customer-managed keys (CMK / HSM signing) — Partial#

The authority-token private key can live in the customer's KMS/HSM. Intended never holds it: every token issuance calls the provider's Sign API, and only the customer's public key is published into the tenant JWKS (by kid), so relying parties still verify offline through the same algorithm-agnostic verifier.

  • aws_kms is real. It uses @aws-sdk/client-kms (Sign / GetPublicKey). AWS KMS asymmetric signing has no Ed25519, so the adapter maps to ES256 (ECC_NIST_P256, transcoding KMS's DER ECDSA signature to JOSE raw r||s) or RS256 (RSA). The JWS alg header is always honest to the key type.
  • gcp_kms and azure_kv are NotImplemented stubs. They sit behind the same interface and throw CmkNotImplementedError rather than ever producing a faked signature. That gap is why this capability is Partial.

Configuration lives on TenantAuthorityConfig (cmkProvider, cmkKeyId, cmkAlgorithm, cmkKid, plus audit fields). If the customer's KMS is unreachable when the JWKS is served, the fetch failure is caught and the built-in keys remain — the endpoint does not break.

Multi-provider gateway — Partial#

The policy-enforcing LLM gateway has provider adapters for OpenAI, Anthropic, Bedrock (Anthropic), Vertex (Gemini), and NVIDIA NIM. Each parses the provider's real streaming wire format into a canonical event and routes tool calls through the same authority resolver — they are real handlers, not stubs.

Only OpenAI is live-proven end-to-end at the hosted gateway.intended.so endpoint. Anthropic, Bedrock, Vertex, and NIM are reference-grade and in beta — not yet live-proven. Present multi-provider support as "OpenAI live, others in beta", never "all providers GA".

Next steps#

Policy Safety Controls — Structural Policy, Catastrophic Floor, Read/Write Signal | Intended