For analysts & builders
Keep your tools. Keep your speed. Ship governed by default.
You keep building the way you build. Trustward governs the two things that actually leak, the data connection and the production runtime, and stays out of your editor. No SDK to learn, no security plumbing to wire, no ticket to wait on.
Bring your own tool
It looks like an ordinary database, because it is one.
Build in Claude Code, Cursor, Codex, or a hosted builder. Your app connects to what looks like standard Postgres and a REST endpoint, with no Trustward SDK in the way. The broker issues a scope-bound, short-lived credential and enforces row-level security, column grants, and masking in the database itself, so the app physically can't read data it wasn't cleared for.
$ psql $DATABASE_URL
connected to trustward (postgres 16)
> select * from ar_aging limit 3;
3 rows · scoped · masked · logged
> select * from payroll;
permission denied: out of scope for this app
How a build goes
From a prompt to a governed app, without leaving your flow.
- 01
Describe what you want to build, in the tool you already use.
- 02
Trustward spins up a sandbox seeded with synthetic, schema-faithful data, including the edge cases that break finance logic.
- 03
Build and iterate. A scope observer watches the columns you actually read, so least privilege comes from your real queries, not a guess.
- 04
At promotion, a proof run executes your app against a brokered slice of real data, inside the boundary, to confirm the logic holds.
- 05
Go-live checks run automatically: SAST, dependency and supply-chain scanning, secret scanning, and an authorization and RLS verification.
- 06
Your app ships to a governed runtime in your own cloud, behind SSO, reading only the scoped, masked tables it was granted.
Under the hood
The mechanics, in the terms you'll ask about.
The broker looks like an ordinary database.
Your app connects to what looks like standard Postgres and a REST endpoint. There's no Trustward SDK to learn. Under the hood the broker issues a scope-bound, short-lived credential and configures enforcement in the database itself: row-level security mapped to that credential, column grants, and masking views. The broker sets the rules and steps off the wire, so there's no per-query proxy hop. The overhead is an indexed predicate plus a view.
You build on stand-in data that behaves like the real thing.
The sandbox seeds synthetic, schema-faithful fixtures: real table shapes, types, and relationships, plus the edge cases that break finance logic (unmatched items, timing differences, duplicates, nulls, negatives, and FX). The workspace runs under default-deny egress, so a paste into an outside model has nothing real to leak.
Least privilege comes from what you actually query.
A build-time scope observer watches the columns your app reads against the fixtures, so the data-access request is the minimal set you demonstrably used, not a broad guess. That captured scope becomes the approval the CFO or data owner sees.
Promotion runs two checks in parallel.
A proof run executes the finished app against a brokered slice of real data, inside the boundary, to prove the logic, without that data ever reaching the authoring tool. Deploy gates run deterministic checks before go-live: SAST, dependency and supply-chain scanning, secret scanning, an authorization and row-level-security verification, and a dependency allow-list that blocks hallucinated packages.
It speaks MCP.
Trustward exposes the broker, secrets, deploy path, and runtime logs to the agent over MCP, and injects an auto-generated context file that carries your org's data policy into whatever tool you open.
Your deployed app stays fast.
The app reads a governed, pre-normalized lake inside your cloud, refreshed on a schedule that matches the workload (a cash forecast is batch-fresh: nightly, or hourly for the bank feed), so the dashboard never waits on a slow upstream.
The relief
What you don't have to do.
The governance is the platform's job, not yours. You write the app; the controls run underneath.
- Learn an SDK. The broker is just Postgres and REST.
- Wire up auth, secrets, or network policy. Secrets are injected at runtime; the app is SSO-gated from creation.
- Wait on IT or security for a data pull. Your queries define the scope, and routine sources clear under standing policy.
- Hand-roll an audit trail. Access, runtime, and lineage logs fall out of normal use.
Builder questions
The questions developers ask first.
What languages and frameworks can I use?
Whatever you build with. Trustward governs the data connection and the runtime, not your stack, so your framework, language, and libraries are your call. The broker presents as standard Postgres and a REST endpoint.
Can I use my own packages and dependencies?
Yes. Real packages you choose go through. A deploy gate checks dependencies against a known-good allow-list and blocks hallucinated or unpublished ones, and it runs at promotion, not in your editor.
How does auth work in the app I build?
Your app is SSO-gated and private by default, and it inherits your own data entitlements, so it can't reach anything you couldn't. Secrets are injected at runtime, never in your code, bundle, or chat history.
Will the governance slow me down?
No. You build against stand-in data, and at runtime the broker sets the rules and steps off the wire, so there's no per-query proxy hop. The governance runs around your work, not through it.
Where do my logs and errors go?
Access, runtime, and model-call logs are captured and exposed back to your agent over MCP, alongside a source-to-dashboard lineage graph the CFO can read.
Scope note: the current pilot runs the fully-governed path with terminal-based tools like Claude Code, and the architecture extends to Cursor, Codex, and hosted builders. Some isolation hardening is on the roadmap, not the pilot.
Build the first one with us.
Start with one workflow in the private preview, working directly with the team building Trustward.