What we do, and what we do not do yet.
We build the layer that decides who may see what, so the bar for our own claims is higher than usual. Everything below is true of the running platform. The second section is the one worth your time.
What the platform does today
Tenant isolation in the platform, not in your code
Every generated application inherits multi-tenant scoping from the platform. Applications do not carry a tenant_id column that developers have to remember to filter on — the boundary is enforced below the application, so a forgotten WHERE clause is not a data breach.
Role-based access at object and field level
Access policies govern which records a caller may read and which fields come back. Custom roles carry a permission ceiling, so a role cannot grant itself more than the role that created it.
Secrets sealed at rest
Integration credentials and platform secrets are encrypted at rest with AES-256-GCM under a key held outside the image and outside version control. Encrypted values are masked when read back through the API.
Transactional integrity with compensation
Multi-step operations run as sagas: a failure part-way through walks back the steps that already succeeded, rather than leaving a half-finished write. Illegal state transitions are refused rather than absorbed.
Audit trail
Reads and writes across the platform surfaces leave an audit record, scoped to the domain that owns them.
Isolated deployment per application
A deployed application runs as its own service with its own credentials. One application reaching another is a deployment boundary, not a code-review question.
What we do not do yet
Named plainly, because a vendor who lists only strengths has told you nothing. If one of these is disqualifying for you, we would rather you knew now than after an evaluation.
No third-party penetration test
We have not commissioned one. When we do, we will publish the summary here — including anything it finds.
No SOC 2, ISO 27001 or HIPAA attestation
We are not certified against any of these and do not claim readiness. If a compliance regime is a hard requirement for you, tell us before you invest time in an evaluation.
No published uptime history
We do not yet run a public status page with historical incident data. We are not going to publish a page that shows a green square nobody measured.
Generated applications are not hardened to production browser standards
The applications the platform generates are built for demonstration and iteration. They do not currently ship a content security policy, and their front-end bundles are development builds. Treat a generated application as production-ready only after you have reviewed it.
Field-level read enforcement is being rolled out in stages
The access-decision component that governs query inputs — filters, sorts, groupings — is deployed and observing before it refuses, so that turning it on does not break running applications. Enforcement is being enabled deliberately rather than all at once.
Reporting a vulnerability
We would rather hear about a gap from you than from a customer.
- ✓ Write to [email protected]. We acknowledge within two business days.
- ✓ We agree a disclosure date with you — ninety days by default, sooner if you prefer.
- ✓ We publish what you found either way, including when it reflects badly on us.
- ✓ We will not pursue anyone acting in good faith within the scope below.
In scope: supero.dev, app.supero.dev, api.supero.dev, docs.supero.dev, and any project you created yourself.
Out of scope: other customers’ projects and data, denial of service, volumetric or automated scanning, social engineering, and physical access. If you find yourself somewhere that is not yours, stop — that is the finding, and we will thank you for it.
Machine-readable contact: /.well-known/security.txt
Questions before an evaluation?
Ask us the awkward ones. We would rather answer them early.