Reqursor Security

1. About this page

This page explains how our products keep your data and your systems safe: Reqursor Platform in section 2 and Reqursor Development, with its license portal and Reqursor Credits, in section 3. Section 4 lists the documents you may need for a security or procurement review, and section 5 explains how to report a vulnerability in any of them. Reqursor Platform is in early access, so we update this page as our products grow.

2. Reqursor Platform

Where it runs

Reqursor Platform runs in the EU, in data centers in Germany (Falkenstein and Nuremberg) and Finland (Helsinki). See GDPR and Data Hosting for what data we process and where.

Every store runs on its own

Each store runs in its own isolated environment, with its own private network and storage. No store can reach another store's data, and no organization can see another organization's stores, settings or status. This is built into how Reqursor Platform works, not a setting someone has to remember. One store's problem never affects another.

Every change is checked and can be undone

• You confirm every change the AI proposes before it takes effect.
• Every change is triple-checked before anything goes live. A change that fails a check is stopped with a clear report.
• If a change still causes a problem, you can undo it in one click. Orders and customers are untouched.
• Every change is recorded, so you can always see what changed.

Passwords, keys and the AI

• Secrets such as passwords and API keys are encrypted at rest and never stored in plain text in logs or change history.
• Account passwords are stored as a salted hash, never in plain text.
• When you use AI features, only the store settings needed for the task are sent to our AI provider. Secrets, orders, products and customer records are never included, and each request holds data for one organization only. The privacy policy lists exactly what is sent.

Encryption in transit

All data in transit is encrypted with TLS. Every store and custom domain gets a TLS certificate that is issued and renewed automatically.

Your account and your team

• Turn on multi-factor authentication when Reqursor Platform asks you to.
• Organization admins invite team members and give each one a role: Admin, Operator or Viewer.
• Keep your sign-in details safe, and contact us right away if you think someone else has access to your account.

3. Reqursor Development

It runs on your own infrastructure

Reqursor Development runs in one of two ways, and your license sets which. Self-hosted with your own key, it is installed on your own server. Its dashboard, worker and agent run there, together with your tickets, run history, audit log and encrypted secrets. You control the host, the network and the backups, and the Terms of Service say what you are responsible for. Hosted with Reqursor Credits, we run the same software for you on servers that we operate, and your tickets, run history, audit log and encrypted secrets, and the copies of your repositories that the agent works on, are stored there. Unless it says otherwise, the rest of this section describes a self-hosted installation.

What leaves your server

• Your code and ticket text leave a self-hosted installation only for the model provider you configured, your git remote and the integrations you connect. With your own key, model requests go straight from your server to your provider and never through Reqursor. On a license that runs on Reqursor Credits, model requests go through our relay instead of straight to a provider.
• The software sends us a daily license check with eight fields of license metadata, and asks about once a day for the signed list of new releases. Neither contains code, ticket text, prompts or model output. An installation on an offline license file sends neither.
• There is no other telemetry. The dashboard loads no external scripts, fonts or trackers, and we switch off the non-essential traffic of the AI tooling the software uses.

The privacy policy lists exactly what is sent, and the AI Usage Policy explains what happens to prompts.

How the agent is isolated

How well the agent is separated from the rest of your server depends on how you run the software:

• On bare metal, the agent runs in a sandbox that shows it only the project it works on and its own scratch space, and it has no route out except the local model gateway and a proxy for package registries.
• With Docker, the agent runs in a separate container that has no access to the key, the database or the license, and no route out except the same gateway and proxy.
• On Windows, and in process-only mode, there is no isolation. The agent runs as a local account that can read what that account can read and reach the network. Use a dedicated machine.

Rules the agent cannot break

The software enforces its git rules in code, not by asking the model. Force-pushes, history rewrites, commits that skip your git hooks, pushes to protected branches and commits of protected paths, such as CI workflows, environment files and secrets folders, are refused. New dependencies outside your allow-list block a change. A secret scan runs on every change. A failing check blocks a change, but the build, type, lint and test checks run your own commands and stay off until you set them. You can also turn on approval before commit, so that large changes or changes to paths you name wait for a person to approve them.

