Trust center.
This is the evidence a lender's security review asks for, answered from the platform as it is built today. It is stated as honest scope rather than as certifications or logos: what is live is described plainly, and what is a path or not yet built is named as exactly that.
Security practices.
The controls that govern the platform today: how identity, encryption, runtime isolation, logging, and secrets are handled as built, not as aspiration.
- Identity and access
- SSO over OIDC (an org registers its own issuer, client id, and client secret), TOTP multi-factor authentication with the shared secret encrypted at rest, and SCIM for automated provisioning and deprovisioning. Access is org-scoped and role-gated end to end.
- Encryption
- TLS in transit on every hop. At rest, application data lives in managed Postgres and every secret lives in Google Secret Manager, so encryption at rest is handled by the managed platform rather than by hand-rolled code.
- Least-privilege runtime identities
- Each service runs on Google Cloud Run as its own service account. The private decision engine is reachable only by the gateway's identity; the internet-facing site and console run as bare identities that hold no secrets, no invoker rights, and no project roles.
- Audit logging and retention
- Every consequential action is written to an append-only, org-scoped audit trail. Retention is a deliberate control: the trail is kept complete by default, and an organization admin can set a per-organization data-minimization window. Admins can export the full trail as CSV or JSON.
- Rate limiting and abuse controls
- Authentication is rate limited: a durable per-user budget bounds multi-factor guessing, and magic-link issuance and SCIM are paced. Cross-org isolation is enforced on every request, and outbound connectors are guarded against server-side request forgery.
- Secrets handling
- No secret lives in source. Runtime secrets are read from Google Secret Manager and scoped per service. Deploys authenticate through Workload Identity Federation, so there is no long-lived cloud key to leak. Session cookies are HttpOnly and Secure, and CORS is an exact-match allowlist, never a wildcard.
Architecture and data flow.
A request flows through a small number of hops, and personal data lives in exactly one place. The browser talks to the console, which is a backend-for-frontend: it holds no application database and proxies to the gateway over an internal address, never over public DNS. The gateway is the one authorization boundary; it applies org-scoped access, then calls the private decision engine with a signed identity token the engine verifies before it does any work. The decision engine renders the call and writes it to managed Postgres, where the application data and the immutable audit trail live. Decision traces flow to the observability tool only when tracing is enabled. The marketing site you are reading now is static and separate: it holds no personal data, no database, and no path into the decision engine.
Internal security audit, June 2026.
In June 2026 the platform went through an internal security audit: an adversarial read-only review of the gateway, the decision engine, the agent, and the deploy configuration, against both a malicious authenticated tenant and an unauthenticated attacker. It found no critical or high-severity exploitable vulnerabilities. The bounded findings it did raise were remediated and deployed, and the fixes are verified in the deploy pipeline on every ship. This was an internal audit, not a third-party attestation, and it is named as such.
- IAM least-privilege split
- The single shared runtime identity was split into per-service accounts. Only the gateway's account can invoke the private decision engine; the site and console hold no secrets and no invoker rights, so a compromise of an internet-facing app cannot reach the engine.
- Durable auth rate limits
- The multi-factor per-user attempt budget was moved to a durable counter so the ceiling holds exactly regardless of how many instances autoscaling runs, closing a limit that had multiplied per process.
- SSRF guards
- Outbound connector calls are routed through a guard that blocks requests to internal and private-network addresses, so a crafted endpoint cannot be turned into a request against internal metadata or services.
- Service-to-service authentication
- The decision engine, already private at the network layer, now also verifies a Google-signed identity token (audience and issuer) inside the app as fail-closed defense in depth, so it is no longer one infrastructure flag away from exposure.
- Token handling
- Login, invite, and SSO tokens were taken out of URL query strings and the referrer surface was tightened, so a single-use token cannot leak through browser history, referer headers, or proxy logs.
Subprocessors.
The third parties the platform relies on, each with its purpose and the data category it can see. The list is derived from the deploy configuration and the code, so it reflects what the platform actually calls.
- Google Cloud Platform
- Application hosting, container registry, and secret storage (Cloud Run, Artifact Registry, Secret Manager).
- DataAll application data at rest, in the hosting region.Regionus-central1
- Supabase
- Managed Postgres: the primary application database and its automated backups.
- DataApplication records, including decision data and account data.RegionConfigured per project
- Anthropic
- The Claude API: the model the decision engine calls to render a decision.
- DataThe decision inputs for one application, sent for inference only.RegionUS API endpoint
- Resend
- Transactional email delivery (magic-link sign-in and organization invitations).
- DataRecipient email address and the message contents.RegionProvider-managed
- Langfuse
- LLM observability: the per-decision agent trace, when tracing is enabled.
- DataDecision traces: the agents' prompts and outputs, including the application's numeric decision facts (for example credit score, income, and debt ratios) keyed to an opaque applicant id. No names, no free-text applicant input, no account credentials.RegionProvider-managed
Data handling.
What can be exported, how long data is kept, how return and deletion are handled, and the posture on sending decision inputs to the model provider.
- Export
- An admin can export their organization's full audit trail on demand, as CSV or JSON, and the organization's complete data as a checksummed archive with credential material redacted. Every export is scoped so it can never read another organization's data.
- Retention
- The audit trail is append-only and kept complete by default. An organization admin can set a per-organization retention window so events are trimmed beyond it while staying complete within it; absent one, the platform-level default applies.
- Return and deletion
- Both are self-serve. Data return is the full-organization export, produced on demand. Deletion is a two-phase offboarding: a reversible offboarding state first, then a separately confirmed, owner-only purge that hard-deletes the organization's data and issues a destruction certificate recording what was removed. The append-only audit trail is deliberately retained, with the destruction itself recorded on it.
- Model provider
- Rendering a decision sends that application's decision inputs to the model provider for inference only, as part of producing the decision. We state the API-usage posture and do not make claims on the provider's behalf beyond it.
Vendor questionnaire, quick answers.
The questions a security review asks first, each answered in one honest sentence. They restate the facts above in the short form a questionnaire expects.
- Where is the application hosted?
- On Google Cloud Run in the us-central1 region, with the container images in Google Artifact Registry.
- Is data encrypted in transit and at rest?
- Yes: TLS in transit on every hop, and at rest through managed Postgres and Google Secret Manager.
- How is access controlled?
- SSO over OIDC, TOTP multi-factor authentication, and SCIM provisioning, with org-scoped, role-gated authorization on every request.
- Is activity logged and auditable?
- Yes: an append-only, org-scoped audit trail records consequential actions, and admins can export it as CSV or JSON.
- Do you use subprocessors?
- Yes: Google Cloud Platform, Supabase, Anthropic, Resend, and Langfuse, each listed above with its purpose and the data it sees.
- How are secrets and deploy credentials managed?
- Secrets live in Google Secret Manager, never in source, and deploys use Workload Identity Federation, so there is no long-lived cloud key.
- Where does data reside?
- Application data resides in the us-central1 hosting region; a subprocessor that renders a decision or sends mail sees only the data it needs for that task.
- How is data backed up?
- The primary database is managed Postgres, which provides automated backups on the managed platform.
- Has the platform been security tested?
- An internal security audit was run in June 2026; every finding was remediated and deployed, with the fixes verified in the deploy pipeline.
- Do you have a security contact?
- Yes: [email protected], and the full due-diligence pack is available on request through the pilot form.
- Is the decision engine exposed to the internet?
- No: it is private, reachable only by the gateway's identity, which presents a signed token the engine verifies inside the app.
- Does the marketing site hold customer data?
- No: this site is static and holds no personal or customer data; it runs as a bare identity with no secrets and no access to the decision path.
- Is there a status page and an uptime commitment?
- Yes: the live status page reports real uptime for the gateway API and the decision engine, computed from continuous internal health probes, against a 99.9 percent monthly availability target. A contractual SLA is set in a lender’s agreement.
Security contact.
For a security question or a vulnerability report, write to [email protected]. For the full due-diligence pack, request a pilot and note that you are in security review; the pack is shared on request.
The related regulatory and model-risk posture, including the SOC 2 readiness path, is on the compliance page.