Security

This page describes how GPTpost protects the data you and your customers put into it. It is written to be checked, not admired: every control listed here is implemented in the product, and the limitations section says plainly what is not yet done. We would rather lose a procurement review than pass one on a claim we cannot support.

Report a suspected vulnerability to security@oraglegpt.org.

1. Our security principles

1. Tenant isolation is the primary control. Every record carries a tenant identity and every read and write is filtered by it. A bug that leaks across tenants is treated as the most severe class of defect.
2. Credentials are sealed, never echoed. Social tokens, AI keys, and integration secrets are encrypted before storage, are never returned by the API, and are omitted from responses rather than returned as masked placeholders that leak length or shape.
3. Least scope, always. We request the narrowest set of social platform permissions that supports the features a customer has switched on, and we drop scopes when a feature is switched off.
4. Fail closed. When an authorisation decision, a policy check, or a signature verification cannot be completed, the request is refused rather than allowed.
5. Say what is not done. Section 8 lists known limitations. We do not claim certifications we do not hold.

2. Data protection

2.1 Encryption in transit

• All traffic to oraglegpt.org is served over HTTPS with TLS, using certificates obtained and renewed automatically at the reverse proxy.
• HTTP Strict Transport Security is sent on HTTPS deployments with a one-year max-age, includeSubDomains, and preload.
• Calls to social platform APIs and AI providers are made over TLS.

2.2 Encryption at rest

• Tenant state is protected with AES-GCM authenticated encryption. Data is checksummed and schema-validated when it is loaded, so silent corruption is detected rather than served.
• Writes are transactional: PostgreSQL commits them atomically, and write-ahead logging means an interrupted write cannot destroy committed state.
• Social OAuth access and refresh tokens, AI provider keys, and integration credentials are held in sealed envelopes under a master key that is supplied to the process at runtime and is not stored alongside the data it protects.
• Backups are written as encrypted, context-bound envelopes with tamper detection. Restores are verified, and the master key can be rotated offline.

2.3 Secret hygiene

• Secrets, tokens, and credential fields are redacted before they reach logs, error messages, or diagnostic endpoints.
• An automated secret scan runs in the release verification gate, so a credential committed by mistake fails the build rather than shipping.

3. Identity, authentication, and access

• Passwords are stored only as a salted hash. We never hold a plaintext password and cannot tell you what yours is.
• Multi-factor authentication is supported with TOTP authenticator apps, single-use recovery codes, and WebAuthn / passkey credentials.
• Step-up authentication is required before sensitive operations, including operator diagnostics.
• Sessions use an opaque token in an HttpOnly, SameSite=Lax cookie, marked Secure on HTTPS. Sessions carry both an absolute and an idle expiry and can be revoked server-side; signing out revokes immediately.
• Enterprise identity is supported through OIDC and SAML single sign-on, with SCIM user and group provisioning, so joiners and leavers are managed in your directory rather than by hand.
• Authorisation combines role-based and attribute-based access control with publishing approval workflows, so the ability to draft is separable from the ability to publish.

4. Application and network security

• Security headers are set on every response: X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, a restrictive Permissions-Policy, Cross-Origin-Opener-Policy: same-origin, and Cross-Origin-Resource-Policy: same-origin.
• Content Security Policy is enforced with default-src 'self', script-src 'self', object-src 'none', frame-ancestors 'none', and base-uri 'self'. No third-party script is loaded by the application.
• Cross-site request forgery is mitigated by requiring a same-origin Origin header on cookie-authenticated state-changing requests.
• Rate limiting is applied per client, and request bodies are capped, so a single caller cannot exhaust the service.
• Trusted proxy handling validates the forwarding chain right-to-left, so a client cannot spoof its source IP address by injecting headers.
• Server-side request forgery protections apply to features that fetch a customer-supplied URL.

5. Integrity and auditability

