Request protection, run-scoped credentials, and new roles

A security review of the request surface, and of how runs reach credentials, shipped as a set of protections. None of them change how a workflow is written; they narrow what a request or a run can reach.

How it works

• One trusted-origin list. Cross-origin settings, sign-in, file storage, the OAuth popup, session handling, and live connections all read the same list. A state-changing request from an untrusted origin is rejected.
• Run credentials bound to the declaration. A run can use only the credentials, databases, and stores its own slots declare, and the database proxy checks that a credential belongs to the run before connecting.
• Validated connection fields. An OAuth connection accepts only the fields an integration declares, such as an instance URL, each checked against its allowed pattern before anything is stored.
• Retry-safe top-ups. A credit purchase carries a request ID, so a retried submit can't charge twice.
• Clearer connect links. The hosted page that completes a connection names the workspace and the person who asked.

New permissions

Manage workspace models, and Manage subscription and seats. Both default to Admins and Owners and are enforced on the server as well as in settings.