Trust, Audit & Control

FlowDot is a Guardian Agents platform, the analyst-named category Gartner forecasts at 10-15% of the agentic AI market by 2030. Most agent platforms treat trust as an add-on: a dashboard widget that summarises yesterday's spend, a kill switch that only stops the surface it was pressed on, an audit trail that fabricates data when it can't see the truth. FlowDot ships verifiable human-control as a first-class property of every running session. This page is the user-facing reference for how that works and what it changes.

Why This is Different

Verifiable human-control should not be a premium tier. It should be the floor. Here is the comparison the platform was built against. For the detailed comparison against each named competitor (n8n, Zapier, LangFlow, Claude Code, LangChain, AutoGen, CrewAI), see /docs/trust/comparison.

Four-Layer Attribution

"Powered by AI" is not attribution. When you ask an agent on FlowDot to do something, the platform records and displays the entire chain of providers that fulfilled the call. This matters because the only way to evaluate a model's behaviour is to know which model actually ran.

Bring-Your-Own-Key calls have no aggregator and no routing layer: the chain collapses to source/model, which is exactly what you'd expect when the request goes directly from FlowDot to the provider account you own. Whatever path the call takes, the audit row records every layer it knows about. We do not paper over differences in routing by collapsing them.

Real-Time Cost & Tokens

Every agent message in the chat shows a small $ indicator next to the provider attribution line. Hover it for the per-message receipt:

• Tokens: exact input and output counts as reported by the provider
• Cost: dollar amount that was deducted from your balance, computed from current model pricing
• Conversation total: running sum across the entire chat so you can see cumulative drift
• Colour cue: grey under one cent, amber from one cent, orange above five cents. No flashing, no hectoring. Just signal.

The receipt survives a page reload because the provider, model, and underlying provider are persisted on every conversation message. You can come back to a chat tomorrow, scroll up, and verify which model said which thing. This is the same data the four-layer attribution chain uses.

For BYOK calls the cost field reads "billed to your provider account" rather than showing a fabricated number. We have the tokens but not the rate, so we won't pretend.

The Trust Center

The page at flowdot.ai/observability is the user-facing consolidation of every server-side audit source FlowDot maintains. One screen, one user, one timeline. No admin view. No team-level aggregation. Just yours.

The Trust Center reads from the per-call USD ledger, the per-step recipe rollups, the per-node workflow audit, the live voice session table, and the programmatic API usage table. If FlowDot recorded it server-side, this is where you find it.

Panic E-Stop

The user story behind the panic button is concrete: you are away from your desk. You see something you don't like. An auto-replied email, an agent thread going off the rails, a recipe doing the wrong thing. You press one button on whatever surface you have. Within seconds every outbound action stops. The stop is sticky until you clear it.

How it works

The Hub is the chokepoint for every action that touches the outside world: email send, third-party toolkit invocation, workflow execution, LLM call, COMMS notification. A single sticky flag on the Hub politely refuses every side-effectful endpoint with HTTP 423 Locked until the user clears it. Local read-only navigation stays available; outbound state changes do not.

What that gives you

• Cross-surface by design. Press it from the web top bar, the native sidebar, the mobile drawer, the VR settings panel, the CLI, or the MCP panic_stop tool. The Hub doesn't care which surface fired; it reacts the same way.
• Works without daemons. Even if no local agent is reachable, the Hub gate still refuses outbound work. Panic is not dependent on a local process being online.
• Reach into local processes too. Online daemons receive the panic frame on their normal poll and abort active recipes, goals, relays, and pending commands without waiting for their next user action.
• Sticky until cleared. No auto-clear, no timeout. The system stays halted until you say otherwise.
• Password-confirmed clear. Clearing the panic requires recent password confirmation. An attacker with a stolen session cookie cannot quietly clear panic to hide their tracks.
• Noisy on press and clear. Every press and every clear fires a notification through every COMMS channel you have enabled, plus your account email. Silent denial-of-service becomes loud denial-of-service.
• Append-only audit. Every press and every clear writes a forensic row: surface, IP, user agent, stopped execution IDs, stopped agent sessions, drained command count. No DELETE path exists in the code.
• Per-user blast radius. No code path can panic another user's account. The button is yours, and only yours.
• Two-tap arming on every surface. First tap arms the control for three seconds; second tap fires. Quiet warning colour, no fire-engine red. Easy to find, hard to misfire.

The 423 contract

When panic is active, every gated endpoint returns:

