How TaskCrew protects your work.
Who can open what, how secrets are stored, what AI teammates can and can’t reach, and what we don’t claim. Everything below is in the product today, with the details in the security docs.
The short version.
Six things to know before you read the rest.
Secrets encrypted at rest
Password vaults, connector tokens and chat webhook links are encrypted with AES-256-GCM. API and provisioning tokens are stored only as hashes.
Sign in your company’s way
SAML 2.0 single sign-on, SCIM 2.0 provisioning and Require SSO. Rate-limited sign-in for everyone.
Only what people need
Roles per workspace and project, private projects, restricted lists, guests who see only what you share, and a My space nobody else can open.
AI in a sealed sandbox
Each AI run gets its own container with no network and no secrets. Actions in other tools can wait for a person to approve them.
Everything logged
Task changes, membership and single sign-on events, AI tool calls and vault reveals are all logged, and the audit logs download as CSV.
Your choice of where it runs
Use TaskCrew Cloud, or run it on your own servers with Docker, in the region you choose.
The right people, and only them.
Sign-in that follows your identity provider, and permissions down to a single list.
SAML single sign-on
Okta, Microsoft Entra ID, Google Workspace and other SAML 2.0 providers. Sign-in starts from TaskCrew, the assertion must be signed, and an answer can’t be used twice. Only addresses at email domains you verified by DNS can sign in.
Require SSO
Turn it on once a test sign-in passes. Owners keep their password for emergencies, and each use of it is logged.
SCIM provisioning
One token per workspace, stored as a hash. Someone turned off in your identity provider loses access at once: they come off its tasks, and their tokens and calendar link stop.
Passwords and sessions
Passwords are hashed with scrypt and failed sign-ins are rate-limited. A password reset or change signs out every other device at once.
Permissions per item
Owner, admin, member and guest in the workspace; manager, editor, commenter and viewer on projects and lists. Any project can be private and any list restricted.
Guests
People from outside get View, Comment or Edit on what you share, never Manager. They never see vaults, chat, AI teammates or the rest of the workspace.
My space
Everyone’s private project. Nobody else can open it, not even admins, and access reviews leave it out.
API tokens
A token acts as its owner in one workspace only. It’s shown once, stored as a SHA-256 hash, and refused on account, admin and vault routes.
Secrets stay secret. Shared things stay in bounds.
Team passwords, encrypted and accounted for.
Logins, 2FA codes, SSH and API keys, and files such as certificates, shared with exactly the people who need them.
- AES-256-GCM at rest, with a new random IV on every write
- Members-only: admins can see a vault exists, but not its entries, until they add themselves (and that shows)
- Your password is asked for again before a secret is shown
- Every reveal, copy and download is logged with who and when
- Never shown to AI teammates, MCP, search or exports, and vaults can’t be exported
Everywhere else
Encrypted with a key kept apart
Connector tokens, chat webhook links and public links are encrypted with AES-256-GCM, using a key kept in the server’s settings, never in the database.
Public links that end
Read-only, unguessable, and they expire after 7, 30 or 90 days. Never indexed, never showing descriptions, comments or files. Admins can turn every link off at once.
Exports that respect access
An export holds only what the person downloading can open. Text a spreadsheet would run as a formula stays text.
Files through the front door
Files always leave through the API, after an access check. The storage bucket stays private, with no public file links.
Nothing deleted by accident
Deleted tasks go to the Trash with Undo, and only managers delete for good. Deleting an item for good needs a typed confirmation that lists what will be lost.
Deleted when you ask
A workspace can be deleted, or a person erased, for good, including their files in storage. Backups keep a copy until they expire.
AI teammates work in a sealed box.
Reading is free. Changing anything outside TaskCrew can wait for a person, who sees exactly what will happen.
Asks first
Each action in Slack, HubSpot, Gmail and other connected tools waits for Approve or Reject, with the exact details.
Sandboxed
Every run gets its own sealed container: no network, no secrets, a read-only file system.
Spend limit
Set a monthly limit. At the limit AI pauses until you raise it or the month ends. No surprise bill.
Every step logged
Every tool call, with its inputs, results and timing, is written to the audit log by the runner, not the AI.
Sees what you share
Ask your workspace answers only from what the person asking can open.
Never sees passwords
Password vaults are invisible to AI teammates, MCP, search and exports.
How a run is sealed
- One container per run: read-only file system, a non-root user, every capability dropped
- No network. Model calls and tool calls go back through the runner, which allows only what it should
- No secrets. The AI provider key and connector tokens stay in the runner
- The runner writes the audit log, so a run can’t skip or forge an entry
- Memory, CPU, step and time limits on every run, and gVisor as an option
- A sandbox escape test checks that network, other files, child processes and secrets are out of reach
Where AI data goes
- AI runs on
deepseek/deepseek-v4-flashthrough OpenRouter - By default, AI requests only go to model providers that don’t keep or train on prompts
- Ask your workspace answers only from what the person asking can open
- Describe your project sends only what you type, no workspace data
- Approvals are made by people only: never by AI teammates or API tokens, and never from a link in an email or chat message
- No answer within 30 minutes means the action is rejected
Careful with everything that comes in.
Files, forms, emails and AI output come from outside the team, so TaskCrew treats them as untrusted.
Links in emails
Password reset links are signed, last one hour and work once. They travel in the part of the address that never reaches server logs.
Single sign-on, hardened
Signed assertions only, audience and recipient checked, each request used once (replays fail across servers), no external XML entities, and defences against signature wrapping. Each case has a test.
Uploaded files
Checked by what they contain, not their name. Served with nosniff and a sandboxing Content Security Policy; thumbnails are made only from real images, within pixel and time limits.
Reading attachments for search
Done in the background, one isolated worker per file, with memory, time and size limits that also stop zip bombs. Encrypted files aren’t opened.
Forms without a CAPTCHA vendor
A hidden field, a time trap, an optional sum and rate limits keep spam out. Programs and scripts are refused, and answers stay plain text.
AI output is untrusted
Project plans written by AI are checked against a schema and cleaned: mentions become plain words, images become links, and only web and email links are kept.
Tests that guard it
Integration tests check that vault secrets never appear in lists, search, exports, MCP or AI tools, and a guard test fails if other code reads the encrypted column.
Safe defaults at start
A production server refuses to start with example, short or reused secrets, or with insecure cookies over HTTPS.
Limits, exactly
| Failed sign-ins | 10 per email and 30 per IP address per 15 minutes, then a pause, even with the right password |
|---|---|
| Sign-ups | 10 per IP address per hour |
| Password reset emails | 3 per address per hour; reset links last 1 hour and work once |
| Sessions | 7 days; single sign-on sessions 12 hours by default (1 to 168, set per workspace) |
| Vault reveals | 30 per person per minute; 5 wrong passwords in 10 minutes pause unlocking |
| Copied secrets | Cleared from the clipboard after 30 seconds (best effort) |
| Form responses | 5 per IP address per form per 10 minutes, 20 per IP address per hour, 300 per form per hour |
| Public links | 300 unknown links an hour per network, 600 views an hour per link |
Limits are counted per API server. Self-hosted servers use the same ones.
How a production server is set up.
TaskCrew runs from one Docker Compose file. This is what its production setup does out of the box.
HTTPS in front
Caddy gets and renews Let’s Encrypt certificates and adds HSTS. Only ports 80 and 443 need to be open.
Nothing else exposed
The web app and the API listen on 127.0.0.1 only, behind the proxy. The database is reachable only inside the private Docker network.
Daily backups
A database dump every 24 hours to S3-compatible storage, kept for 30 days. A restore drill on 13 Oct 2026 restored a dump and compared row counts: they matched.
A contained sandbox host
The runner reaches Docker only through a least-privilege socket proxy, and gVisor can be added for stronger isolation.
Secrets outside the code
Secrets live in a settings file that is never committed. The server won’t start with the example values once it’s reachable beyond localhost.
Alerts and health checks
Server errors, failed backups and crashed runs are posted to an alert channel, and health endpoints are ready for an uptime monitor.
What we claim, and what we don’t.
SOC 2 reports and ISO 27001 certificates are audits of the organisation that runs a service, by an accredited firm. Software isn’t certified, so you won’t find a badge here. What TaskCrew gives you are the controls those audits look for, and the evidence to show.
| Control SOC 2 / ISO 27001:2022 | In TaskCrew | Evidence |
|---|---|---|
| Logical access, least privilegeCC6.1, CC6.3 / A.5.15, A.5.18, A.8.3 | Workspace and project roles, private projects, restricted lists, My space | Settings → Access review (CSV) |
| AuthenticationCC6.1 / A.5.17, A.8.5 | SAML SSO and Require SSO, scrypt password hashes, sign-in rate limits, session revocation | SSO settings; the sign-in entries of the audit log |
| Provisioning and deprovisioningCC6.2, CC6.3 / A.5.16, A.5.18 | SCIM, invites, immediate removal (tasks, tokens, sessions, push devices) | Audit log: members, invites and provisioning (CSV) |
| Logging and monitoringCC7.2 / A.8.15 | Task audit log, workspace audit log, every vault reveal logged | Audit log CSVs; vault access logs |
| EncryptionCC6.7 / A.8.24 | Vault and connector secrets AES-256-GCM at rest; tokens stored as hashes | The security docs; your TLS and disk encryption |
| Automation and API accessCC6.1 / A.8.2 | Personal API tokens confined to one workspace and refused on account and admin routes; AI teammates never see vault secrets | Access review “Tokens & links” (CSV); audit log “API tokens” |
| Change management, backups, incident response, vendors, peopleCC8, CC9 / A.5.24–A.5.30, A.6 | Organisational: these belong to whoever runs the service | Their policies and records |
Running it yourself?
These controls become part of your own audit. You run the service, so the report or certificate is yours.
Using TaskCrew Cloud?
Tell us what your security review needs and we’ll go through it with you. Contact us
Privacy
How we handle personal data, and who processes it for us. Privacy policy · Subprocessors
Found a security problem? Tell us.
Email security@taskcrew.com with what you found. This covers TaskCrew Cloud and the TaskCrew software you run yourself.
What to send
- What you found, and where
- Steps to reproduce it
- The impact you think it has
- How to reach you
Please
- Test only with your own account and workspace
- Don’t open, change or delete other people’s data
- Don’t slow the service down for others: no denial of service, no spam
- Give us time to fix it before you tell anyone else
From us
We’ll confirm we got your report, keep you posted while we fix it, and credit you when it’s fixed if you’d like.
Bring your security review to us.
We’ll go through single sign-on, SCIM, the audit log and how AI teammates are contained, for the cloud or your own servers.