Lab 001

Know Your Agent: Identity Is Only the Beginning

Identity can establish which agent is acting. Authority, scope, limits, and context determine whether its requested action should proceed.

Educational simulation with fictional companies, agents, accounts, tickers, and thresholds. Not investment advice. No order is executed.

From identity to decision

Animated workflow: an agent presents identity, then authority, scope, limits, and context are checked before the trust gateway returns allow, confirm, step-up, or deny. — The agent trust flow: identity establishes who is acting. Authority, scope, limits, and context determine whether the request is allowed, challenged, or denied. Every outcome remains traceable.

Two-panel architecture: a runtime request path from reader to evaluation API to trust gateway, and the policy evaluation inside the gateway with allow, confirm, step-up, and deny outcomes. — The agent trust flow: identity establishes who is acting. Authority, scope, limits, and context determine whether the request is allowed, challenged, or denied. Every outcome remains traceable.

Scenario presets

Try a complete request in one click. Amounts are fictional notionals.

Request builder

Fictional identifiers only. Do not enter real names, accounts, or credentials.

Evaluation result

Submit a request or choose a preset. The service returns a decision only — it does not execute an order.

How to read the decision

Identity establishes which agent is acting.
Authority establishes what it can do, for whom, on which accounts and tickers, and until when.
Context determines whether confirmation or stronger authentication is required for the amount.
Audit preserves a decision identifier and explanations. Nothing is executed.

How it works

This lab separates four responsibilities that are often treated as one. Identity establishes which agent is acting. Delegated authority defines what it may do and for whom. Policy evaluates the requested action against scope, limits, and current context. The result is an explainable decision and audit record—not an executed transaction.

Panel A shows the runtime path: reader, interactive scenario builder, POST /api/evaluate, Trust Gateway, decision response returned to the reader, then explanation and audit ID. Panel B shows identity registry, delegated authority, policy rules, and request context feeding policy evaluation, then ALLOW, CONFIRM, STEP_UP, or DENY. CONFIRM and STEP_UP resubmit after context is satisfied. ALLOW and DENY end at explanation and audit. No order is executed. — Panel A is the request path through this website. Panel B is the policy lifecycle inside the Trust Gateway. Confirmation and MFA cannot override a hard authorization denial. An ALLOW decision is policy approval only.

This spike ends at an explainable policy decision. ALLOW does not place an order, move money, or call a brokerage. A production execution system would be a separate, independently controlled component.

Technical policy details

Policy ID in this demo: cedar-quill-desk-v2. All values below are fictional.

Fictional notional bands after hard authorization checks pass
Notional (fictional)	Decision	How context can satisfy it
Up to 5,000	ALLOW	No extra context required
Above 5,000 through 10,000	CONFIRM	Customer confirmation can satisfy CONFIRM
Above 10,000 through 15,000	STEP_UP	Confirmation plus MFA can satisfy STEP_UP
Above 15,000	DENY	Amount cap; flags cannot override

Hard authorization checks run first. Neither confirmation nor MFA can override an unknown, inactive, expired, revoked, mismatched, unassigned, unsupported, or restricted request. Amount bands use decimal arithmetic. The service never places a trade (execution: not_performed).

Sources

View source on GitHub Read the newsletter