Security & Trust
What an auditor gets.
Trustward is built so a risk committee can verify controls in the apps it can finally see. Here's what the platform enforces, and the evidence it hands you.
Where data can and can't go.
Real data and credentials live only behind the broker. Apps get scope-bound, short-lived credentials with row and column limits and masking enforced in the database. Outbound traffic is denied by default, and production runs isolated inside your own cloud. There's no back door to route around at runtime, because the broker holds the only real credential.
Why a control is required
You can't prompt your way to safe code.
The case for a deterministic control, in the numbers an auditor will want.
40 to 62%
of AI-generated code carries vulnerabilities; the OWASP pass rate sat flat near 55% across 2025 into 2026 even as coding benchmarks climbed.
Independent studies · Veracode
2.74×
the vulnerability rate of human-written code, in AI-authored pull requests.
CodeRabbit, ~470 PRs
91.5%
of 200-plus assessed apps had at least one flaw traceable to AI hallucination.
Q1 2026 assessment
2,000+
vulnerabilities, plus 400-plus exposed secrets and 175 instances of live PII, across 5,600 deployed apps.
Escape.tech
Telling an agent to be safe isn't the same as enforcing it. A constraint has to be a deterministic check in the pipeline, which is what the controls below are.
Threat to control
What can go wrong, and how it's contained.
| What can go wrong | How Trustward contains it |
|---|---|
| A builder pastes real data into an outside model | Build runs on synthetic data in a sandbox with egress denied. |
| An app gets more access than it needs | The broker scopes data to rows and columns, classifies, and masks. |
| An app sends data to an outside endpoint | Outbound traffic is denied by default. |
| A credential ends up in the code or chat history | Secrets are injected only at runtime, never exposed to the tool. |
| A dead app stays wired to production | The registry tracks ownership and time-to-live, with a kill switch. |
| You can't prove how data flows | Observability, audit, and lineage produce the evidence. |
The architecture in the terms you'll ask about.
Four trust boundaries carry the whole model.
Harness boundary
Everything runs inside your own cloud or VPC (BYOC). Data and secrets don't cross out of it.
Broker boundary
The broker holds the only credentials to source systems. No app, agent, or workspace ever receives a raw source-system credential.
Build-versus-runtime boundary
At build time the only data available is synthetic. Real data is brokered only at runtime, inside the harness.
Egress boundary
Outbound network from the workspace and the app is default-deny, allow-listed to the broker, approved model endpoints, and approved SaaS.
Enforcement model
Scope is enforced in the database through row-level security mapped to a short-lived, scope-bound credential, column grants, and masking views, so least privilege holds even if app code is wrong. Writes are read-only by default, gated, and reversible.
Isolation
Each app and each agent session runs in microVM-level isolation, separating agent execution from data, with per-session network namespaces.
Secrets
Injected at runtime only, workload-scoped and short-lived, rotated automatically. No secret touches code, bundle, repo, or chat history. Commits containing credentials are blocked at the deploy gate.
Deploy gates
Deterministic checks in the pipeline, not prompts: SAST, software-composition and supply-chain analysis, secret scanning, an authorization and RLS verification, and a dependency allow-list against hallucinated packages.
App front door
SSO-gated and RBAC-scoped from creation, private by default, no public URL without a reviewed publish step. An app inherits the builder's own data entitlements and can't exceed them.
Residency and keys
Governed data lives in an isolated store encrypted with customer-managed keys, region-pinned, with classification tags propagated through transforms and a TTL and purge policy.
Evidence
Access, runtime, and model-call logs plus a source-to-dashboard lineage graph, exportable to your SIEM.
Where we are on compliance
Controls are demonstrable today and built toward certification, not yet certified. The registry and audit export speak SOC 2 Security first, then SOX ITGC, then GDPR where there's EU data, then FINRA where the customer is regulated. We'll show you the control surface working before you commit.
Demonstrable, not certified
We won't claim a certification we don't hold. “SOC 2 demonstrable” means the controls are designed, documented, and shown working, the certification itself comes next.