Trust Center

Sign-in uses one shared identity provider keyed on a single account id across every Skills Tech product; no second identity store.

Owner/admin/member capabilities gate every write action server-side (invite, connect repo, manage settings, manage SSO, view audit); members hold no write capability.

A self-serve console verifies your domain (DNS TXT), registers your IdP metadata, and enforces SSO per domain. Live SAML provisioning requires enterprise setup on our side; until enabled the console previews the flow and reports provisioning pending (it does not fake success).

Automated directory sync (SCIM) is on the roadmap after SAML provisioning is live. Not built today.

Workspace holds account identity, team/seat structure, entitlement metadata, and Proof Portfolio references and scores, not source code. Repository analysis runs in the products that own it (e.g. local, on your machine).

Your source code is not used to train AI models anywhere in the platform, including AI features.

Proof records carry metadata and safe-derived fields only. Ingested evidence is validated (key + value scans) and cert payloads are projected to a safe-derived allowlist before storage; raw content is rejected or dropped.

TLS on all surfaces and APIs; data at rest encrypted by infrastructure providers; secrets held in provider-managed stores, never in source control.

Region pinning for data at rest is available only under an enterprise agreement and provisioning; there is no self-serve residency control today.

Consumer-visible retention windows and a deletion-on-request SLA are being formalized; today deletion is handled on request without a contractual SLA.

The policy contract, a fail-closed decision engine, and a per-organization policy editor (workspace settings, admin-gated) are implemented and tested (disable AI, local-only, provider/model/endpoint allowlists, block source transmission, data-classification ceiling, BYOK-required). Runtime enforcement in the AI gateway is the remaining piece; do not rely on it for compliance until gateway enforcement is live.

AI processing is disclosed per action via the shared disclosure contract; the provider matrix below states what is used, retention, and training posture.

An admin can approve a product + AI configuration for a level of work (blocked / personal-use-only / approved-internal / approved-confidential); each approval is bound to a config fingerprint and invalidates automatically when the configuration changes. Implemented and tested. Product-side enforcement of the effective status is the remaining piece.

Governance actions (visibility changes, approvals, share links, SSO changes) are logged workspace-scoped and viewable by admins.

A workspace admin (view-audit capability) can export the workspace audit log as CSV from a one-click Export button on the audit log, or via the endpoint directly; the export is privacy-preserving (actor display names and action labels, not internal user ids, formula-injection safe).

Other products emit safe-derived audit events (audit-event-v1: actor, dotted action, category, safe label) into the workspace audit store via a secret-gated server-to-server endpoint. The shape has no free-form blob, so raw content cannot leak.

A DPA, subprocessor list, and acceptable-use policy are published (see the legal pages). A counter-signable executed DPA is available under an enterprise agreement.

Executing and storing a counter-signed DPA is handled as part of an enterprise agreement, not self-serve.

We hold no SOC 2 report today and do not claim one. When a formal audit completes we will state it here with the report available on request, and not before.