For consumers in Romania the Romanian version prevails.Versiunea in limba romana
GPTpostLLM Legal

Security

This document describes how GPTpostLLM at https://app.oraglegpt.org is protected, and where it is not. It is published by TRIIVON S.R.L., whose identification data is in Company Identification.

It is written to be checked rather than believed. Every control below corresponds to something implemented in the deployed application. Where a control that a reader might reasonably expect is absent or weaker than a common default, it is listed in section 11 instead of being left out. A security page that lists only strengths tells you nothing, because you cannot tell whether the omissions are absences or silence. So the limitations section is the part of this page we consider load-bearing.

1. What this document covers

It covers the application, its data store and the servers that run them. It does not describe the internal security of the social platforms you publish to. Those are independent services with their own controls, and our connection to them is narrow in a way that is set out in section 8.

Two facts about the product bound everything else on this page, because they remove whole classes of risk that a similar product would carry:

2. Authentication and sessions

Passwords are stored as PBKDF2-HMAC-SHA256 derivations with 210,000 iterations and a 16-byte random salt per password. Verification is constant-time. The plaintext password is never written to storage or to a log.

Sessions are opaque bearer tokens, not JWTs. A session identifier is 32 bytes from a cryptographically secure random source, stored server-side. It carries no readable claims, so nothing about your account can be decoded from it, and revoking it server-side takes effect immediately rather than waiting for a token to expire.

Session propertyValue
Absolute lifetime12 hours from sign-in
Idle timeout2 hours without activity
Platform operator absolute lifetime30 minutes
Platform operator idle timeout15 minutes
Step-up re-authentication window10 minutes
Cookieorbitpost_session, HttpOnly, Secure, SameSite=Lax

Sensitive operations require step-up re-authentication: if you have not proved your identity within the last 10 minutes, you are asked again before the operation proceeds, even though your session is still valid.

Mutating requests are additionally checked against the request origin, so a hostile site cannot make your browser act on your session. Session records themselves are held under the tenant isolation described in section 5.

Login responses are hardened against user enumeration: the timing and the response of a sign-in attempt do not reveal whether an address is registered.

3. Multi-factor authentication

Time-based one-time passwords are implemented to RFC 6238, with a 30-second step, a plus or minus one step verification window, and constant-time comparison of the submitted code.

MFA is optional for ordinary users. You can turn it on for your own account and we recommend it, but the application does not require it and we will not claim on this page that it does. It is mandatory only for platform operator accounts, which are the accounts held by the company's own staff.

One honest detail that follows from that: MFA secrets are stored as ordinary database fields, not encrypted by the application. They are redacted when read back through the API. They fall under the tenant isolation and the database access controls, but they are not in the encrypted field list in section 4, and we are not going to imply that they are.

This deployment offers no passwordless or hardware-key sign-in. There is code in the repository related to it, but it grants no session and cannot authenticate anyone, so it is not a feature and you should not plan around it.

4. What is encrypted, and what is not

This is the section where products most often overstate. The precise position is below.

Application-level encryption is AES-256-GCM, with the context string bound in as additional authenticated data, and it is applied to specific credential fields only:

That list describes which fields are encrypted when they hold a value. It is not a claim that every feature which uses one of those fields is enabled on this deployment.

What is not encrypted by the application: your business content. Posts, drafts, campaigns, schedules, contacts, media metadata and analytics observations are stored without application-level encryption. They are protected by the tenant isolation in section 5, by authentication, and by the access controls on the server, not by a cipher in the application.

Two further points that similar pages usually blur:

So the sentence "all data is encrypted at rest" is false here, and we will not write it. What is true is that the credentials which would let someone act as you on a social platform are encrypted, and your content is not.

Data in transit is protected by TLS. Certificates are issued by Let's Encrypt over ACME and terminated by the Caddy reverse proxy.

5. Tenant isolation

Workspaces are isolated by PostgreSQL row-level security, which is both ENABLED and FORCED on the tables that matter: records, idempotency keys, the job queue, the transactional outbox, the audit log and sessions. FORCED matters because it means the policy also applies to the table owner rather than being bypassed by it.

The tenant identity used by the policy comes from the stored server-side session, never from the request. A client cannot select a workspace by sending a header, a parameter or a token claim.

This is verified by a test that opens a raw database connection outside the application's tenant context and asserts that it reads zero rows. Production runs this PostgreSQL profile, so the isolation described here is the isolation that is deployed and not a configuration that exists only in development.

6. Audit log

The audit log is the strongest control in the product and it is worth understanding precisely.

Reads are not audited. There is no access log recording who viewed a record. If your requirement is "show me everyone who looked at this contact", this product cannot answer it. It can answer "show me everything that was changed, by whom, when, and prove the record has not been edited since."

7. Rate limiting and abuse controls

Rate limiting is an in-process fixed window of 900 requests per minute per IP address, applied per replica. If more than one replica is running, the effective ceiling is that number multiplied by the number of replicas, because the counters are not shared.

There is no login-specific rate limit and no account lockout. Sign-in attempts are subject only to the general limit above. This is a real weakness and it is listed again in section 11. The mitigations that do exist are the password hashing cost in section 2, the enumeration-resistant login behaviour, and optional MFA. If your account matters, turn MFA on.

8. Outbound request safety

