Enruta

Docs Reference

Security

LiveUpdated

View as Markdown

The record is built to survive scrutiny, so the system that produces it has to be plain about what it holds.

What is stored

  • Policies, mandates, decisions, approvals, consents, attestations and records, encrypted at rest, with the chain kept per organization.
  • Rail and PSP credentials your administrator scoped, and an x402 signer’s bearer secret, encrypted in a separate secrets store, never in the record.
  • The identity evidence an agent submits (a public key and its proof, the kept claims of a workload identity token, an enclave attestation) with its hash; for a legal entity, the verification result, never a document.
  • Token references and identifiers for cards and transactions; the IP of the agent’s request and of the approver’s session, for the dispute packet.

What is never stored

  • Card numbers, expiry dates or security codes. Every interface rejects a 13-to-19-digit string that passes the Luhn check; the storage layer has no field for them. This keeps merchants and customers on the lightest PCI questionnaire (SAQ A).
  • The funds. Enruta has no balance, no ledger of money, no payout capability.
  • The agent’s full transcript. Only the digest the agent chose to include in trace, and the intent text it chose to send.
  • Identity documents. A legal-entity anchor reads a verification that a rail or an organization already has.
  • Private keys and collateral. An x402 authorization is signed by the customer’s own signer; collateral is read on chain.

People and keys

  • Five roles, one per person on each account: Owner, Admin, Developer, Operator and Viewer. The Owner and Admins approve payments with passkeys (a policy may also name any member) and sign the weekly report the same way; an owner can delegate approval within a scope. An organization with a verified domain can sign in through its own OIDC provider, at no charge.
  • API keys carry one role: agent, developer, auditor, seller, platform or catalog. A platform key acts for a connected account only when a request names it, and never across accounts; a catalog key reaches the Catalog API only.
  • Organization signing keys are rotated on a schedule; every rotation is a snapshot in the key store so old records still verify. Enruta’s own seal, checkpoint and mandate keys are encrypted at rest under a master key.
  • Daily-root checkpoints are signed, published and anchored with OpenTimestamps; anyone can keep a copy.
  • A model judgement runs only when a policy enables it. The model sees the policy’s instruction, the slots, the payee and the line items, never credentials, keys or the user’s e-mail, and the record keeps the hashes of what it saw and said.
  • Webhooks are signed with HMAC-SHA256; OAuth tokens are stored as hashes, and a replayed authorization code revokes the whole grant. An owner can pause any agent from the console; the pause is a sealed record and every later request is denied.

Retention and export

Every record is kept at least 540 days, the longest card-network dispute window, and is exportable at any time, with the verifier. Records export on expiry. Leaving Enruta does not weaken a single record you already hold.

Reporting a vulnerability

Write to security@enruta.ai. Coordinated disclosure; acknowledgement within two business days.