No SOC 2, ISO 27001 or other certification is held.
Security
Isolation and verified work, by construction.
This page describes how the platform is actually engineered: the database boundary, the session boundary, the build sandbox, the payment path and the export path. It lists no certification or audit, because none exists.
Tenant isolation in the database
Isolation is enforced where the data lives, not only in application code.
- Every tenant-sensitive table carries an organization owner (organization_id or an equivalent tenancy boundary) with composite ownership to projects.
- Row-level security is forced for tenant tables, and the runtime roles are narrow: the identity role cannot read project or wallet data, and the request boundary rejects PostgreSQL administrative, superuser and file/server-level roles.
- Tenant context is set per transaction. An identifier that arrives from a browser is a request, never an authorization.
- Protected writes go through functions that verify the session and current authority independently, and direct writes from application roles are revoked for those tables.
Sessions and current authority
Authentication is checked on the way in, and authority is re-checked at the moment it is used.
- Session cookies are HttpOnly and SameSite=Lax, __Host-prefixed in production, and every request resolves the session to a user and a tenant before anything else happens.
- Browser mutations must come from the configured origin, and request bodies are bounded (application/json, 16 KiB, five-second deadline).
- Sensitive changes — MFA changes, credential issuance, purchases, plan changes — require fresh authentication rather than a long-lived session.
- MFA is TOTP with one-time recovery codes. Tokens and codes are consumed atomically, so two simultaneous uses cannot both succeed.
Credentials and operation approvals
A credential is a scoped, revocable grant — not a standing key to the platform.
- API and MCP credentials are hashed at rest, bound to one organization, brand and project, carry explicit scopes and a bounded lifetime, and are shown exactly once.
- Removing someone from a team permanently revokes their credentials, and a password reset invalidates credentials issued earlier.
- Sensitive and billable actions require a short-lived approval bound to the user, organization, project, exact action, target and canonical input digest.
- Approval consumption, job admission, credit reservation, audit and the outbox record commit in a single transaction; if the trusted callback fails, the whole admission rolls back. Role or membership changes permanently revoke pending approvals.
Builds run isolated
Customer and AI-generated code is treated as untrusted, because it is untrusted.
- Builds run in a temporary container on a minimal base image with the network disabled, capped memory and CPU, a process limit, a read-only root filesystem, a bounded noexec temporary mount, no Docker socket and no production credentials, under a wall-clock timeout.
- An artifact must pass digest and size verification and be written through an atomic store — write, flush, read back, atomic rename, read back again — before a build receipt is recorded. A crash can therefore never leave a ready state without durable bytes.
- Build and artifact receipts are append-only; an update or delete raises an immutability error.
- A worker holds a fenced lease, renews it while it works and stops if it loses ownership. Source and archive limits (1000 entries, 256 KB per file, 16 MB total) are enforced on the way in and on the way out.
- File content is delivered to the browser as escaped text: markup inside a saved file stays inert and is never executed.
Payments verified from signed events
Money changes only when the provider says so — and the platform can prove it.
- Payment webhooks are verified with real signature checking over the bounded raw request body, with replay and time checks and an exact account and test/live scope. The endpoint acknowledges only durable receipt.
- Credits become a balance only after the payment is verified against the provider — invoice, payment intent and charge — and a grant is applied exactly once.
- Prices are never taken from a browser: amounts and credit units come from a server-side catalog, and a price that does not match the expected product, amount, currency and cycle is rejected.
EU hosting and recorded hardening
What is true today, including what is not finished.
- Servers are EU-based and managed by the platform. Customers never receive a provider control panel; everything runs through Hostingsurge.
- On the production server, pending OS updates were installed (including security updates), the firewall was enabled while preserving SSH, HTTP, HTTPS and HTTP/3, and the reverse proxy administration binding was restricted to localhost, then verified after restart.
- Traffic terminates through TLS and a hardened proxy; administrative interfaces are not exposed to the internet.
- This is a development preview: no customer workloads are running, and external backup/restore and notification delivery are not yet configured or verified. Those are reported as unfinished rather than implied.
What this page does not claim
Stated plainly, because a security page that overstates itself is worse than none.
No independent security audit has been performed.
No third-party penetration-test report exists.
No uptime SLA and no bug-bounty programme is offered.
No security disclosure address is published yet. Until one is, a finding has no confirmed channel — and this page will name one when it exists.
Read the boundary, then decide.
The developers page documents the real endpoints and their authentication. The docs page states what is implemented module by module.
Everything above describes the current build. No certification, audit or SLA is claimed anywhere on this site.