Security

1. Overview

This page describes how we protect the data that moves through Chiselo's 3D-conversion pipeline — your uploaded reference material, the assets we generate, and the credentials our system uses to do it. Every claim below reflects how our production system is actually built, not general boilerplate.

2. Secret management

Every third-party API credential our pipeline depends on is stored at rest in Supabase Vault, encrypted using the pgsodium Postgres extension. Secret values never appear in our codebase, logs, or internal tooling — only secret names are ever visible for reference, and values are write-once. A rotated credential is validated against the provider before it takes effect, so a mistyped replacement key can't lock out the pipeline. Every read, write, and rotation of a secret is recorded in an audit log that cannot be updated or deleted, even by us.

3. Database access control

Row-Level Security is enabled on every table in our production database. Where no explicit access policy is defined, Postgres denies access by default — so only our backend service can read or write data; there is no accidentally open table. Audit and financial tables go further: they reject updates and deletes by database policy, not just application convention, closing off even an internal accident.

4. Internal access controls

We don't layer a separate employee access-management program — onboarding and offboarding reviews, periodic access audits — on top of the database. The same Row-Level Security and service-role isolation described above governs internal access too: there's no path around it for our own team either. Third-party provider credentials are held in Vault; engineers reference secrets by name and never see raw values (see Secret management above).

5. Webhook integrity

Inbound webhook calls from our 3D-generation providers are verified against an HMAC signature tied to a per-account secret. A signature mismatch is a hard rejection — there is no fallback path that processes an unverified request.

6. Encryption at rest and in transit

Our database and file storage run on Supabase's managed infrastructure. Per Supabase's published security documentation, all customer data is encrypted at rest with AES-256 and in transit via TLS. Application secrets receive an additional, independent layer of encryption specific to Chiselo — see Secret management above.

7. Operational integrity

Every call to a third-party generation provider is preceded by a database-level credit reservation, reconciled after the call completes. Combined with per-account concurrency limits and idempotent job handling, this keeps one client's usage from interfering with — or being billed against — another's.

8. Security monitoring and logging

Every read, write, and rotation of a stored credential is recorded in an audit log that can't be altered or deleted, even internally (see Secret management above). Production errors and failures are captured through the structured error classification described in Error handling below, so anomalies surface to our team rather than going unnoticed. We do not currently run continuous third-party penetration testing or a dedicated SIEM; our monitoring today is built directly into the pipeline's own error-handling and audit-log discipline described throughout this page.

9. Vulnerability disclosure

If you believe you've found a security vulnerability in Chiselo, email support@chiselo.design with details and, if possible, steps to reproduce. We ask that you give us a reasonable opportunity to investigate and remediate before any public disclosure, and that you avoid actions that could degrade the service or access data beyond what's needed to demonstrate the issue. We don't currently run a paid bug bounty program, but we will acknowledge good-faith reports and keep you informed as we work through a fix.

10. Data retention

Uploaded source files (reference images, spec sheets) and intermediate processing data are deleted 60 days after final delivery of your converted assets. Delivered 3D models remain accessible to you via your project's delivery link, which does not expire on a fixed schedule — it stays active until you ask us to revoke it, or your account is closed and its data removed.

11. What data we process

Chiselo is a B2B service. We process product and SKU data provided by our business clients — reference images, dimensions, and catalog metadata. We do not knowingly process personal data belonging to our clients' individual end-consumers.

12. Incident response

We do not currently have a separate, formal incident-response or breach-notification process beyond what's described on this page. What exists today is the error-classification discipline described below: every production failure — including a potential security issue — is required to classify into one of a fixed set of outcomes rather than fail silently, which is how issues surface to our team internally. Confirmed incidents affecting an enterprise client's data are communicated per the breach-notification commitment in the next section, regardless of whether a broader formal process exists yet.

13. Error handling and breach notification

Internally, every error in our production pipeline is required to classify into one of a fixed set of outcomes — automatic retry, an alert requiring admin attention, a billing-related pause, or an escalation to on-call — rather than failing silently.

If we confirm a security breach affecting an enterprise client's data, we will notify that client within 72 hours of confirmation.

14. Certifications

We do not currently hold SOC 2, ISO 27001, or other third-party compliance certifications. We're happy to walk through our actual security posture — everything described on this page — as part of your vendor diligence process.

15. Contact

Questions about this page or our security practices — Aikagra Technologies — support@chiselo.design