This page is a first draft prepared for review. It has not yet been approved by counsel and does not yet form part of any contract.
What we actually do to protect your data
This page describes controls that exist in the running product today. It also has a section listing what we have not built. Both halves are here on purpose.
Last updated: August 14, 2026
Why this page reads the way it does
Most security pages are written to close a deal. They say "enterprise-grade encryption" and "bank-level security" because those phrases mean nothing and therefore cannot be falsified. We would rather tell you precisely which controls exist, so that you can decide whether they are sufficient for what you were planning to put in here.
We are a young company. Some of what a mature vendor would have, we do not have yet. Those gaps are listed below in the same detail as the controls, because you cannot make a real decision from only half the picture.
Accounts and sessions
Passwords are hashed with Argon2
We never store your password. It is hashed with Argon2, a memory-hard algorithm designed to resist offline cracking. We cannot read your password, and nobody at this company can tell you what it is.
Session cookies are locked down
The session cookie is httpOnly (JavaScript on the page cannot read it), secure (it is only ever sent over HTTPS), and sameSite=lax (it is not attached to cross-site requests). Sessions last 30 days and can be revoked.
A password reset kills every session
When you reset your password, every existing session on your account is destroyed — not just the one you are using. If someone else had a session, that reset ends it.
Login and signup are rate limited
Repeated authentication attempts are throttled, which blunts credential-stuffing and brute-force attempts against accounts.
API keys are stored as a hash only
If you generate an API key, we store only its SHA-256 hash. The key itself is shown to you exactly once at creation and is not recoverable afterwards — including by us. If you lose it, you generate a new one.
Tenant isolation
A request cannot ask for someone else's data
Client scoping is enforced in middleware, not left to individual handlers. Any client identifier supplied by the caller is overwritten with the authenticated principal's own, and a mismatch is rejected with a 403. Our services never trust a client identifier that came in over the wire.
Media downloads check ownership
Downloading a deliverable through the dashboard requires an authenticated session, verifies that the file belongs to your account, and passes the requested path through a traversal guard so a crafted filename cannot walk out of the intended directory.
Staff cannot act as you
There is no impersonation capability in this platform. The admin “view as client” screen is read-only: it performs no session swap and has zero action controls, so a staff member cannot take actions inside your account from it. Staff actions are audited separately.
Network and infrastructure
Everything is served over TLS
All traffic to the platform terminates TLS at nginx on port 443. There is no plaintext HTTP path into the application.
Internal services are not reachable from the internet
Every internal service binds to 127.0.0.1 — the loopback interface — so nothing but the local machine can connect to them. The only externally reachable services on the host are nginx and SSH.
Encryption and payments
Stored credentials and second factors are encrypted
Three things are encrypted with AES-256-GCM, using a 12-byte random initialization vector and a 16-byte authentication tag per record, so tampering is detectable and not merely a decryption failure: the per-client social publishing credential, any account credential you give us where a platform offers no delegated access, and your two-factor authentication secret. A stored credential is never sent back to a browser, never written to a log, and never included in an error message — the only code that decrypts one runs on the server while doing the work you asked for, and it records who used it and when before it does. See the honest limits below.
We ask for delegated access before we ask for a password
Where a platform supports it — Google Ads, Meta, Analytics, Search Console, Business Profile — we ask to be added as a manager, partner or user on the account you own, rather than asking for your login. No password changes hands, you stay the owner, your own two-factor stays in force, and you can remove us from the platform without asking us. We only store a real credential where no delegated option exists. Whatever we hold, of either kind, is listed in your dashboard under Security, and you can revoke it there.
We never see your card
Payments run through Stripe's hosted checkout. Card numbers are entered on Stripe's own page and never touch our servers, our logs, or our database. We store the outcome of a payment, not the instrument.
Privacy on this website
No analytics, no trackers, no ad cookies
We run no analytics platform, no third-party tracking scripts, and no advertising cookies. The only cookie this product sets is the session cookie that keeps you logged in. We are not building an advertising profile of you, because we are not collecting one.
What we have not built yet
These are real gaps, stated plainly. If any one of them is a dealbreaker for your business, we would rather you know now than find out later.
Most data is not encrypted at rest
Only secrets are encrypted in our database — the three described above. Everything else, including your briefs, deliverable metadata, and audit results, is stored unencrypted at the application level. We are not going to describe that as “encrypted at rest”, because it is not.
No key management service, and no key rotation
One encryption key, held as an environment variable on the same host as the application, protects everything described above. There is no KMS, no hardware security module, and no rotation schedule. Anyone with host access has the key — so encryption at rest protects you against a stolen database, which is the common case, and not against someone who has already reached the server.
Files in our object storage are not access-controlled by URL
Uploaded files, generated media, and PDF reports live in an object storage bucket. Listing the bucket is denied, but individual objects are readable by anyone who has the URL. This is architectural: our AI generation providers fetch your source files by URL in order to produce your work. Treat anything you upload as readable by anyone holding the link, and do not upload material you would not accept being seen that way. Downloads initiated from your dashboard are separately authenticated and ownership-checked; that protection does not extend to the raw storage URL.
Two-factor authentication
You can turn on app-based two-factor authentication (TOTP) from your account settings, using Google Authenticator, 1Password, Authy or any standard authenticator app. Enrolment only completes once you have proved you can generate a valid code, so a half-finished setup cannot lock you out. You also get ten single-use recovery codes, shown once and stored only as hashes — we cannot show them to you again, and we cannot recover them for you.
No formal certification or third-party audit
We hold no SOC 2 report, no ISO 27001 certificate, and no HIPAA attestation, and we have not been through an independent security audit or penetration test. Do not use this platform for protected health information, payment card data, or anything else carrying a regulatory obligation we have not been certified against.
No automated security scanning
We do not currently run automated vulnerability or dependency scanning against the codebase or its dependencies.
No granular staff roles
Our internal staff and admin roles are functionally identical — there is no least-privilege separation between them today. Staff cannot act inside your account, as described above, but the internal roles themselves are not tiered.
No content moderation on generated output
We do not run our own moderation layer over what the AI providers return. The providers apply their own policies; we do not add a second check. Review your deliverables before you publish them.
Reporting a vulnerability
If you think you have found a security problem, email security@optimizeplus.agency with enough detail for us to reproduce it. We do not run a paid bug bounty, and we will not pretend otherwise — but we will read your report, respond, and credit you if you want to be credited. Please do not test against other people's accounts or data.
Where your data goes
Security is only half the question — the other half is who else sees your data at all. Every third-party provider we send data to is listed publicly, along with what each one receives.
Anneshy Royals Inc., doing business as OptimizePlus · 28 Geary St., Suite 650, San Francisco, CA 94108