• Audit logging is tenant-scoped and append-oriented: who did what, to which record, when, and from which session.
• Publication attempts are recorded immutably, including the request, the provider response or error, the provider post identifier, and timestamps. This is the evidence trail for what was actually sent to a social platform.
• Outbound webhooks are signed with HMAC-SHA256 over a timestamp and the body, with replay protection, secret rotation, retry with backoff, a dead-letter queue, and automatic disabling after repeated failures.
• Correlation identifiers are attached to every request so an incident can be reconstructed across subsystems.

6. Operational security

• Backups are encrypted, taken on a schedule, held off-site, and restore-tested. The backup and tenant-export files the Service writes are deleted 90 days after they are written by a scheduled sweep, so a deleted record is gone from them within 90 days. Backups taken outside the Service, such as a hosting provider's volume snapshot, are on that system's own rotation; see Privacy Policy section 9.
• Restoring a backup can reinstate erased records. A restore or a reference-state import replaces the store from a copy taken before an erasure, and nothing replays the deletion receipts afterwards. An operator who restores must re-run the affected deletion requests. This is carried as a named, accepted risk in our internal risk register rather than left implicit.
• Patching. Dependencies are reviewed and updated as part of the release cycle, and a software bill of materials is produced for each release.
• Change management. Changes go through review and an automated verification gate that includes tests and the secret scan before release.
• Access to production is limited to personnel who need it, over authenticated channels, with actions recorded.
• Subprocessors are listed publicly at Subprocessors, with 30 days' notice before a new one begins processing.

7. Incident response

If we suffer a personal data breach:

1. We contain and investigate immediately.
2. We notify affected customers without undue delay and within 72 hours of becoming aware, with the facts known at that time, so that a customer acting as controller can meet its own GDPR Article 33 deadline.
3. We provide the categories and approximate volume of data involved, the likely consequences, the measures taken, and a contact point.
4. We update customers as the investigation develops rather than waiting for a final report.
5. Where a social platform's data is involved, we notify that platform in line with its developer terms.

Breach obligations are contractual, not merely a promise: they are set out in section 9 of Data Processing Addendum.

8. Known limitations

We publish these because a security page that lists only strengths is not a security page.

1. No third-party audit certification. We do not hold SOC 2 Type II, ISO/IEC 27001, PCI-DSS, or HIPAA attestation, and we do not claim to. If you need an audited provider today, we are not that provider yet.
2. No contractual uptime commitment unless one is signed in an order form. See Terms of Service section 10.
3. No full regional pinning guarantee. Primary hosting is in Germany, and so is the object storage the Company runs itself, but AI processing at a provider a customer has configured may be in the United States under Standard Contractual Clauses. We do not offer a single-region guarantee across every subsystem. See Privacy Policy section 8.
4. No paid bug bounty. Good-faith research is protected by the safe harbour in Acceptable Use Policy section 8, but no reward is offered.
5. A single primary database, with no high-availability cluster and no automatic failover, and point-in-time recovery that has not yet been rehearsed end to end. This is an availability and durability limit rather than a confidentiality one.

9. Reporting a vulnerability

Email security@oraglegpt.org. Please include:

• what you found, and the impact you believe it has;
• the exact steps to reproduce it;
• any request and response samples, with secrets removed;
• how you would like to be credited, if you would like to be.

Rules of engagement, which also grant you our safe harbour:

• Test only against your own tenant.
• Do not access, modify, or exfiltrate another tenant's data. If you encounter someone else's data, stop and tell us.
• Do not run denial-of-service, physical, or social-engineering attacks.
• Give us reasonable time to remediate before public disclosure.

What you can expect from us: acknowledgement within 2 business days, a remediation timeline within 10 business days, and no legal action against research conducted within these rules. The full safe harbour text is in Acceptable Use Policy section 8.

10. Security questionnaires and procurement

Enterprise buyers can request our Data Processing Addendum, our subprocessor list, and answers to a security questionnaire at dpa@oraglegpt.org. We answer questionnaires factually, including the questions where the answer is "not implemented".

11. Contact

GPT LLM ORAGLE Ltd. Liability Co.
30 N Gould St, Ste N
Sheridan, WY 82801
United States