How we protect accounts, workspaces and the code you generate

Accounts sign in with email and password or a supported social provider. Passwords are never stored by us in readable form; credential storage, hashing and email verification are handled by our managed authentication provider. Sessions use short-lived access tokens with refresh, and signing out revokes the session on that device.

Workspaces on Business and Enterprise plans can require single sign-on and manage members and roles centrally. Operator access to the platform console is separate from customer accounts, is limited to named staff roles, and critical actions require a second authorised approver or step-up verification before they take effect.

Every project, message, credit entry and deployment record is scoped to a workspace, and access is enforced in the database with row-level policies rather than only in the application. A request that is not a member of a workspace receives no rows. We run an automated isolation test suite that attempts cross-workspace reads and writes and fails the build if any of them succeed.

Traffic to the product and its APIs is served over HTTPS/TLS. Database storage and backups are encrypted at rest by our managed hosting provider. Provider API keys you add — hosting, repositories, model providers, external databases — are stored as secrets, are write-only in the interface once saved, and are decrypted only inside server-side code that needs them for a run.

Prompts and generated files are stored so you can resume a project, replay a run and export your work. Workspaces on Business and Enterprise plans are excluded from the platform improvement corpus; for other plans the signals we retain are de-identified and reviewed before they influence platform defaults. Card details never reach our systems: checkout and billing are handled by our reseller and Merchant of Record, Paddle.

Build runs, deployments, credit debits and administrative actions are recorded with a request identifier and a timestamp, so a charge or change can be traced to the run that caused it. Members can review their own workspace's credit ledger, deployment history and audit log. We aim to keep logs no longer than we need them for security, billing and debugging, and to remove or de-identify them after that.

Report a suspected vulnerability to support@ischolarx.com with enough detail to reproduce it. Please avoid testing that degrades the service for others, and do not access data belonging to another workspace. We aim to acknowledge reports within two business days and to keep you updated while we investigate. We do not currently run a paid bounty programme.

When we confirm an incident we contain it first, then assess what data and which workspaces are affected, restore normal service, and record what happened and what we changed. Where an incident affects personal data and notification is required by law, we notify the relevant supervisory authority and affected customers with the facts known at the time, and follow up as the picture becomes clearer. Timelines depend on the incident, so we do not publish a fixed guarantee.

Use a unique password and enable single sign-on where your organisation supports it. Review workspace members regularly and remove people who no longer need access. Treat generated code as code you own: check it, keep secrets out of it, and rotate any provider key that has been shared or committed by mistake.