Information Security Policy

Control iso27001:A.5.1 in the compliance register; also supports clause 5 (leadership), iso27001:A.6.7 (remote working) and iso27001:A.8.24 (cryptography).

Adopted by the owner on 2-10-2026. At the same time, the owner accepted the residual risks that the risk register treats as "accepted", including one person as owner and administrator and the absence of an external penetration test.

This is the policy that ISO 27001 A.5.1 requires: a single document stating what Stilops wants to achieve with information security, who decides on what, and which rules apply. It is deliberately short and it describes what actually happens. A policy that is nicer than the practice is not a policy but a wish.

1. Purpose and scope

Stilops provides AI agents that carry out work on behalf of an organisation. In doing so, customers entrust to us their business data, and sometimes personal data of their relations. The core of the product is not only that the work gets done, but that it can afterwards be traced what has happened and who approved it.

This policy applies to the entire platform: the customer portal, the administration environment, the public site, the execution of agent tasks, and the infrastructure on which all of that runs. It applies to everyone who works on it — at present the owner — and to the agents that themselves work in the codebase.

2. Objectives

1. Confidentiality. The data of one organisation is not accessible to another organisation, and secrets of connected systems are stored encrypted and are not shown to an agent. Where an agent technically needs a secret, it receives it only for the duration of that task; the exceptions are set out under "Cryptography and key management" and in §5.
2. Integrity and traceability. What an agent proposed, who approved it and what the result was is recorded and is not subsequently altered.
3. Availability. The service is running, and a failure can be recovered from without loss of the audit trail.
4. Human authority. No effect without a human who has approved it.

At Stilops, the fourth is not a security measure but the starting point of the product. The other three exist to make that fourth one credible.

3. Who decides what

That the owner is the only human in this table is a fact and not a shortcoming to be concealed — but it is the single largest risk in the risk register, and it is recorded there as such.

4. Rules that apply

Access. Access is by name and by role. Passwords are stored as a strong, salted hash. Two-factor authentication is available to every user, and is mandatory as an additional step for actions with consequences — including publicly confirming a compliance claim. A rate limit applies to logging in and to forms.

Workplace and remote working. Stilops has no office; all administration takes place remotely, from the owner's workplace. The following rules apply to this: the device's disk is encrypted and the screen locks automatically after a short period of inactivity; the operating system and browser receive security updates as soon as they are released; the accounts with the code, hosting, DNS and payment providers are secured with two-factor authentication; access to servers is only via SSH keys, not via passwords; production data is not copied to the workplace, except a temporary copy for a recovery or an investigation, which is deleted afterwards. In the event of loss or theft of the device, the sessions are terminated within 24 hours and the keys that were on it are renewed, and an assessment is made of whether it is a personal data breach under the Incident and data breach procedure.

Secrets. Secrets of connected systems and of the infrastructure are stored encrypted (AES-256-GCM) with one key per environment, and are only decrypted at the moment a task needs them. They never end up in the prompt to the language model. Accidentally committing a secret is only partly prevented: a test in the quality gate searches the code for secrets with a fixed prefix (such as GitHub, Anthropic and Stripe keys and private keys), and the same patterns are applied to what agents submit as a change. A secret without a recognisable prefix, such as a Hetzner token or a password, is not caught by that check. A user who puts a secret in a chat message has that message intercepted before the model sees it.

Execution of agent tasks. An agent task runs confined under its own, restricted account from a fixed pool. If there are more concurrent tasks than the size of the pool, a task temporarily runs under the shared agent account, where another concurrent task can read its decrypted configuration. This is being closed. An agent of a customer never gets access to data of another organisation, has no mailbox and sends no e-mail.

Changes to the software. Every change goes through a fixed automated gate: style, type checking, the full test suite, a check for committed secrets and a check for known vulnerabilities in dependencies. A change to a gate or an authorisation must moreover be deliberately broken to prove that the corresponding test turns red — a gate that has not been broken guards nothing until the contrary has been demonstrated.

