Skip to content

How it works

The broker is the keystone.

Real data and real credentials stay behind the broker. It issues scope-bound, short-lived credentials and sets enforcement inside the database itself, so an app physically can't reach data it wasn't cleared for. One mechanism protects every tool at once.

The keystone diagram: authoring tool to broker to governed runtime and registry. The broker is the watched gate. The build-time path runs on synthetic data; the runtime path is scoped, masked, and logged.

Build time runs on synthetic data.

While your team builds, the coding tool works against synthetic, schema-faithful data inside a sandboxed workspace, with outbound traffic denied by default. The dangerous paste into an outside model has nothing real to leak. The schema looks right, the logic develops correctly, and no live record ever leaves the boundary.

Runtime serves scoped, masked, logged data.

When the app goes live, it gets exactly the rows and columns it needs, masked and logged, through a credential that can reach nothing else. It runs in isolation inside your cloud and serves through an SSO-gated URL. Every read is recorded.

Build versus runtime: build time on synthetic data under default-deny egress, runtime on scoped, masked, logged real data, showing real data never touches the tool.

The registry and the audit trail

Every app is on the map.

Each app enrolls in a registry with an owner, a purpose, the data it touches, and its governance tier. The CFO can pull a clean inventory and lineage report for any app, and can turn one off. New or sensitive data sources surface a per-app approval; routine, low-sensitivity sources clear once under standing policy, so the hundredth finance app is as light to approve as the first.

The app registry: rows of finance apps with owner, data touched, tier, and a cleared, flagged, or contained status chip.
An append-only audit log with approvals and a source-to-dashboard lineage graph.

Walkthrough

A 13-week cash forecast, governed end to end.

  1. 01

    An analyst describes the app in the coding tool they already use.

  2. 02

    Trustward stands up a sandbox with synthetic versions of the bank feed, AP, AR, and payroll. The build happens against data that looks real but isn't.

  3. 03

    At promotion, a shadow run proves the logic against real data before anything goes live.

  4. 04

    The app runs in your cloud, behind SSO, reading only the scoped, masked tables it was granted.

  5. 05

    The CFO sees the app in the registry the moment it ships, with its owner, its data, and its kill switch.

One workflow, one team, governed the whole way, and nobody had to slow down.

For analysts & builders

Want the technical version?

If you're the analyst or engineer doing the building, there's a page for you: the broker as plain Postgres, building on stand-in data, least privilege from your real queries, the deploy gates, and MCP. The CFO never has to read it.

Go to the builder docs

See it on your own workflow.

Start with one workflow, working directly with our team.

Request demo access
See what an auditor gets