A client's system is set up after the agreement is signed.
The principle
A client's system is secured in layers that do not depend on each other: who can sign in, what each person or agent may do once inside, how data moves and rests, and what is recorded. A failure in one layer is caught by the next. Every control on this page is enforced on the server, so hiding a button in the interface is never the only protection. Every action, by a person or an agent, is defined, permitted, checked before it runs and traced, inside locked-down environments; nothing in a client's system runs on typed instructions to an AI.
How a client's system is secured
Control | What it guarantees | How you can check it |
|---|---|---|
Sign-in | A small number of wrong passwords locks the account for a while, and too many attempts from one address are refused. Every attempt is recorded. Administrators and Siege’s Forward Deployed Engineer (FDE) also sign in with a second step. | Try a few wrong passwords on a test account, then view the attempts in the people list. |
Sessions | Sessions are checked on every request. Changing a person’s role, disabling a person, or signing out ends the session on the server at once. If the check cannot be made, the request is refused. | Change a test person’s role while they are signed in; their next click asks them to sign in again. |
Forms and cookies | Every form that changes data carries a one-time anti-forgery token. Cookies are sent only over HTTPS and are hidden from page scripts. | Inspect the cookie in any browser: it is Secure, HttpOnly and SameSite. |
Encryption | All traffic is HTTPS with a certificate for the client’s domain, and browsers are told never to use plain HTTP. The connection to the database is encrypted too, and the database, backups and uploaded files are encrypted at rest. | Run any public TLS test against the client’s domain; ask for the provider’s documentation of encryption at rest. |
Secrets | No secret is stored in the code or its history. The system refuses to start without a strong secret key and its own database password. | Read the repository; start the system without its key and watch it refuse. |
Isolation | Each client’s system has its own deployment, database and repository, in the client’s own accounts. No database is shared with any other client. | Check the connection settings of the client’s database and the owner of each account. |
Permissions | Every change is checked against the roles allowed for that action, on the server, before anything is written. | Sign in as a role that may not take an action and try it; the refusal names the roles that may. |
The client’s agents | Each agent can take only the actions it holds keys for, stops wherever a person would be warned, never holds administrator or engineer power, can change no more than a fixed number of rows in any one action, has its own rate limit, and can be switched off by an administrator. | |
Record of change | Every change to the data is logged with who made it, when, and the value before and after, and access changes are logged too. Administrators read and download the log on the Records page. The system’s own database login cannot alter the log, and a copy is kept where Siege cannot write. | Change a value, then find the change on the Records page. |
Your data, any time | An administrator can take a full export of the client’s data from the Records page, without asking Siege. | Press the export and open the files. |
Backups and recovery | Daily backups with checksums, a copy before every deploy, and an off-site copy that the system’s own keys cannot delete; point-in-time recovery if the client chooses it (see Recovery options below). A restore is tested on the client’s own system before go-live. | Ask for the backup schedule and the record of the restore test. |
Changes to the code | The client’s repository starts clean, with no history before the client’s first commit. It accepts no change without a review and passing checks, administrators included. Every dependency is locked to an exact version with a checksum, and the full test suite blocks any deploy that fails it. | Open the repository’s settings and history. |
Deploys | Deploys run through the client’s own pipeline, with no call to Siege. A database change is refused unless it was written from the client’s own Ontology at a revision on its live model. | Read the pipeline in the client’s repository. |
Before a client's real data connects
Any item of this work still open when a client signs gets a date in that client's agreement. Real data connects only once every item is done and shown to the client's technical person.
Recovery options
The client picks one when its system is specified, and the data agreement records the choice.
Daily backup (standard) | Point-in-time (upgrade) | |
|---|---|---|
Most data that can be lost | The work since the last daily backup, at most one day | A few minutes |
Time to restore service | Within one business day | Within 4 business hours |
What it needs | Included | A higher database plan, at the client's cost |
Both include a copy before every deploy, the off-site copy, and a restore tested on the client's own system before go-live.
Response times
Siege answers within one business day, and within 4 business hours when the system is down or data is at risk.
Siege's access
Siege reaches a client’s system in two ways, and only two.
Who | What they can do | What keeps it in view |
|---|---|---|
Siege’s FDEs | People at Siege, signing in through Siege’s FDE account, who take actions through the application like any other user, under the same checks. | Every sign-in and every change is visible to the client’s administrators. |
Changes to the client’s code | Pull requests in the client’s repository. A person reviews and merges each one. | Every pull request and review is in the client’s repository. |
Siege’s own software stays with Siege. It holds no server key and no database login with write access to the client’s production system. The only client data it holds is data the client hands over for a move or a clean-up, described on the Refractor page, and read-only samples of the client’s data used for model work, read through a login that the client issues and can revoke.
What leaves the system
Each service below is named in the data agreement.
Category | What crosses |
|---|---|
Hosting | The client's system and its data, in the client's own hosting account, in the region the client needs |
Off-site backups | Encrypted backup copies |
Mail a person sends from their own mailbox | |
AI provider | Only the fields each AI feature needs, on the client's own provider account |
Alerting | Uptime and error signals, with no client data |