Changes and compliance. Before merging, every change is also assessed for what it means for compliance: does it affect anything that a compliance document, the controls or the terms promise? Software determines which subjects a change affects; a separate, read-only review agent then assesses whether the change may proceed as it is, whether a compliance document must change along with it (which Stilops itself updates in the same change, after which the owner adopts the new text), whether the owner must decide, or whether the change is stopped. A change to the terms, the privacy statement, the data processing agreement or the list of sub-processors, a risk that must be accepted and a measure that becomes weaker, always lie with the owner; so does a test that does not reach a verdict. In addition, every quarter Stilops lays all compliance documents alongside the code and turns every deviation into a finding.

Logging. Actions of administrators and of organisation users are recorded append-only. A recorded action is not changed and not deleted.

Cryptography and key management. Traffic runs over TLS. Data at rest that constitutes a secret is encrypted with AES-256-GCM, with two known exceptions: the short-lived read token of the Search Console connection (valid for one hour at most) is deliberately stored unencrypted, and the Anthropic API key for customer runs is present as a file on disk during such a run, for up to two minutes. The key is kept per environment outside the source code and the database and is readable only by the service itself, on machines where the agents run under a separate account (a separate setting for that account). Where that separation has not been set up, such as on the local development and production environment, agents run as the same user as the service and can read both the key and the encrypted values.

What an agent can read, also where the separation has been set up: the Anthropic API key during a customer run; the ordinary Cloudflare token; as long as the local tunnel for connection secrets is not switched on, the decrypted configuration file of a task; and with a full pool also the configuration file of another concurrent task, with the connection secrets of a customer. Where that tunnel is switched on, those secrets do not end up in a readable file. The database with the data of all organisations is also readable by the agent account, because the servers that agents use need it. An agent of a customer cannot reach it: it then has no shell, a fixed check before every action restricts its reading to its own working directory and attachments, and the tools it receives filter on its organisation. That separation lies in the application, not in the operating system: if that check falls away, nothing holds the account back. These are residual risks, and the first is recorded in the risk register (R13).

External access keys are renewed to the extent the supplier allows. The Cloudflare token is renewed by Stilops itself. For Hetzner, GitHub, Anthropic, Stripe and MXroute, Stilops creates a reminder as a finding and the owner renews the key personally. For the remaining connections (S3, OneDrive, VirusTotal, LinkedIn, PageSpeed, Bing, the Google service account and the SMTP and IMAP passwords) no reminder is in place; there, only the manual key rotation in the operational planning applies. For Hetzner, there is in addition a monitor that reports every action in the Hetzner action log that does not originate from Stilops itself; for the other suppliers that monitoring does not exist.

A key change after a (suspected) leak invalidates existing public compliance confirmations: these must then be given again, because whoever had the old key may have forged them. In the event of an ordinary change, Stilops re-signs, with the new key, every confirmation that was valid under the old key. Sessions and invitation and reset links expire upon every change.

Incidents. What an incident is, how it comes in and within what period what is reported to whom is set out in the Incident and data breach procedure. The decision to report is human.

Suppliers. Every party that processes personal data is listed by name, purpose, country and the status of the processing agreement in the Sub-processor list — also where that agreement is missing.

5. What this policy must honestly admit

• There is no segregation of duties. One person adopts policy, approves and administers. The compensation is that the audit trail is complete and append-only, and that the heaviest actions require an extra verification step. That is a compensation, not a solution.
• Recovery is tested, but not yet fully. Decrypting and checking the back-ups has been tested; a full recovery exercise each quarter has been set up and the first execution is still outstanding. Details are in the continuity plan, which customers can view in the portal.
• Secrets are not unreadable to every agent. See "Cryptography and key management": the Anthropic API key during a customer run, the ordinary Cloudflare token, and on machines without a separate agent account also the key itself. Closing this off is an open consideration.
• The separation between organisations in the database is a separation in the application. The database with the data of all organisations is readable by the agent account, because the servers that agents use need it. That an agent of a customer cannot reach it is ensured by a fixed check in the application, not by the operating system: if that check falls away, nothing holds the account back.
• There is no external penetration test.

These points are recorded as an open item in the compliance register. They are set out here because a security policy that names only the strong points misleads the reader about what he can rely on.

6. Compliance and review

The compliance register at stilops.com/nalevingsregister is the ongoing measurement of this policy: per standard and per control, what the status is, with evidence. Deviations come in as a finding and are routed to whoever is responsible for them.

This policy is reviewed when the organisation grows to more than one person, when a new category of data or a new supplier is added, after an incident with impact, and at the latest annually.