# Signed policy

The controls every user has: one signed policy across the rails the agent pays on, a decision before any credential exists, approvals by the person who approves, and a record of every attempt.

Status: Live · Updated: 2026-09-14
For: agent
Source: https://enruta.ai/docs/signed-policy

Whoever lets an agent pay, a person or a company, gets the same controls: a policy they sign, a decision made before any credential exists, a named person who approves above a threshold, a record of every attempt including the ones that did not happen, a weekly report, and an export someone outside can re-run.

| Control | Form | Status |
|---|---|---|
| Signed policy | One signed, versioned policy, compiled onto every rail the agent pays on | Live; each rail adapter applies the same policy ([Rails](https://enruta.ai/docs/rails) says what each needs) |
| The decision before the click | Every payment is decided before a credential is issued; above the threshold the person who approves signs with a passkey | Live |
| Approvals where people are | E-mail and the console inbox; Slack when the organization connects an incoming webhook; approval delegated within a scope | Live |
| One record per attempt | An Evidence Record, denials included, verifiable offline | Live |
| Weekly report | The [reconciliation report](https://enruta.ai/docs/weekly-report), exceptions coded, signed by the person who approves | Live |
| Audit export | A zip with the verifier; the [compliance export](https://enruta.ai/docs/compliance-export) by person, period and kind | Live |
| Single sign-on | OIDC single sign-on per organization, sign-in by e-mail domain | Live on Enterprise |

## The policy, in your words

The person responsible for the agent’s spending writes the policy in the console editor: which payees, which categories, how much per payment, how much per month, above what amount a person signs, which agents. Since `enruta/0.3` it can also say which details a request must carry (`intent`), which identity anchors an amount requires (`identity_requirements`) and whether the merchant must be verified before paying (`payee_identity`). Signing produces version `n`; every mandate and every record names the version it was decided under. The editor shows the [autonomy level](https://enruta.ai/docs/autonomy-levels) at the top (“This policy is L3: autonomous inside the boundary, a person approves beyond it”).

The same policy runs twice: Enruta decides, then compiles the decision into the rail’s own control, such as a single-use card with the exact amount and a merchant lock on Stripe Issuing, or a Shared Payment Token whose usage limits are the mandate’s. The rail is the fuse; the mandate account is the truth about the limit.

## Approvals

A step-up reaches the person who approves by e-mail and in the console inbox, and in Slack when the organization has set `slack_webhook_url` (`PATCH /v0/org/settings`). It shows the payee, the purpose, the policy version that matched and the budget left. They sign on their phone with a passkey (the assertion binds the request hash) or, where the organization allows it, through an authenticated link. A refund above `reversal.step_up_above` is approved the same way. Nothing is issued before the signature, and an expired approval seals a record too.

## Delegating approval

An owner can hand approval to a member or to an e-mail address, within a scope: a maximum amount, optionally a list of payees and agents, and an end date. The approval page accepts the delegate inside that scope and nowhere else, and the record’s `approval` carries the `delegation_id`.

```http
POST /v0/approval-delegations          Authorization: Bearer enruta_dev_…
{
  "delegate_email": "sam.okafor@halvernrobotics.com",
  "scope": { "max_amount": "500.00", "payees": ["reamandrule.com"], "until": "2026-12-31T23:59:59Z" }
}

GET    /v0/approval-delegations
DELETE /v0/approval-delegations/{id}          → the delegation is revoked (revoked_at)
```

## Two phases

1. **Shadow mode.** Turn a policy on with `shadow: true` and let it observe: every request is decided and sealed as `observe` with what an enforcing policy would have done. After four weeks the [report](https://enruta.ai/docs/shadow-mode) says what would have been stopped.
2. **Release under policy.** Take `shadow` off; the same policy now issues the credentials, and the same records keep flowing.

Replaying payments already made on a rail as `observe` decisions is not part of this release. The Bill.com adapter reads bills, approvals and payments as evidence.

## What the person who approves sees

- `/policies`: every version, its signature and hash, the autonomy label, the rule sheet.
- `/approvals`: the inbox; `/a/{id}`: the approval page, for the owner or a delegate.
- `/payments/{id}`: the timeline from request to seal, with the Intent, Judgement, Identity and Money split panels, the mandate account, the settlement, reversals, the reconciliation line and dispute packets.
- `/reconciliation`: the week’s lines, the exceptions with suggested actions, “Sign with passkey”.
- `/agents`: each agent’s identity and anchors, consents, and “Pause” with a reason; the pause is a sealed record.
- `/recurrences`: the repeated payments running under the policy.
- `/records`: the chain, the verify button, the export panel with the compliance options.
- Settings: Slack, approval delegations, single sign-on, organization verification.

## Price

Policies, approvals, shadow mode and the records are part of every Agents plan. The audit export comes with Vendor and Enterprise, single sign-on with Scale and Enterprise. Enterprise, from $24,000 a year, is sized by mandates and approval seats and adds signed policies across rails, the weekly report and the audit export on a 24-month retention. Denials and step-ups are free and still sealed. A twelve-week read-only pilot ($10,000, credited against the first year) is the shadow-mode phase with a readout at the end. Full sheet on [Pricing](https://enruta.ai/pricing).