DT 1.5 treats a signed-in account, a workspace membership, a connected credential, and a merchant approval as separate requirements. Holding one does not grant the others.
The backend verifies the signed-in session and the user's workspace membership before reading or changing workspace data. Administrative actions require the matching workspace role.
Credential values submitted through Connections are encrypted with AES-GCM before storage. The encryption key remains a server secret, and saved credential values are not returned to the browser.
A Shopify write must match the audited hostname to one authorized active store. A missing or ambiguous match blocks automation instead of selecting a destination by guesswork.
Approval covers the exact object, before state, proposed state, destination, and allowed limits. The system rechecks current state and authority before execution so a stale approval cannot silently authorize a different change.
The URL entered is sent to the audit service, which reads publicly reachable pages. Do not submit private, password-protected, signed-preview, local-network, or customer-specific URLs.
Provider credentials are used server-side only for the requested connected workflow. Connection metadata shown in the dashboard excludes the saved secret value.
A model key connected in the dashboard is encrypted server-side and used for the model requests you initiate. CLI keys stay in the local environment and go provider-direct. External page content is treated as untrusted data, not as permission or system instruction.
Dashboard pages are excluded from search indexing. Authentication and server-side authorization protect workspace data; crawler rules are not treated as a security boundary.
Supported writes are logged, bounded, and read back where the provider supports it. Missing permission, stale state, failed verification, rate limits, and provider uncertainty remain visible failure states.
Confirm account, permission, object, current state, approval, and safety limits.
Prevent duplicate or conflicting execution of the same approved action.
Use the account-bound provider adapter and record the provider response.
Mark success only when the actual supported state can be confirmed.
Email [email protected] with the affected URL, what you observed, steps to reproduce, and a safe way to reach you. Do not include access tokens, customer data, or exploit data in the first message.