This page describes the controls currently in place at MITPO. It is written to be accurate rather than marketing-polished. Where a control exists but has not been externally audited, it is described as implemented — not certified. Where a control is aspirational, it is flagged as such or omitted entirely.

If you need a specific control documented for procurement, email support@mitpo.com and we will respond with the current state.

MITPO authenticates users with a choice of email + password or OAuth (Google, GitHub) through a dedicated authentication service. Passwords are hashed before storage using industry-standard algorithms — plaintext passwords are never persisted. OAuth connections use the provider’s standard flow and only request the scopes required to operate the product.

• Email + password with hashed password storage.
• OAuth single sign-on with Google and GitHub.
• Session cookies are HTTP-only and marked secure in production.
• Session rotation on privilege change (password reset, new OAuth linkage).

MITPO is multi-tenant. Tenant data is isolated at the database layer using row-level security, which means even if an application-level bug attempted to query across tenants, the database would refuse to return rows belonging to another account. The enforcement runs on every query, not only on reads performed through the application’s ORM.

• Postgres row-level security FORCE on user, session, account, brand, generation, and campaign tables.
• Production database roles are scoped to the minimum privilege needed (for example, billing crons use a billing-only role that cannot read brand or campaign data).
• Signed URLs for private asset access expire on short windows and re-sign per request with an ownership check.

Traffic between your browser and MITPO is encrypted over TLS. Data at rest in the primary database and in the object store is encrypted using provider-managed keys. Backups are encrypted with the same key management and are retained in line with the provider’s standard practice.

• TLS in transit; HTTP Strict Transport Security enabled.
• Provider-managed encryption at rest for the primary database.
• Provider-managed encryption at rest for generated assets (images, video, audio).

MITPO emits structured logs for application events, authentication attempts, and scheduled job execution. Logs are retained long enough to be useful for diagnosing incidents but not so long that they become a standing privacy risk. Alerting covers production availability and error-rate spikes.

If MITPO experiences a security incident that affects user data, we will notify affected users within the timeline required by applicable law — generally within 72 hours of becoming aware of the incident for material cases. Notification will include what is known, what is not yet known, and what the user is advised to do.

Updates during an ongoing incident are published to this page. For widespread incidents, a banner is added to the landing page.

We welcome good-faith security research. If you believe you have found a vulnerability in MITPO, please email security@mitpo.com with a description and reproduction steps. We respond within two business days and work in good faith to remediate confirmed issues.

Please avoid testing that would degrade service for other users (denial-of-service, large-scale scraping, accessing real user data beyond what is strictly necessary to demonstrate the issue).

• Report to: security@mitpo.com
• RFC 9116 contact also at /.well-known/security.txt
• We do not currently run a paid bug-bounty program, but we acknowledge researchers on request.

To be accurate rather than aspirational: MITPO does not currently hold a SOC 2 attestation, ISO 27001 certification, HIPAA or PCI scope. If a specific compliance posture is required for your engagement, say so in a purchase conversation and we will tell you honestly whether the product is ready for it.