Authenticated product boundary
The customer workspace is served separately from the public marketing site. Product routes require an authenticated session and server-side tenant resolution.
Trust Centre
Controls buyers can understand and operators can verify.
This page describes ONSET's current product boundaries. It does not claim an external certification that ONSET has not completed, and it does not treat a provider's certification as our own.
Implemented boundaries
How the product limits and records access.
Account-scoped module access
Module availability is evaluated for the current account. Platform readiness and account enablement are separate controls.
Server-side provider credentials
Supported provider keys are submitted through authenticated server routes and displayed back as presence only. Secret values are not returned to the browser after storage.
Operational evidence
The product records module runs, provider usage and selected audit events. Coverage is checked per module during production-readiness certification.
Explicit decision boundaries
Work that requires a person should expose a clear approve, reject or revise path. Financial, public and destructive actions require a separate operating boundary.
Readiness shown honestly
Available, disabled, deferred and quarantined capabilities are distinguished. A capability that lacks its required provider or runtime proof must fail closed.
Published information
Start with the current record.
Procurement
Ask for the current scope.
Provider relationships, data regions and contractual terms can change. ONSET will provide the current sub-processor and data-flow scope for the modules included in a proposed customer implementation.
Security, privacy and compliance questions should be tied to the actual workflow and provider set rather than a generic platform claim.
Send a procurement question