The application makes outbound requests to social platform APIs and to endpoints that customers configure. Those requests are constrained, which is what stops a customer-supplied URL from being used to reach the inside of our network:

Be aware of the shape of this control: it is a deny-list, not an allowlist. It blocks the known-dangerous destinations rather than permitting only an approved set.

On the inbound side, the only provider callbacks the application accepts are Meta's data deletion and deauthorize callbacks, for facebook, instagram and threads only. They are verified by HMAC-SHA256 signature with a five-minute freshness window. No other inbound receiver exists. The customer-facing "webhooks" feature is outbound only.

9. Data you can take out, and data we remove

Export is available in the interface at Settings, Data Privacy. It runs synchronously and returns a signed ZIP archive named with an .optenant extension containing manifest.json and records.json, covering 48 resource families, with a SHA-256 digest of the payload and an HMAC signature over the manifest so you can tell whether the file has been altered. Stored credentials are never included in an export.

Import and restore are not available. There is code but no route and no caller, so an export is a readable archive of your data, not a backup you can push back in.

Account erasure is requested through the API at POST /api/v1/privacy/deletion-requests and runs after a 30-day grace period which is a compile-time constant, is enforced before erasure runs, and is cancellable during the window. The Data Privacy screen does not have an account-deletion button. A deletion instruction received from Meta through the callback in section 8 has no grace period and is queued immediately.

Workspace closure uses a 30-day window during which the workspace stays readable and exportable, moving through the states active, pending deletion and closed, and it can be reversed by reopening. The final erasure at the end of that window is carried out by us as an operational commitment, not by an automatic job: the automated purge runs in report-only mode on this deployment. The window and the deletion date are real and are stamped on the record. The execution is a promise by the company, and we would rather you hold us to a promise you can see than trust an automation we have not enabled. The full mechanics are in Data Deletion Policy.

10. Infrastructure, availability and backups

The application, the database, object storage and media processing all run on a single server in Lauterbourg, France. This legal site and the company mailbox run on a second server in Germany. Both are rented from Contabo GmbH, which is the only infrastructure vendor. Both are in the EU. The full list is in Subprocessors.

The datastore is PostgreSQL 18 with data checksums enabled, fronted by PgBouncer in transaction pooling mode. There is no Redis and no message broker: queuing is a transactional outbox and a job table in the same database, which means a job cannot be accepted unless the change that created it committed. Object storage is S3-protocol but self-hosted on our own server, not a cloud storage vendor. Media processing is ffmpeg running as a local subprocess; nothing is sent to a transcoding service.

Availability. This is a single-server deployment with no multi-region failover and no high-availability cluster. We publish no uptime figure on this page. Any availability commitment that exists is the one in Terms of Service, and current incidents are at Service Status.

Backups. We are not going to print a backup schedule, a retention period or a recovery time objective here, because a number on a page is worth nothing to you unless it is the number actually in force. If your procurement process needs a statement on backup frequency, retention and restore testing, ask at contact@oraglegpt.org and you will get the position as it actually stands on the date you ask. What you can do without asking anyone is take your own copy, using the export in section 9.

11. Known limitations

Stated plainly, as of the date at the top of this page.

  1. No login-specific rate limit and no account lockout. Sign-in is covered only by the general per-IP limit in section 7.
  2. Rate limiting is per replica, not shared, so the effective ceiling scales with the number of running replicas.
  3. Bulk customer content is not encrypted by the application. Only the credential fields listed in section 4 are.
  4. There is no full-disk or database-level encryption configured on this deployment.
  5. Encryption uses a single static key. There is no per-tenant key and this is not envelope encryption.
  6. Key rotation does not cover the database on this profile. The rotation tooling exists but does not re-encrypt stored fields here, so we do not promise key rotation and you should not assume it.
  7. MFA is optional for ordinary users, mandatory only for platform operator accounts.
  8. MFA secrets are stored unencrypted in the database, redacted on read.
  9. Reads are not audited. The audit log covers changes only.
  10. Outbound request filtering is a deny-list, not an allowlist.
  11. No independent penetration test and no security certification. There is no ISO 27001, no SOC 2 report and no equivalent third-party attestation for this service. Nobody outside the company has audited it. If a certification is a hard requirement for you, we do not meet it today and we would rather you learn that here than in month three.
  12. Single-server deployment with no failover, as described in section 10.
  13. No import or restore path, as described in section 9.

12. Reporting a vulnerability

Send it to contact@oraglegpt.org. Put "security" in the subject line. Include what you found, where, and the steps to reproduce it. If you have a proof of concept, attach it. Write in Romanian or English.

Target acknowledgement: within 3 working days. That is a target we hold ourselves to, not a contractual service level. We will tell you what we intend to do about the report, and we will tell you when it is fixed. We do not currently run a paid bug bounty, and we will not pretend otherwise.

Safe harbour. If you research in good faith under the conditions below, we will not pursue legal action against you, we will not report you to the authorities for the research itself, and we will not ask your employer to discipline you. The conditions are:

Please do not report the items already listed in section 11. We know. They are there so that you can spend your time on something we have not already written down.

Material changes to this page change the date at the top. Because the Service sends no email, there is no automatic notification: if you want to be told when this page changes, ask at contact@oraglegpt.org and a person will write to you.