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

# Steuerung (Control)

> Spending-Policies und Guardrails, die sich selbst durchsetzen.

Steuerung ist die Regel-Schicht. Zwei Engines — **Policy** und **Risk** — bewerten gemeinsam jeden Intent, Grant, Issue, Redeem und Checkout. Entscheidungen sind server-seitig; Agents können ihre eigenen Regeln nicht umgehen.

## Die zwei Engines

<CardGroup cols={2}>
  <Card title="Policy-Engine" icon="shield-check">
    Pure Function `evaluatePolicy(policy, input) → { allowed, requiresApproval, reason }`. Deterministisch, deklarativ, plan-tier-agnostisch.
  </Card>

  <Card title="Risk-Engine" icon="radar">
    Stateful. 5 Signale (velocity, amount-anomaly, geo, session, time-anomaly). Score 0–100 mit tunable Thresholds für Review/Deny/Freeze.
  </Card>
</CardGroup>

## Policy: was ausdrückbar ist

Policies sind JSON-serialisierbare Objekte, an einen Agent gebunden (eine Policy pro Agent). Vollständiges Schema in `/de/concepts/policies` — hier die Surface:

| Gruppe                | Felder                                                                                        |
| --------------------- | --------------------------------------------------------------------------------------------- |
| **Limits**            | `maxTransactionEuros`, `dailyLimitEuros`, `weeklyLimitEuros`, `monthlyLimitEuros`             |
| **Approval**          | `autoApproveLimitEuros`, `enforcementLevel` (`enforce` / `approve` / `warn`)                  |
| **Merchant**          | `merchantAllowlist`, `merchantBlocklist`, `allowedMccs`, `blockedMccs`, `lockToFirstMerchant` |
| **Geo**               | `allowedCountries`, `blockedCountries` (ISO 3166-1 Alpha-2)                                   |
| **Zeit**              | `activeHoursStart`, `activeHoursEnd`, `timezone`, `allowedDays`, `cooldownMinutes`            |
| **Lifecycle**         | `expiresAfterMinutes`, `expirationAction` (`freeze` / `close` / `notify`), `maxUsageCount`    |
| **Required behavior** | `requireIntent` (sacred — niemals stillschweigend abgeworfen), `requireAttestation`           |

## Risk: Signale und Thresholds

| Signal           | Was es prüft                                              | Default-Gewicht |
| ---------------- | --------------------------------------------------------- | --------------- |
| `velocity`       | N Transaktionen in M Minuten vs Baseline                  | Hoch            |
| `amount-anomaly` | Z-Score gegen historischen Spend-Mean/StdDev              | Hoch            |
| `geo`            | Neues Land vs Policy + History; „impossible travel"       | Mittel          |
| `session`        | User-Agent / IP-Cluster-Anomalien                         | Mittel          |
| `time-anomaly`   | Außerhalb Geschäftszeiten oder definierter Active-Windows | Niedrig         |

Score ist gewichteter Aggregat. Thresholds sind per Policy tunable (5-min-Cache):

| Threshold         | Default | Aktion                                 |
| ----------------- | ------- | -------------------------------------- |
| `thresholdReview` | 70      | Hold für menschliche Genehmigung       |
| `thresholdDeny`   | 85      | Intent ablehnen                        |
| `thresholdFreeze` | 95      | Agent einfrieren (opt-in, Default off) |

<Warning>
  Auto-Freeze ist opt-in. Kann legitime Flows brechen wenn deine Toleranz nicht kalibriert ist — Empfehlung: erst nach Beobachtung der Risk-Scores in Production aktivieren.
</Warning>

## Wo Steuerung läuft

```text theme={}
intent → grant → issue → redeem → checkout
   ↑       ↑       ↑       ↑          ↑
  policy + risk an jedem Checkpoint ausgewertet
```

Jede Auswertung schreibt eine Row in `decision_logs` mit vollem Signal-Payload, Score, Reason und Action. Abfragbar via `/audit` und `/risk/violations`.

## Card-Controls-Sync

Bei Policy-Änderung übersetzt das System die relevanten Felder in card-issuer-native Controls (MCC-Rules, Country-Rules, Per-Tx-Limits) und pusht sie auf die zugrundeliegende Karte. Policy ist Source of Truth; der Card-Mirror ist Best-Effort und wird bei jedem Update reconciliert.

## Approval-Workflow

Wenn `enforcementLevel: "approve"` oder Risk-Action `review`, geht der Intent in `pending_approval`. Genehmigung via:

```bash theme={}
curl -X POST https://api.getovra.com/intents/int_.../approve \
  -H "Authorization: Bearer $OVRA_API_KEY"
```

Oder `POST /intents/:id/deny` mit optionalem `reason`.

## Schnellbeispiel — Policy eines Agents lesen

```bash theme={}
curl https://api.getovra.com/policies?agentId=ag_... \
  -H "Authorization: Bearer $OVRA_API_KEY"
```

Oder via MCP — Agents können ihre Policy **lesen** aber nie modifizieren:

```text theme={}
ovra_policy { action: "get", agentId: "ag_..." }
```

## Pre-built Presets

`policy-presets.ts` shippt Templates für gängige Patterns: Travel-only, Subscriptions, Dev-Tools etc. Im Dashboard-Create-Flow als Startpunkte verwendbar.

## Surfaces

| Surface   | Capability                                                               |
| --------- | ------------------------------------------------------------------------ |
| REST      | `GET/POST/PATCH /policies`, `GET /risk/violations`, `PATCH /risk/config` |
| SDK       | `policies.*`                                                             |
| MCP       | `ovra_policy` (read-only by design)                                      |
| Dashboard | `/dashboard/policies`, `/dashboard/risk`, `/dashboard/agents/:id`        |

## Weiter

<CardGroup cols={2}>
  <Card title="Policies" icon="shield-check" href="/de/concepts/policies">
    Vollständige Feld-Referenz mit Beispielen pro Regel.
  </Card>

  <Card title="Intents" icon="file-signature" href="/de/concepts/intents">
    Die Approval-tragende Primitive die Steuerung gatet.
  </Card>

  <Card title="Intelligenz" icon="chart-line" href="/de/concepts/intelligence">
    Was Steuerung schreibt — Decision-Logs, Audit, Anomaly-Detection.
  </Card>

  <Card title="Disputes" icon="gavel" href="/de/concepts/disputes">
    Was passiert wenn etwas, das Steuerung erlaubt hat, sich als falsch herausstellt.
  </Card>
</CardGroup>