Docs · Controls

Signed policy

LiveUpdated September 14, 2026

Agents. Written for people who build agents, the hosts they run in, and the people and companies the agents pay for.

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 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, exceptions coded, signed by the person who approves	Live
Audit export	A zip with the verifier; the 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 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.

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

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 says what would have been stopped.
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.

Who pays whom Shadow mode