Security overview

A system that writes code and runs it on your data needs boundaries you can point at. This page describes them.

Isolation between workspaces

The workspace is the security boundary, and it is enforced at more than one layer.

• Data. Each workspace’s records and files are stored separately. A query executed for one workspace cannot address another’s data.
• Compute. When a workspace needs to run code — parsing files, transforming data — it runs in an isolated environment dedicated to that workspace, started on demand and torn down when idle. The wall between tenants is the environment itself, not a check in application code.
• Connected tools. Integrations and their credentials belong to the workspace they were added to. They are not visible to, or usable from, any other workspace.

Access control

Authentication is handled by a dedicated identity provider using OIDC. We never see or store your password. Multi-factor authentication is available and we recommend it.

Authorisation is by workspace membership and role — owner, admin, member, viewer — and is re-checked on every request rather than cached into a session. Removing a member takes effect immediately across the app, connected agents and messaging channels.

Per-request workspace binding. Every request states which workspace it is for, and membership is verified against that workspace. A request that names a workspace you are not a member of is refused outright — it does not quietly fall back to one you can see.

Autonomous agents and external clients

Agentic features get specific controls, because they are where the interesting failure modes live.

• Grants are ceilings. An external client connecting over MCP receives access to exactly the workspaces you approved at sign-in — one, several, or all. It cannot widen that later, and your live membership constrains it further: leave a workspace and the grant stops working for it.
• Authorisation is bound to the browser that started it. An approval flow cannot be completed from a different browser, which defeats consent-phishing.
• Credentials are single-use and rotating. Authorisation codes and refresh credentials can be used once. If a used credential is replayed, the entire connection family is revoked rather than reissued.
• Revocation is immediate. Revoking a connection stops it on the next call.
• Workers act only when addressed. In a group chat an unaddressed AI worker may offer to help; it does not act. Scheduled runs exist only where someone scheduled them, and are all listed with their history.

Data protection

• In transit — TLS 1.2 or better for all connections, with HSTS.
• At rest — encryption at the storage layer for databases, files and backups.
• Integration secrets — encrypted, scoped to a single workspace, never rendered back to a user, and never included in conversation transcripts or logs.
• Logs — structured and scrubbed; credentials and personal data are not written at normal logging levels.

Backups and continuity

Databases are backed up on a rolling schedule with backups expiring within 35 days. Restores are tested. Deleting a workspace removes it from live systems promptly and from backups as those expire.

Development practices

• Changes go through review before reaching production.
• Automated tests run on every change, including tests that specifically pin the isolation and authorisation behaviour described above.
• Dependencies are monitored for known vulnerabilities and updated.
• Production access is limited to personnel who need it, authenticated with MFA, and logged.

Incident response

If we detect or are told about a security incident:

1. We contain it first.
2. We investigate scope and impact.
3. Where a personal data breach affects customer data, we notify affected customers without undue delay and within 72 hours of becoming aware, with what we know at the time and updates as we learn more — see DPA.
4. We remediate, and we tell you what we changed.

We do not sit on bad news to make a better statement later.

Beta status

CogniWork is in public beta. The controls above are in place today. We do not currently hold SOC 2 or ISO 27001 certification; when we begin those programmes we will say so here rather than implying it earlier. If your procurement process needs a security questionnaire completed, write to [email protected] and we will fill it in honestly.

Your side of the line

Some things only you can do:

• Turn on multi-factor authentication.
• Grant integrations the narrowest scope that works.
• Review who is in your workspaces, and remove people who have left.
• Check what your scheduled jobs are allowed to touch.
• Don’t put regulated data into a workspace without an agreement with us covering it.

Reporting a vulnerability

Please follow the Responsible Disclosure Policy. Do not report security issues through general support.

[email protected]