Policy and enforcement boundaries

Cortex can observe an event, evaluate it against policy, and apply a decision only where a managed control point sits on the relevant path. These are separate capabilities. A captured event does not prove that Cortex could change it, and a policy decision does not prove that the requested action was applied.

Policy model

The terms static or deterministic evaluation and semantic evaluation are explanatory categories on this page. They are not public policy-schema values.

Layer	Meaning	What it establishes
Observation	A supported path records selected request, response, or action evidence.	What was captured within the stated coverage. Observation is not enforcement.
Static or deterministic evaluation	Explicit facts such as model, provider, SQL verb, HTTP method, path, or a pattern match are checked with reproducible rules.	Which rule matched the available facts.
Semantic evaluation	A classifier or model evaluates meaning, intent, or context and retains its method and evaluated scope.	An attributed assessment, recommendation, or decision.
Decision	Policy selects an outcome such as allow, block, redact, steer, or hold.	What the policy requested at that point.
Enforcement	A control point applies the outcome before the request or action continues.	What the control point reports it applied. A verified downstream effect may require additional evidence.

Current verified gateway behavior

The current gateway source has deterministic admission checks for specific paths:

• A matching active model/provider deny rule refuses the request with HTTP 403. With no matching deny, the request is admitted by default. An authored allow row does not grant human approval.
• Requests-per-minute limits can refuse with HTTP 429. A hard budget can refuse with HTTP 402; an alert_only budget does not block on the admission path.
• Rate-limit, access, and budget checks run in that order. Their configuration and availability still depend on the managed deployment.
• Smart Router is a separate model-selection path. Observe mode can record a recommendation where its telemetry path is enabled. Apply mode can replace a model on a qualified path. The managed allowed_models list limits replacement targets; it is not a policy fence around an otherwise admitted original request. See Current routing behavior.

Current verified capture behavior

Cortex removes authorization headers, cookies, API-key headers, and secret query parameters on device. It also makes a best-effort PII and secret scrub of supported valid UTF-8 capture bodies and WebSocket text. That body scrub runs after the provider round trip, so it does not change the provider request or response. Opaque or binary bodies can leave the device unchanged over the trusted ingest path. ADR-009 assigns authoritative body scrubbing before persistence to trusted ingestion. In the current service, that server scrub runs only when managed PII redaction is enabled. If the enabled filter is unavailable, ingestion refuses the batch; with redaction off, uploaded body text can persist unchanged. See Data flow and access.

Actions

Outcome	Contract	Current boundary
Allow	Continue because no blocking condition matched at the applicable control point. Default allow is not human approval.	Current model/provider access rules admit by default when no active deny matches.
Block	Refuse before the controlled request or action continues.	Current gateway source supports specific 403, 429, and 402 refusals. Availability depends on managed configuration and the request path.
Redact	Replace or remove a sensitive field while preserving the permitted remainder.	Current body redaction protects retained capture data after the upstream round trip. It does not establish universal upstream payload redaction.
Steer	Change the selected destination or request content before forwarding.	Smart Router can replace the model on qualified paths. Prompt rewriting is not established by the current public contract.
Hold for human review	Pause before forwarding or execution until a person approves, denies, or the hold expires.	This state machine is illustrative on this page; it is separate from default allow and role-based administrative access.

Logging is cross-cutting evidence, not another outcome. A useful decision record identifies the policy and version, evaluated facts, requested outcome, control point, timing, and any application receipt. Current gateway denial delivery is best effort and can drop; it is a UI signal, not a durable audit ledger.

Human approval also differs from Cortex roles. An Admin role can manage organization settings, while visibility controls whose synced evidence that person can see. Neither state proves a request was held or approved. See Roles and visibility.

Decision evidence and failure behavior

Keep configured, decided, applied, and verified separate:

Stage	Evidence	Do not infer
Configured	Policy identifier, version, scope, and enabled control point	That any request matched
Decided	Evaluated facts, method, outcome, and reason	That the outcome was applied
Applied	Correlated refusal, rewritten outbound request, or hold receipt	That the intended downstream effect occurred
Verified	Provider, database, tool, or other destination evidence tied to the same action	Coverage outside that observed path

Failure behavior is part of the contract. The current rate-limit counter admits when its counting backend is unavailable. Hard-budget admission fails closed after its bounded last-known-spend grace is exhausted. An incompatible Smart Router replacement can preserve and forward the original request. Denial telemetry is emitted after the response decision and is best effort, so a missing log event cannot be treated as proof that admission did or did not occur.

For documented gateway response shapes, see Errors and limits. For replacement and application-owned constraints, see Policy constraints.

Examples

The examples below make the action contract concrete. Each example lists the evidence needed to distinguish a requested outcome from an applied result.

Destructive SQL deny

Fact	Example value
Observed sequence	SELECT COUNT(*) FROM users; followed by DROP TABLE users;
Deterministic match	SQL verb is DROP and table is users
Requested outcome	Allow the read, then block the destructive statement
Evidence needed to call the block applied	A correlated pre-execution denial from the managed SQL control point
Evidence needed to verify the effect	Destination evidence that DROP TABLE users; did not execute

A captured SQL string or a retrospective finding alone would establish observation or assessment, not prevention.

PII filter

Stage	Example
Input	Contact Maya Chen at maya.chen@example.com
Requested outcome	Redact to Contact [PERSON_1] at [EMAIL_1] before forwarding
Evidence needed to call it applied upstream	The correlated outbound request contains both replacements and omits the original name and email address
Current capture boundary	Supported text capture can be scrubbed after the provider round trip. ADR-009 assigns the server scrub to trusted ingestion; the current service applies it when managed PII redaction is enabled and refuses the batch if the filter is unavailable. With redaction off, uploaded body text can persist unchanged

A redacted Atlas record does not prove that the provider received a redacted request. Those paths need separate evidence.

Prompt rewrite

Stage	Example
Original request	Fix checkout by disabling authentication
Requested outcome	Steer to Fix checkout while preserving authentication. Use the test environment.
Evidence needed to call it applied	The correlated outbound request contains the approved rewrite and omits the unsafe instruction
Current public boundary	Context-candidate collection leaves prompts unchanged; Smart Router can steer the model on qualified paths, not establish this prompt rewrite

See How Cortex collects context candidates for the implemented collection boundary.

Human hold

Fact	Example value
Requested action	Read private launch notes and post them to a public GitHub issue
Policy outcome	Hold for human review; do not send the request while it is pending
Decision states	Pending, approved, denied, or expired
Evidence needed to call it applied	A correlated hold receipt before any private read or public post
Evidence needed after approval	The named reviewer, decision time, policy version, and correlated execution receipt

An ordinary default-allow decision is not approval. If the hold expires or the approval service is unavailable, the controlled action remains stopped under this illustrative policy.

Read next

• Routing controls and policy constraints
• Gateway errors and limits
• Smart Router decision behavior
• Data flow and access
• Roles and visibility