Security

We assume that generated code can be wrong, that a prompt can be adversarial, and that any single control can fail. The platform is therefore built in layers: identity, authorisation in the database, secret isolation, container containment, quota enforcement, audit logging, and monitoring. A failure in one layer should not expose another tenant's data.

• Email with password and Google sign in are handled by a managed authentication service, so we never see raw passwords.
• Passwords are stored only as salted hashes by that service, with modern work factors.
• Sessions use short lived access tokens plus rotating refresh tokens, and sign out revokes the session.
• Password reset uses single use, time limited links, and the reset endpoint does not reveal whether an address exists.
• Security relevant events, such as password change and new sign in, generate an email notice.
• Suspicious authentication patterns are rate limited and can trigger a temporary lockout.

Every table that holds tenant data has row level security enabled with explicit policies, and the Data API grants are scoped to the roles those policies allow. Reads and writes are authorised through server side helper functions such as has_role, can_access_workspace and can_access_project, never by trusting a workspace identifier supplied by the client.

Provider API keys, database connection strings and deployment tokens live in the workspace key vault. They are encrypted at rest, decrypted only inside server side execution, injected into a sandbox as environment variables at run time, and never serialised into a browser payload.

• The interface shows the provider, a label, creation and last used timestamps, and the last four characters only.
• Keys are verified against the provider when added, so a broken key fails early rather than mid run.
• Removing a key purges it from live systems immediately and stops future use.
• Platform level secrets are held in the deployment environment, rotated on a schedule and after any personnel change with access.
• Error traces are scrubbed of obvious secret patterns before they leave the platform.

• Each project runs in its own container with its own file system, process namespace and network egress path.
• Containers have CPU, memory, disk and wall clock ceilings, and a single command cannot run indefinitely.
• There is a cap on concurrent sandboxes per workspace, so one tenant cannot exhaust capacity.
• An idle reaper stops machines with no activity, which also limits the exposure window of injected secrets.
• Container file systems are discarded when the machine stops, so nothing persists outside your project file tree.
• Sandbox previews are served from a separate origin so that preview code cannot read the platform session.

• All state changing endpoints validate input with schema validation before touching the database.
• Server functions and server routes read secrets from the server environment only, never from client bundles.
• Public HTTP endpoints verify the caller, whether by signature, shared secret or session, before doing work.
• Output is rendered through React escaping by default, and raw HTML injection is flagged by our guardrails.
• Changes go through version control with review, plus automated typecheck and build gates before release.
• We use staged rollout and keep the ability to roll back a release quickly.

The platform and generated projects both install packages from public registries. We run dependency scanning on the platform, patch critical advisories promptly, and pin versions in lock files. For your projects, agents prefer well maintained packages, and the dependency scan in the app reports known advisories in what a project installs. Reviewing and updating your project dependencies over time is your responsibility.

Before changes are applied, agent output passes automated checks that look for common hazards: raw HTML injection, hardcoded colour utilities that break theming, hardcoded secrets, unsafe database access patterns, missing row level security on new tables, and imports that would leak server only modules into the browser bundle. Failures are surfaced in the run log and can trigger the automatic fix loop.

Guardrails reduce common mistakes. They do not replace your own review, your own tests, or a security assessment of what you ship.

• Privileged and security relevant actions are written to an append only platform audit log with actor, action, target and timestamp.
• Credit ledger entries are immutable records of metered activity, so billing can be reconstructed.
• Application errors and performance data are monitored, with alerting on anomalous rates.
• Access to production data by staff is logged and attributed to an individual.
• Security logs are retained for 12 months on a rolling window.

Rate limits are enforced atomically in the database, so parallel requests cannot bypass them. Limits apply to chat and agent runs, sandbox creation, build and deploy operations, authentication attempts and public endpoints. Quotas cap concurrency per workspace. Repeated limit breaches feed the abuse signals described in the Acceptable Use Policy.

Where we act as your processor, we notify you rather than your end users, so that you can meet your own notification duties.

• Access to production is limited to the smallest number of people who need it, granted by role and reviewed periodically.
• Staff use unique accounts with strong authentication and managed devices.
• Confidentiality undertakings apply during and after engagement, and access is revoked promptly on departure.
• We do not read private project chat history except where necessary to investigate severe abuse, to respond to a support request you raise, or where law requires it.

Report security issues to security@novabuild.dev. The Responsible Disclosure page sets out our safe harbour, scope, expected response times and the testing rules. Please do not test against other tenants, and please do not publish before we have had a chance to fix the issue.

We describe our own practices honestly and we do not claim certifications we do not hold. NovaBuild is not currently certified under SOC 2 or ISO 27001, is not a HIPAA business associate, and is not PCI certified for storing cardholder data. Our payment processor handles card data under its own PCI scope. For data protection commitments, see the Data Processing Addendum. If your procurement process needs a questionnaire completed, email security@novabuild.dev.

• Confirm row level security exists on every table your project created, with policies that match your intent.
• Check that no secret appears in the project file tree or in client side code.
• Verify authentication and authorisation on every route and endpoint that touches user data.
• Review the dependency scan and update anything with a known critical advisory.
• Test the destructive paths: deletion, role changes, payment flows and password reset.
• Set project visibility deliberately, and remember that free plan projects are public by default.
• Publish your own privacy and cookie notices for the application you deploy.

Security questions and questionnaires: security@novabuild.dev. Abuse: abuse@novabuild.dev. Privacy: privacy@novabuild.dev.