ResourcesGlossary

Glossary

Agent — software that acts for a person or an organization and can reach a rail. Under Regent it has an AgentID, acts only as itself with its own credential, and never holds an organization key.

AgentID — the agent’s identity record: a did:webvh identifier with a key log, bound to a responsible party, anchored on Solana. The API knows the agent by its agent_… identifier.

Allow token — the short-lived (sixty seconds) signed proof an allowed decision issues, scoped to one tool and action and bound to the request by args_hash. A rail or a verifier checks it offline.

Approval — a person’s signature over terms: the owner approving a mandate, or an escalation. Recorded in every token and receipt as approval_method (passkey, passkey+authid, or session in a sandbox) and approval_digest.

Audit trail — every meaningful event hashed, batched into Merkle trees, chained, checkpointed under Regent’s signature, timestamped on Bitcoin and anchored on Solana (Audit Trail).

Budget envelope — a slice of a mandate issued as an AAuth budget token so a resource can meter spend itself without a round trip per call (Budget envelopes).

Cloud Gateway — the hosted door: one URL and one key, every tool call decided, provider credentials in Regent’s vault, set up by chatting over MCP (Overview).

Counterparty — who the money goes to: a merchant, a store, a connected account, a chain address. Named by the rail wherever the rail can (payee_source: rail), by the agent otherwise.

Decision — the answer to “may this agent do this, now”: allow, deny or escalate, taken before money moves, with a decision_id. Every decision is recorded, including refusals.

Escalation — a decision that waits for a person. The agent stops, the owner is asked (console, e-mail, a card in the chat), and the agent retries the same call with the same idempotency_key after the answer.

Guardian — the behavioural layer of the gate: a risk score with explainable factors; medium risk on a money action asks a person, high risk refuses (Guardian).

Idempotency key — a stable key per logical action. A retry with the same key replays the earlier decision; it is also the handle an escalation resumes on.

Mandate — the spending rulebook for one agent in one currency: limits per transaction, day and month, caps per seller, an optional expiry. Terms a person signs; every change is a new version, committed by hash in every token and receipt (Mandate).

Mandate reveal — the owner’s disclosure of a mandate version’s terms and salt, which lets a third party open the receipt’s mandate_hash.

Policy — the organization’s rules on top of the mandate (who may do what, with which tool, under which facts). Its version is committed by hash in every token and receipt (policy_hash).

Rail — the system that actually moves the money: Stripe, Agentcard, a custodian, an HTTP API (Where Regent sits).

Receipt — the signed statement of what one decision authorised and what settled, verifiable offline with Regent’s public key (Receipt).

Regent Control — the in-path enforcement product: the gate that decides, the sidecar that holds credentials and proxies calls, the SDKs and hooks that bring an agent to it (Overview).

Responsible party — the person or entity legally answerable for an agent’s actions; every AgentID is bound to one, verified in a production organization (Responsible Party).

Sandbox — the environment a self-serve organization starts in: Regent’s test rail, a practice budget, real decisions and receipts labelled sandbox, no identity check. Going live is one-way.

Settlement — what actually happened after a decision: the amount, the payee, the outcome, as the rail reports them. Closes the decision and produces the receipt.

Settlement confirmation — a JWS the counterparty (merchant, PSP, custodian) signs over a decision’s outcome; embedded in the receipt as confirmation (Settlement confirmation).

Sidecar — the Regent Control proxy you run on your own servers; the agent talks to it and to nothing else; it holds the provider keys and the egress allowlist (Run the Sidecar).

Step-up — a second proof above a threshold: a face check with the identity provider on top of the passkey (approval_method: passkey+authid).