Our approach
Security is an ongoing engineering responsibility, not a badge or one-time checklist. We aim to limit the information the service needs, use reputable infrastructure, keep dependencies current, restrict operational access, and respond proportionately when a risk is reported. Controls evolve with the product’s features and sensitivity.
We do not claim certifications, independent audits, encryption properties, uptime guarantees, or compliance programs that have not been verified. As accounts, billing, uploads, or integrations are introduced, the security model and public documentation will need to expand with them.
Infrastructure and application safeguards
The site is delivered through managed cloud infrastructure with transport encryption for supported HTTPS connections. Hosting platforms may provide network protection, isolation, logging, and deployment controls. Application design favors a small exposed surface and avoids collecting credentials when a feature does not need them.
We review changes through version control and perform build validation before deployment. Dependency and platform risks are addressed according to severity and practical exposure. No safeguard guarantees that a service cannot be compromised, and users should not treat a public web tool as a secure vault.
Data minimization
The safest sensitive data is data never submitted. Do not put passwords, secret keys, full payment-card numbers, government identifiers, confidential client lists, unreleased financial information, health records, or private legal documents into a social-content prompt. Use placeholders or remove identifying details when asking for help with a draft.
Operational logs may contain technical identifiers needed for reliability and abuse prevention. Access should be limited to legitimate operational needs, and retention should be proportionate to purpose. The Privacy Policy provides broader information about data handling.
Responsible disclosure
Send suspected vulnerabilities to [email protected] with the subject “Security report.” Include affected URLs, reproducible steps, potential impact, and a safe proof of concept. Give us a reasonable opportunity to investigate before public disclosure.
Good-faith research must avoid accessing other users’ data, changing or deleting information, degrading availability, social engineering, phishing, spam, physical testing, or automated scanning that creates significant load. Stop testing and contact us if you encounter sensitive information.
How we respond
We triage reports based on exploitability, affected data, user impact, and likelihood. A credible report may move through acknowledgment, reproduction, containment, remediation, validation, and communication. Some low-risk findings may be accepted as known limitations or scheduled with other work.
We do not currently operate a paid bug bounty and cannot promise rewards. When appropriate, we may recognize a reporter who wants attribution, but privacy and safe remediation come first.
What users can do
Use the correct HTTPS domain, keep your browser updated, review output before publication, and be cautious with links or messages claiming to represent Social Post AI. We will not ask for a password or one-time authentication code by email. Report suspicious messages and do not reuse sensitive credentials across services.
If we learn of a security event that creates a material risk to users, we will investigate, take reasonable containment steps, and provide notice when required or useful. The timing and detail of notice may be limited while active remediation is underway.