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.
45%
of AI-generated code fails security tests; the security pass rate has stayed near 55% across 2025 into 2026 even as coding benchmarks climbed.
2.74×
the security-issue rate of human-written code, in AI-authored pull requests.
2,000+
vulnerabilities, plus 400-plus exposed secrets and 175 instances of live PII, across 5,600 deployed apps.
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.
How vibe-coded apps fail
Where the numbers come from.
The defects above aren't exotic. They're the same handful of shortcuts an AI tool takes to make something work fast, each one harmless on its own and dangerous in a system that touches money. These are the failure modes, in plain terms.
Secrets end up in the code
To connect an app to a real system, the fastest path is to paste a live database password or API key straight into the code or the chat. From there it spreads, into the repository, the version history, and the AI tool's logs, and it's nearly impossible to claw back.
The app can read everything
An AI tool wires an app to the whole database because that's the simplest thing that works. A forecast that only needs revenue ends up able to read payroll, AP, and the operating account, because nothing limited it to what it actually needed.
Real data leaves to get help
When a build stalls, the natural move is to paste real numbers, an export, a customer list, a payroll file, into an outside model to debug it. That data is now outside your control, with no record that it ever left.
Invented and untrusted dependencies
AI tools confidently pull in software packages, and sometimes invent names that don't exist, which attackers then register and fill with malicious code. One hallucinated dependency can quietly open a door into everything the app touches.
Shipped wide open
A vibe-coded app often goes live with no sign-in and a public URL, because authentication is the boring part the model skips. Anyone who finds the link reaches whatever the app can reach.
Nobody owns it afterward
The app that ran one report in March is still connected to production in December, owned by no one, patched by no one, on a list that doesn't exist. It's the breach you find out about last.
None of this is the builder being careless. It's what “just make it work” produces by default. The fix isn't a more careful prompt, it's a control that makes each shortcut impossible. That's the map below.
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, and a deterministic screen blocks secrets and records from the prompt before it reaches the model. |
| An app gets more access than it needs | The broker scopes data to rows and columns, classifies, and masks; a read outside the app's approved scope fails closed and is logged, never widening access. |
| An app sends data to an outside endpoint | Outbound traffic is denied by default, and a generated app that tries to call out is refused at publish. |
| 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 every app and its owner, with a kill switch that cuts data access and produces a signed receipt you can verify independently. |
| The database itself is misconfigured | A signed check runs on every deploy and asserts the configuration the broker depends on, so least privilege can't inherit a flaw underneath it. |
| 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. A read outside the app's approved sources fails closed and is logged. A signed check on every deploy verifies the database configuration the broker depends on, so enforcement can't inherit a misconfiguration underneath it. Access is read-only by default; there is no write path for an app to execute today, and when writes are enabled they run through the broker with approval and limits, never as a standing grant.
Isolation
Trustward is architected to run each app and each agent session 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: linting and build verification, dependency and supply-chain audit, secret scanning, a signed database-configuration check with real-database RLS verification, and a content lint that refuses to publish a generated app that tries to call an outside endpoint. Deeper static analysis (SAST) and a dependency allow-list against hallucinated packages are on the roadmap.
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.
Built to the controls auditors test
Trustward's registry and audit export are designed around SOC 2 Security first, then SOX ITGC, then GDPR where there's EU data, and FINRA where you're regulated. The controls are designed, documented, and demonstrable today; formal certification is on the roadmap. We'll walk your risk committee through every one before you commit.
Where we stand on certification
Trustward is in private preview, and we haven't completed a formal SOC 2 or SOX audit yet. We built the product to those standards from the start, so the scoped access, full logging, and evidence trail an auditor expects are already in place and demonstrable. We'll pursue certification as we scale. Until then, you and your auditors are welcome to review the controls firsthand.
For your security team
Forward this page. Here's what they'll ask first.
The CFO evaluates Trustward; the security team reviews it. These are the answers to the first six questions we hear from that review, stated plainly.
Where does customer data live?
In production, inside your cloud or VPC. Trustward reads data in place and never copies it out to us. The hosted private-preview demo touches synthetic data only.
Is customer data used to train models?
No. Your data is never used to train any model, and real data never reaches the AI coding tool, at build time or after.
What's the credential model?
The broker holds the only real credentials to source systems. Apps and workspaces receive scope-bound, short-lived credentials, with row limits, column grants, and masking enforced inside the database itself. No raw key ever reaches an app or a tool.
What's the network posture?
Outbound traffic from workspaces and apps is denied by default, allow-listed to the broker, approved model endpoints, and approved SaaS. Deployed apps serve through SSO-gated URLs only, and the app itself runs contained: a frame with no outside network access and no credentials, with brokered, scoped data injected at render.
Can the audit log be tampered with?
The access log is append-only and hash-chained: each record carries a digest linked to the one before it, so editing, deleting, or reordering any row is detectable on verification. The chain head is anchored outside the control plane, so you can confirm a kill and the log's integrity without having to trust the console.
What's certified today?
Nothing yet, and we won't claim otherwise. Controls are designed, documented, and demonstrable now, built toward SOC 2 first. Ask us for the security disclosure brief and we'll walk your team through the full model.