Nocta.aiSTUDIO
PRODUCT
Try-OnShots & AnglesUpscale & EnhanceExplorePricingResources
LEGAL

Security overview

Intended security practices for Nocta.ai Studio.

Last updated 2 September 2026
Provisional wording — final legal text requires review before launch. The contact, support, takedown, removal and appeal forms now send to an operations mailbox, but only where this deployment configures outgoing mail: each form states, after you submit, whether your request actually left the server, and issues a reference only when it did. Deleting an image from your Library Trash is the one erasure the product carries out itself; it never reaches the images generated from that asset, and the Privacy centre still simulates data export and account deletion without performing either.
ON THIS PAGE

Private by default

Your uploads and creations are private to your account by default, and are not used to showcase the product without permission.

Access control and signed access

Assets are reachable only through authenticated, signed requests scoped to your account. Stored objects are private and are never served from a public bucket.

Encryption

Data is intended to be encrypted in transit; encryption at rest is an intended production requirement.

Provider access

Generation providers receive only the data needed to fulfil your request, under contractual restrictions. Inputs sent to a provider are bounded and explicitly controlled server-side.

Account security

Passwords are stored hashed. Additional protections such as rate-limiting and suspicious-activity alerts are intended production requirements.

Incidents, backups and deletion

Incident-handling and backup procedures will be documented operationally.

One erasure procedure exists and is exercised: an asset removed from the Library goes to Trash, and its stored object is deleted — by you at any moment from the Trash, or automatically once it has been there 30 days. The automatic pass is carried by the generation worker, which is where bounded background work runs in this deployment; there is no internal scheduler. The database row survives, stripped of everything that described the image, because upload and generation records reference it and the schema refuses to drop it — it still carries the account it belongs to, the credits it cost and the transaction that paid for them, the folder, projects and collections it was filed in, and its dates.

Everything beyond that is still a request handled by a person: the Privacy centre request is simulated, no code path erases an account, and no erasure reaches the images generated from a deleted asset.

Responsible disclosure

A dedicated security contact for vulnerability reports will be published before launch. Until then, use Contact support and mark the case as a rights and safety matter.

Verification

The controls described here are intended production requirements and must be verified before launch. No certification is claimed and no audit has been performed.

Read the FAQ↑ Back to top