HTTP/1.1 423 Locked
Content-Type: application/json

{
  "error": "panic_active",
  "message": "Your account has an active emergency stop. Outbound actions are blocked. Clear it from flowdot.ai/settings/panic.",
  "panicked_at": "2026-05-12T18:23:11Z",
  "panic_clear_url": "https://flowdot.ai/settings/panic"
}

423 was picked deliberately. RFC 4918 defines it as "the resource is currently locked" - a temporary, owner-clearable condition. That is exactly what panic is, and that semantic lets clients distinguish panic from real authentication or authorisation failures and present the right user experience.

Read more on the Panic Settings page (your canonical clear surface and audit log) and below in Per-Tool Permission Gate.

Per-Tool Permission Gate

Every consequential tool call goes through a permission prompt with five scopes. The model proposes; you authorise. No tool runs the first time without you saying so.

Persisted approvals follow the user, not the surface. If you approve schwab:place_order on the desktop, the next time a voice agent on mobile reaches for the same tool, the gate already knows your answer. This is what makes a multi-surface platform usable without turning the permission prompt into a chore.

When a recipe needs human approval at a specific step rather than a specific tool, recipe authors use the gate step type. The same async hand-off path applies: a gate step can deliver its prompt to Telegram, you tap "Approve" between bites, the recipe continues. See Recipes for the step model.

Per-Surface Memory Attribution

FlowDot can persist facts about you across conversations: project context, preferences, references, feedback you've given. That is useful. It is also exactly the kind of feature that should not write implicitly. The matrix that controls writes is yours.

Every memory write is attributed to a combination of two values: the surface the call came from (web, CLI, native desktop, mobile) and the mode that drove the call (agent, recipe, goal, voice). You toggle each combination independently on the /memories page.

The toggle is enforced server-side, not just hidden client-side. When the toggle is off, the memory service early-returns before any model call and before any database write. There is no path where a memory gets written that contradicts your matrix.

Speculative Cost on Shared Results

When a workflow author publishes a shared result page, viewers see an estimated cost banner. This number is novel in two ways and worth explaining.

1. Tokens are frozen at share time. The exact prompt and completion token counts recorded by the model at execution time are preserved in the share, so the underlying usage figures cannot change later.
2. Pricing is looked up live. Every time someone views the share, the cost is recomputed from the current model price sheet. A workflow that cost three cents to run on the day it was published may cost two cents today and four cents in a year, even though the token counts are identical.

This is deliberate. The figure represents the model-level economics of the workflow, not what FlowDot would charge to run it. A viewer evaluating "is this workflow worth forking?" wants to see today's cost, not the historical price. We surface the live re-derivation and explain it to the viewer in the disclaimer modal so the number is never mistaken for a frozen quote.

Hidden nodes still count

Workflow authors can hide individual node outputs from the public share. The shared result page still counts the tokens those nodes consumed but masks their identity behind a "Hidden node" label. The privacy guarantee is column-level: the underlying usage snapshot contains only token counts, provider identities, and model identifiers. It never contains prompts, responses, tool call payloads, or node titles. The workflow author chose to share the result; surfacing the aggregate cost (including for nodes whose content stays hidden) is a transparency decision, not a leak.

Zero-Trust Agent Runtime

For agent platforms, "zero trust" is not a network primitive. It is the discipline of refusing to treat any input the model sees as authoritative, and refusing to act on the model's output without provenance-aware approval. The FlowDot CLI runtime enforces this in several specific places.

The CLI ships with a full Zero Trust audit document (flowdot-cli/ZERO_TRUST_AUDIT.md) that lists the controls, the threats they address, and the open hardening items by phase. Security work is published, not buried.

What We Refuse to Fabricate

Some agent calls legitimately do not touch the Hub. Two examples:

• Local Ollama. When you have Ollama running, the FlowDot desktop and CLI detect it and route opaque completions through it. The FlowDot server never sees the prompt body or the response. There is no row to write.
• OAuth-Codex. When you authorise your personal ChatGPT subscription via PKCE on the CLI or native desktop, the agent call goes directly from your device to your provider account. You are billed by your subscription, not by FlowDot. The Hub is not in the path.

The dishonest move would be to estimate or back-fill those calls so the Trust Center looks "complete." We refuse to do that. The page renders a permanent banner explaining which classes of call legitimately bypass the Hub, why, and where to look for receipts (the local log file on your machine, or your provider's own billing portal). Trust depends on the platform admitting what it does not know.

Related Documentation