Trust

Security described concretely

This page states what the platform actually does. Where a control is still in progress or has a real limit, we say so rather than rounding up.

Deny by defaultTenant-bound persistenceAppend-only auditNo long-lived cloud keys

Secrets

Provider credentials live in AWS Secrets Manager under per-environment, per-organization paths, encrypted with a customer-managed KMS key that rotates automatically.
Only opaque references are persisted in platform data — never the secret itself.
Secrets resolve server-side at execution time and are never returned to a browser, model, workflow, log, or audit payload.
Production workloads authenticate with short-lived, certificate-bound credentials issued through IAM Roles Anywhere. There are no long-lived AWS access keys to leak.
The worker's entire cloud permission set is three actions: read a tagged secret, describe it, and decrypt it. Decryption is pinned to Secrets Manager, so the key cannot be used directly.
Credential-shaped headers and fields are redacted at every logging boundary.

Tenant isolation

Every persisted record and execution context carries an organization identifier.
Authorization is evaluated before lookup or execution — not after.
Two versioned vault domains per organization: one external-credential bundle, one separate payload-encryption keyring.
Neither domain may contain another organization's material or platform-administration credentials.
Registering a credential uses a different identity than reading one — scoped by tag to the external-credential domain, able to create bundles and add versions, but with no authority to delete a secret and no way to use the encryption key outside Secrets Manager.
Rotation, revocation, suspension, and offboarding invalidate affected material immediately.

Model boundary

Models receive the minimum data needed for a step.
Guardrails can redact, block, transform, or require approval before a model is reached.
A model can recommend an action but cannot bypass connector permissions or workflow policy.
Workflow definitions cannot select secret references at all.
Customer credentials and platform-provided credentials route through separate resolvers with no fallback between them.

Connector boundary

Connectors declare read and write capabilities separately.
Write operations require explicit workflow grants, idempotency keys, and optional human approval.
Incoming webhooks require signature verification and replay protection.
Adapters receive a secret reference and resolve it only inside their server-side protocol boundary.

Identity & authorization

Authentication establishes identity. We own authorization.

The two are kept deliberately separate. Your identity provider says who someone is; the platform decides — every time — what that person may do inside your organization.

Verified tokens only

OIDC tokens are verified against an injected HTTPS issuer, audience, an asymmetric algorithm allowlist, JWKS, expiry, issued-at maximum age, and clock tolerance.

External claims never become permissions

Verified external tenant and group claims can satisfy a narrowly configured identity binding, but the resulting actor receives roles only from an active organization membership you own.

Hardened browser sessions

OAuth state is bound to a short-lived HttpOnly PKCE cookie, redirects derive only from the identity catalog, logout requires an exact same-origin POST, and session cookies stay host-only with a bounded lifetime.

Nothing sensitive in deferred work

Durable workflow requests and approval checkpoints never serialize permission, role, assurance, session, or token claims — only a tenant-bound actor reference that is re-authorized on resume.

Data handling

Where your data sits and how long it stays

Encryption at restAES-256-GCM

Protected execution payloads are encrypted with tenant-selected keys resolved through the secret boundary. Tenant, execution, reference, and purpose identifiers are authenticated with the ciphertext.

Database exposurePrivate network only

PostgreSQL is reachable only on the private network, and database passwords are file-mounted secrets rather than environment values or connection URLs.

MigrationsChecksum-locked

Schema changes are checksum-locked so a migration cannot silently diverge between environments.

RetentionPolicy-bound

Idempotency records and protected payloads expire on configured schedules, coordinated so a record never promises a replay whose payload has already expired.

Audit

Recorded on purpose, and redacted on purpose

Audit events are append-only and contain identifiers, policy decisions, timing, and redacted summaries. Execution failures are recorded as coarse categories rather than exception messages or vendor response bodies. Idempotency records hold request fingerprints and opaque payload references, never raw request or result data.

Successful reads of the audit stream are themselves authorized and audited, evidenced with only the actor, page size, result count, and cursor presence.

Never written to audit

Secret values
Unrestricted source payloads
Exception messages
Vendor response bodies
Model output

On dependency scanning: the platform's dependency audit command transmits dependency and advisory metadata to a public advisory service. That narrow command does not authorize transmitting source code, secrets, credentials, customer information, business data, or arbitrary repository contents. Any other external scanner carries its own approval and data-boundary requirement.

Security review

Bring your security questionnaire

If your team needs to review controls before a pilot, call us and we'll go through them directly — including the areas that are still in progress. Detailed architecture and security documentation is available under NDA.

Call us directly888-497-2999

Book a demo Call now