Customer developer docs

Platform security posture

Access and identity, data boundaries, evidence integrity, and operational controls.

Platform security posture

Access and identity

  • Console authentication supports password sign-in with per-user TOTP two-factor authentication, and tenant-bound SAML SSO with email-domain discovery for enterprise tenants.
  • SCIM provisioning (Users, Groups, and group-to-role mappings) lets an identity provider manage membership; authentication without an active tenant membership is always unauthorized.
  • Roles separate owners, admins, and viewers. Review approvals, definition publishing, and final export authorization require named admin or owner actors. Viewers cannot mutate state.
  • Platform-side administrative access is scoped per tenant and audit-logged, with break-glass access explicitly gated.

Data boundaries

  • Read-only integrations only: Definite never holds write credentials to your systems, never initiates transactions, and never files on your behalf.
  • Per-tenant databases and per-tenant audit ledgers; tenant credentials and transport keys live in a cloud secret manager, resolved at runtime, never stored in application rows.
  • The agent runtime is stateless — no database, no stored source documents, bounded declared inputs per request, and no source rows or payloads in logs.
  • Secrets, credentials, payment data, and customer content are non-loggable by default; logs prefer stable identifiers (request ID, key ID, checkpoint ID).
  • Client data is never used for model training.

Evidence integrity

  • Receipts and ledger events are append-only, hash-chained, and signed (Ed25519 or KMS-backed ES256), with database immutability triggers as a backstop.
  • Checkpoints are externally witnessed in object storage and optionally countersigned by an RFC 3161 timestamp authority.
  • Public verification keys are published at /.well-known/jwks.json; rotation retains prior keys so historical evidence keeps verifying. See independent verification.

Operations

  • Production runs in AWS behind TLS: the control plane and agent runtime run as private services, the runtime reachable only from the control plane, with managed Postgres and object-lock-capable storage for ledger anchors.
  • Signing supports AWS KMS with documented key-rotation runbooks; previous public keys stay published for historical verification.
  • Backup and disaster recovery targets, quarterly access reviews, incident response, and a current subprocessor list (AWS, Supabase, Resend, Slack, PagerDuty) are maintained as operator runbooks and are available to customers on request.