How information and permissions flow between each component. Dashed lines = async / return flows.
How each connection works
The principal configures agents, sets permission rules, reviews the action log, and responds to alerts. Bidirectional — the dashboard also pushes live alerts and approval requests back to the principal.
All permission writes, agent creation, cap changes, and log queries flow through the Trust Engine API. The dashboard never writes directly to the database — the Trust Engine is the single source of truth.
Every agent request passes through Identity first. It confirms the agent is registered, active, and not revoked. No identity check = no permission issued. Nothing else in the engine runs before this.
After identity passes, Permissions checks the action against the agent's permission set — category allowed, amount within cap, merchant not blocked, time window valid.
The final decision point. If all checks pass, it issues a scoped permission token and logs the intent before anything fires. If anything fails it blocks, logs the attempt, and may raise an alert. No action skips this gate.
Every event — completed, blocked, or anomalous — is written here before any side effects happen. Pattern detection runs here and dispatches to Notifications when something needs human attention.
The Trust Engine issues a scoped, single-use, time-limited permission token. The token encodes exactly what is permitted for this specific action. The agent carries it on every MCP tool call — it cannot be escalated or reused.
All events, permissions, agents, and action records persist to Supabase. Intent is always written before an action executes — the record exists whether the action succeeds or fails.
The Audit & Alerts layer sends structured payloads to the Notifications service, which routes them — email for non-urgent, push or SMS for approvals needed, in-app for everything.
The agent calls tools via the MCP protocol, presenting the scoped permission token on every call. Each MCP server validates the token before executing any tool. Calls outside the token's scope are blocked and logged as a blocked attempt.
Four servers, each wrapping one integration domain: Payment MCP (pay, history, flag), Booking MCP (search, book, cancel), Subscriptions MCP (list, usage, cancel), Bank Feed MCP (transactions, anomalies). New service = new MCP server; nothing else in the architecture changes.
Each MCP server translates tool calls into the external service's native API format. The agent never speaks directly to external services — the MCP layer is the only bridge, and the only place that knows about each service's specific protocol.
Confirmation, failure, or partial results flow back via the MCP server to the Trust Engine. The audit record is updated with the real outcome. Discrepancies between intended and actual outcome trigger alerts automatically.
Alerts, approval requests, and summaries are delivered out-of-band. Approval responses re-enter via the Dashboard → Trust Engine path, closing the loop without bypassing the permission model.