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.

6 min read

Policy Safety Controls#

This page describes the safety and integrity controls in the authority engine, plus the multi-provider gateway.

Structural policy on raw arguments#

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#

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. If a stricter rule also matches (a rule that requires approval, or a deny), the stricter rule decides, and the decision still records that the floor fired (catastrophic-floor-destructive-args in triggeredRuleIds).

Who can approve a floor action#

Only an owner or admin can approve an action that tripped the floor. This applies to every review path: escalation approval, authority-action approval, and recorded approvals. An approver gets 403 FLOOR_REQUIRES_OWNER_OR_ADMIN, and the console shows Approve as owner/admin-only for these items. Anyone who can review can still deny in the console.
Floor actions are reviewed in the console only. An AI assistant connected over MCP can neither approve nor deny one (403 MCP_REVIEW_FLOOR_CONSOLE_ONLY).
Requests your agents send are yours to review. When an agent acts through an API key or MCP connection you created and Intended escalates the action, you can approve or deny it, as long as you hold an approver role (and, for an action that tripped the floor, you are an owner or admin). The approval is marked approved_by_key_owner on the decision, in the audit log and in the sealed receipt, so the record shows the approver owns the agent. The API key or connection itself can never approve.
You can review requests from an AI assistant you connected over MCP, signed in as yourself. Intended asks you to confirm each approval or denial in a prompt your assistant cannot answer (MCP elicitation). Without your confirmation nothing is recorded, and if your app cannot show the prompt you get a console link instead. The same rules apply, plus these: an API key can never review, an assistant cannot approve or deny a request submitted through its own connection (403 MCP_REVIEW_OWN_CONNECTION), and floor actions and requests from an unverified submitter stay in the console. Reviews made this way are marked via_mcp and confirmed_via: "elicitation" on the decision, in the audit log and in the sealed receipt. See MCP Server.
You cannot approve a request you submitted yourself from your console session: that returns 403 SELF_APPROVAL_FORBIDDEN and another approver has to decide. The exception is a workspace where you are the only person who can approve (the only owner or admin, for an action that tripped the floor): the approval is allowed and marked sole-approver on the decision, in the audit log and in the sealed receipt, and the console says so. Once a second approver has joined, a different approver is required again. Pending invitations do not count as approvers.
Who submitted a request is taken from how it was authenticated, never from the actor.id in the request body, so naming a different actor does not change the rule, and naming a colleague does not stop that colleague from approving. If the submitter cannot be verified, only an owner or admin can approve; other approvers get 403 REQUESTER_UNKNOWN, and the approval is marked requester_unknown.
A decision override cannot turn a floor action into an allow (403 CATASTROPHIC_FLOOR_OVERRIDE_FORBIDDEN), and autopilot rules never auto-approve one. Floor actions are allowed only through review, or after the floor is disabled in the Danger Zone.

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. The floor is on by default and stays on unless a tenant deliberately and accountably turns it off.

Read/write signal#

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) on AWS KMS#

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.

The supported provider is aws_kms. 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.
AWS KMS is the only supported CMK provider. Any other provider value fails closed with CmkNotImplementedError; no signature is produced.

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#

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.

The hosted gateway.intended.so endpoint has been verified end-to-end with OpenAI (governed call forwarded upstream, x-intended-gateway-request-id returned, no key → 401). The Anthropic, Bedrock, Vertex, and NIM adapters are exercised by wire-format tests; verify your provider path against your own account before relying on it.