> ## Documentation Index
> Fetch the complete documentation index at: https://evalgate.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Runtime controls

> Where EvalGate can deny, require approval, redact, meter, and record evidence during governed AI execution.

# Runtime controls

EvalGate is not limited to a post-run CI score. Governed platform calls can
evaluate provider, model, data, cost, permission, and side-effect policy before
external execution, then attach the decision to the resulting evidence.

<Warning>
  These controls apply only where the application routes a call through the
  corresponding EvalGate gateway, governed asset, SDK, or API integration.
  EvalGate does not claim to intercept arbitrary model traffic, replace a network
  firewall, or provide a proprietary universal safety model.
</Warning>

## Enforcement points

| Point                       | Decision inputs                                                                                                            | Fail behavior                                                                                | Evidence                                                               |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| Model Gateway policy        | Active state, use case, provider/model allowlists and blocklists, data policy, calibration, request cost, remaining budget | Denies before the provider adapter is trusted                                                | Reason code and immutable policy snapshot on the model-call path       |
| Data egress policy          | Data classification and destination type                                                                                   | Throws an explicit egress denial at integrated call sites                                    | Classification, destination, and denial reason                         |
| Organization system policy  | Organization context, correlation ID, PII policy, mutation/audit settings                                                  | Missing organization or invalid policy fails closed; configured mutation activity is audited | Request ID, organization, surface, action, and audit record            |
| Agent evidence policy       | Runtime, connector, action, side-effect class, risk tier, manifest hash, approval state                                    | Denies or requires approval before protected actions                                         | Stable input hash, policy version, decision, severity, and reasons     |
| Bounded evaluation runtimes | Cost ceiling, concurrency, cancellation, provider availability, exact reviewed snapshot                                    | Stops scheduling or records blocked/failed evidence                                          | Case status, cost/model-call ledger, snapshot identity, and run events |

## Model and provider policy

The Model Gateway evaluates a fixed policy order before a governed model call:

1. active gateway and allowed use case;
2. provider and model allow/block policy;
3. declared data policy, including a zero-data-retention requirement when configured;
4. judge calibration requirement;
5. maximum cost per request; and
6. remaining organization budget.

A denial has a machine-readable reason such as `PROVIDER_BLOCKED`,
`MODEL_NOT_IN_ALLOWLIST`, `CALIBRATION_REQUIRED`, or `BUDGET_EXCEEDED`. It is not
converted into a successful score.

## PII and egress

PII detection, redaction, raw-storage policy, and external-transfer policy are
separate controls. The exact behavior depends on the documented surface:

* shared exports redact configured sensitive fields;
* integrated provider and judge paths evaluate organization PII and egress policy;
* data classification can deny external LLM, webhook, or export destinations; and
* redaction or policy telemetry does not prove that traffic sent outside an
  integrated EvalGate path was inspected.

Use provider-side data controls and network policy in addition to EvalGate. See
[model providers and BYOK](/docs/platform/model-providers-byok) for retention and
provider-residency boundaries.

## Side effects and approval

Agent evidence policy can allow, deny, or require approval using a versioned
permission profile. Delete, money movement, permission changes, deployment
changes, legal commitments, and safety-critical actions are treated as
intrinsically approval-sensitive. A connector-manifest mismatch fails closed.

This policy does not grant a connector more authority than its underlying API
credential. Keep the external system's least-privilege permissions in place.

## Connect runtime and release evidence

Use the runtime decision as one input to the release loop:

```text theme={null}
runtime decision -> trace/model-call evidence -> reviewed failure -> eval case -> CI/release gate
```

The release gate should distinguish a quality failure from a policy denial,
provider outage, exhausted budget, cancelled run, or incomplete trace. Do not
collapse those states into one passing average.

## Verify your boundary

1. Route a staging call through the exact integration used in production.
2. Prove an allowed provider/model call reaches the configured adapter.
3. Prove a blocked provider, over-budget request, and protected side effect do not.
4. Confirm the denial reason and policy snapshot are visible to the reviewer.
5. Confirm an uninstrumented direct provider call is documented as outside the
   EvalGate enforcement boundary.

Current maturity is maintained in [Feature status](/docs/platform/feature-status).