Secrets

• Credentials that you store, such as model provider keys and git and tracker tokens, are encrypted at rest with AES-GCM and are write-only: after you save them, at most the last four characters are shown. A generic webhook address is kept in the database as it is, and is masked wherever it is shown.
• Secrets are redacted from logs, live events, the audit log and diagnostics bundles.
• The agent is not given your model provider credentials. A local gateway holds them and hands each stage a short-lived token.
• The master key is stored on your server with restricted permissions, and backups leave it out unless you ask for it.

Access and accounts

• You sign in with an email address and a password, which is stored as an argon2id hash. Repeated failed sign-ins are rate limited.
• Sessions use HttpOnly, SameSite=Strict cookies that are also marked Secure when you serve the dashboard over https, and every change a browser makes needs a CSRF token. They end after 12 hours of inactivity, and after 14 days at most.
• API tokens are stored as hashes and expire after 90 days by default.
• The roles are Owner, Admin, Developer and Viewer. Viewers can only read.

Updates

With the in-product update on Linux, releases are signed and the software checks the signature before it installs one. It backs up the database first, and if the database update fails it restores that backup and starts the previous release again. With Docker, you build the new release's image yourself, take the backup yourself and go back by restoring it. On Windows, you update by running the installer again.

Reqursor Credits and our relay

The relay reads each model request in memory to check it and to count the usage, and it does not store the request or the model's answer. Its access logs hold the IP address of the connecting server, the time, the method, route, status, duration and a request ID, never a body, a query string or a header value, and are kept for at most 30 days. Its usage records, which carry no code or ticket text, are deleted 7 days after delivery, and a record that our license server rejects stays until we have reviewed and deleted it. The relay accepts only the standard fields of a model request, applies request and spending limits per license, and can be switched off. The connection to it is encrypted with TLS. It does not scan the content of prompts for secrets, so keep secrets out of tickets and code that you send.

The license portal and license server

The license portal at license.reqursor.com has no passwords: you sign in with a one-time link that is valid for 15 minutes, and a session lasts 7 days at most. Payments run through Stripe, and we never see or store your card details.

What the software does not protect against

No software can protect against everything. Reqursor Development does not defend against a compromised model provider or host, against your own administrators, against running without isolation, against data that the agent sends to a place that is allowed, or against subtle errors in code that your checks do not catch. Review what the agent changes, as the Terms of Service ask you to.

4. Security reviews and procurement

If your company reviews suppliers, these are the documents that describe how we protect and handle your data:

• the Data Processing Agreement, which applies when personal data goes through our relay with Reqursor Credits, is stored in an instance that we host for you or reaches us in support material, and which says how we tell you about a personal data breach
• the sub-processor list, which names the providers that process data for us and where
• the Privacy Policy, which says what personal data we process, why, and how long we keep it
• the Terms of Service and the AI Usage Policy, which say who is responsible for what

In short, for Reqursor Development: with a self-hosted license and your own key, your code, tickets and run history are stored on your own server, and model requests go straight to your own provider. Apart from the material you send us for support, we then receive only license information, never your code. Where we host Reqursor Development for you with Reqursor Credits, your tickets, your run history and the code the agent works on are stored in the instance that we run for you, and model requests go through our relay, which does not store them. In both cases the software never deletes your data to enforce a license.

For a security questionnaire or a question that these documents do not answer, email [email protected]. We answer in writing.

5. Reporting a vulnerability

If you find a security problem in Reqursor Platform, Reqursor Development, the license portal, our relay or any of our websites, report it privately to [email protected]. Please don't share the details publicly, and give us reasonable time to fix it.

Include:

• the product, page, URL or version affected;
• the steps to reproduce it;
• the impact you expect.

Never include live passwords or keys in a report. If a credential has leaked, tell us which one and change it first.

We acknowledge every report and keep you informed while we investigate and fix it. There is no bug bounty or other reward, and we don't publish security advisories or credit reporters publicly. Do not test our systems for vulnerabilities without our written permission, and never harm other customers or access data that is not yours. If you find a problem by chance, stop and report it to us as described above.