Security and Data Handling

This website

• All traffic is served over HTTPS with HSTS, and security headers restrict content sources, framing, and referrer leakage.
• The site is static, with no user accounts and no server-side session state.
• The only database path a browser can reach is a create-only inquiry write with an exact validated field set and size caps. Everything else is denied by default.
• That write path additionally requires a valid App Check attestation (reCAPTCHA Enterprise), enforced at the API level, so junk is rejected before it consumes resources.
• The inquiry form accepts no file uploads, and visitors are told not to submit confidential data through it.
• Runtime secrets live in a cloud secret manager, never in the repository or the client bundle.

Engagement data handling

• Source access starts read-only and least-privilege wherever possible.
• Sources are processed only under a documented rights basis: customer-provided, public and permitted for the scoped use, or licensed.
• Sensitive data can remain inside the customer's own infrastructure through customer-cloud or hybrid deployment.
• Customer data is not sent to third-party model providers without written approval and an agreed retention boundary.
• Customer data is not used to train shared models or improve unrelated products without explicit contractual permission.
• Retention and deletion are planned per engagement, including propagation through raw, derived, index, and delivery layers.

Reporting a vulnerability

Report security issues to hello@datificial.com. A security.txt file is served at /.well-known/security.txt. Reports get a human reply, and good-faith research within the law is welcome.