1. Your site credentials
Monitoring a logged-in journey (a customer account area, a members' portal, a staff booking flow) means SiteOps needs to sign in the way a real user does. This is the part most people want to ask about, so it comes first.
- Encrypted before they reach the database. Credentials are encrypted in the application using Fernet (AES-128-CBC with an HMAC-SHA256 authentication tag) and stored only as ciphertext. Encryption walks nested values, so a password held inside a larger journey definition is covered too.
- Never stored in plaintext, even on failure. If encryption cannot be performed, the value is dropped and the save is abandoned rather than written unprotected. No save is safer than a plaintext save.
- Never sent to an AI model. This is a hard architectural rule, not a filter. When a journey needs to sign in, the credentials are passed straight to the browser session. The prompts sent to the AI contain the page URL, title, and a list of the controls on screen. They never contain field values.
- Decrypted only in the runner, only at the moment of use. A stored credential is decrypted inside the process driving the browser and typed into the page. It is not returned to the dashboard, the API, or the logs.
- Masked back to you. Once saved, your own dashboard shows a stored credential as
********. Re-saving the mask keeps the existing secret rather than overwriting it.
- Signed-in sessions are protected the same way. When SiteOps keeps a session so it does not have to sign in on every run, the session cookies and storage are encrypted with the same mechanism and expire.
- Sites with two-factor login are supported without handing over your phone. Where your site uses an authenticator app, SiteOps works out the six-digit code itself at run time from the encrypted setup key. Nothing is sent to your device, and no one at VUBEX reads the code.
Least privilege is worth applying here as well: where your site supports it, give SiteOps a dedicated, restricted account rather than a real administrator login. Nothing SiteOps does requires admin rights.
2. What SiteOps does, and does not do, on your site
A monitor that can drive a checkout can also complete one. SiteOps is deliberately built so that it cannot spend your customers' money or fill your inbox with test enquiries.
- It stops at the payment screen. A monitored checkout or booking journey walks all the way to the card screen and halts there. SiteOps does not click pay, place order, buy now, complete purchase, or confirm booking, and it does not enter card details. That guard runs on every scheduled run.
- It fills contact and lead forms, but does not submit them. A form step is completed, then SiteOps confirms the submit control is enabled and that the form reports no validation errors, and stops there. You learn the form works without receiving a fake enquiry. Login forms are the exception: they must be submitted, because signing in is the thing being tested.
- You decide if a step should really submit. Real submission is opt-in per step. Untick it and the schedule immediately returns to verify-only, even for a step that was previously approved.
- Test data is obviously test data. Where a multi-step form has to be filled to reach the next stage, SiteOps uses clearly synthetic values and an explanatory message, so anything that does reach a human is recognisable at a glance.
- Runs are bounded. A journey has a hard cap on the number of steps and a run deadline, so an automated run cannot wander off into your site.
3. Your monitoring data
- Isolated per account. The boundary between accounts is enforced by the database itself, on every table, rather than by application code that has to remember. One account cannot read another's data even if the application asks it to.
- Values are never written to logs. A filled field is logged as a character count, never as its contents, because step results are persisted, streamed to the dashboard, and attached to failure reports.
- Evidence expires on a schedule tied to your plan. Failure screenshots and incident evidence carry an expiry stamp when they are written, and both the stored file and its database record are deleted once it passes. Current retention is 3 days on Free, 30 days on Starter, 90 days on Pro, and 1 year on Agency.
- You can delete everything. You can delete your account data from the product. The deletion runs in batches that pick up where they left off, so a large account is genuinely cleared rather than half-cleared.
Screenshots are captured to prove what your site looked like when a journey failed. If a page displays personal data, that page's screenshot may contain it, which is one reason retention is capped and deletion is available.
4. Your SiteOps account
- Two-factor sign-in. You can turn on two-factor sign-in for an email and password account, using any standard authenticator app. If you keep site credentials in SiteOps, turn it on.
- Authentication on every operation. There is no anonymous access to SiteOps data. Every read and write requires a valid, unexpired session, and unauthenticated attempts are rejected and logged.
- Rate limiting and abuse controls. AI features are metered per plan with rolling-window rate limits and cooldowns on expensive operations, so a single account cannot exhaust shared capacity.
5. Infrastructure
- Encrypted in transit. All SiteOps traffic is served over HTTPS with automatically renewed certificates. The web properties are served with HSTS preload, along with a strict referrer policy, frame denial, and content-type protection.
- Secrets are held outside the codebase. Service credentials are loaded from the deployment environment or protected files on the host, never committed to source control.
- Subprocessors. SiteOps runs on a small, deliberately short list of providers: Supabase (database and authentication), Stripe (payments, which means card details are handled by Stripe and never by SiteOps), and Resend (alert email). These are listed in the Privacy Policy.
6. What we do not claim
A security page that only lists strengths is not much use for making a decision, so here is the other half honestly.
- SiteOps is not currently SOC 2 or ISO 27001 certified. It is a young product operated by a small team, and audited certification is a roadmap item, not a present fact.
- Encryption keys are managed at the application and deployment level. There is no hardware security module or per-customer key separation today.
- There is no formal bug bounty programme yet. Reports are still read and acted on, quickly, by the person who wrote the code.
7. Reporting a security issue
Email [email protected]. It reaches a person directly, and it is the fastest route for anything sensitive. You can also use the support portal if you prefer, marking the message as a security report.
Please give us a reasonable window to fix an issue before disclosing it publicly. We will not pursue action against anyone who reports a genuine issue in good faith and does not access, modify, or damage other users' data while finding it. Machine-readable contact details are published at /.well-known/security.txt.
SiteOps is built and operated by a CompTIA Security+ and ISC2 Certified in Cybersecurity (CC) certified engineer. This page describes the service as currently deployed and is updated as the product changes. For data protection questions, see the Privacy Policy.