Security you can verify, not just claim
TaskForce puts AI in your delivery path, so it should answer for it. Here is how data is handled, who can do what, and what every run leaves behind — with a public roadmap you can hold us to.
Security principles
Security by architecture, not by promise
The philosophy the rest of this page is built on: the more sensitive the decision, the more explicit the control.
Security by architecture
The more sensitive the decision, the more explicit the control.
Your infrastructure
Self-host TaskForce and keep model traffic inside your network.
Human accountability
AI can propose. Named users approve consequential decisions.
Least privilege
Agents inherit only the permissions granted through their connectors.
Verifiable execution
Model calls, approvals and artifacts leave an auditable record.
At a glance
Where security stands today
No badges we haven't earned. Here is the honest status of each control — and the ones that aren't there yet are labelled just as plainly.
- Self-hosting Available
- Encryption in transit TLS
- Secrets encrypted at rest AES-256-GCM
- SSO — OIDC Available
- Enterprise IdP federation SAML / OIDC
- RBAC & per-project access Available
- GDPR export & erasure Available
- Audit logging Available
- SAST · DAST · dependency scan In place
- Human approval gates Beta
- AI model controls (hosted / local) Beta
- Data retention controls Planned
- SOC 2 / ISO 27001 Not started
- Independent penetration test Not yet
Available is in production · Beta works with rough edges · Planned is on the roadmap · Not started means exactly that.
Security architecture
The trust boundaries, at a glance
Where authentication, your connected systems and the models sit relative to TaskForce — so an architect can read the model before the details.
Your identity provider
OIDC / SAML · authenticates users
Your connected systems
GitHub · Linear · Slack · Postgres
TaskForce
Local model — Ollama
stays in your network
Hosted model — Anthropic · OpenAI
external — leaves your network
Data flow
Where your data goes — and where it doesn't
For an AI product this matters more than any single control. This is the path your data takes through a run, and what self-hosting changes about it.
Your workspace
- Repos, issues, docs
- and the outcomes you describe
TaskForce
- Memory
- Workflow engine
- Audit trail
Model provider
- Anthropic
- OpenAI
- Ollama — local
With self-hosting and local models, your model prompts, outputs and run context can remain entirely within your network.
AI security & governance
AI can propose. It cannot approve itself.
TaskForce treats the model as one component, not the authority. Every consequential step is a human decision, and every model call is accountable after the fact.
Model & provider selection
Hosted models (Anthropic, OpenAI) or local models through Ollama — your choice.
Hosted vs local
Run local models to keep every prompt and output inside your own network.
No training on your data
TaskForce uses provider APIs configured for business use, and never uses your data to train its own models. Training policy for a hosted model depends on the provider and service; local models remove the question entirely.
Human approval
The AI proposes; a named human approves it. An agent can never approve its own work.
Model-call auditability
Every call is recorded — which model, which step, on whose infrastructure.
Agent & connector scopes
Agents act only within the connectors and permissions you explicitly grant.
Identity & access
Your identity provider, your rules
- SSO — TaskForce authenticates through Keycloak over OIDC.
- Enterprise IdP federation — Keycloak can federate with your identity provider over SAML or OIDC.
- RBAC with workspace and project roles: Owner, Admin, Member, Viewer.
- Per-project access — membership is scoped, not workspace-wide by default.
- Session management: short-lived access tokens, refresh, revoke and provider-side logout.
- MFA is managed by your identity provider, not reinvented by us.
- Least privilege: sensitive actions are role-gated; audit logs are owner-only.
- Self-hosted, TaskForce personnel have no access to your instance or its data — you run it.
Data lifecycle
From collection to deletion
The questions a security questionnaire asks — answered up front, including the parts that are still on the roadmap.
Collection
Only what you connect or type into a run: repos, issues, docs and the outcomes you describe.
Processing
During a run, the relevant context is sent to the model you selected — hosted or local.
Storage
Workspace content and memory live in PostgreSQL; files in object storage (MinIO/S3); secrets in an encrypted store.
Retention
Today, data is kept until you delete it. Granular retention controls are Planned.
Deletion
Account and workspace erasure removes your data and the associated Keycloak identity.
Export
GDPR data portability: export your workspace data on request.
Backups
Self-hosted backups follow your own policy; managed backup guarantees are Planned.
Auditability
What every run leaves behind
A fair question for any AI tool: “so you log my prompts and outputs?” Here is the honest answer.
What is recorded
- Who approved what, and when
- Which model ran which step, on whose infrastructure
- Workspace, project, timestamp, token usage and status
- Run artifacts — the drafts an agent produced, kept for your review
What stays in your hands
- With local models, prompts and outputs never leave your network
- You choose the provider per deployment — or none but local
- Audit access is owner-only, not open to every member
- Run artifacts live in your workspace, deletable with it
Integrations & secrets
What can an agent do with the keys you give it?
The real question isn't only “can TaskForce be breached?” — it's what an agent can reach with your connected credentials. Here is how they're contained.
- OAuth for GitHub and Slack; encrypted API keys for other connectors.
- Connector credentials are encrypted at rest with AES-256-GCM and are never stored as plaintext database values.
- They are not included in the prompts sent to models.
- Scopes you grant define what a connector — and therefore an agent — can reach.
- Disconnect a connector at any time to revoke access.
An agent inherits the scopes of the connector, nothing more — and never the raw secret behind it.
Infrastructure
Deployment models
Self-hosted
AvailableRun TaskForce inside your own infrastructure with Docker. With local models, model traffic stays entirely inside your network.
Managed cloud
PlannedA TaskForce-managed deployment is on the roadmap. Until it ships, self-hosting is the way to run in production.
Threat model
What we defend, and what's yours to defend
Security is shared — especially when you self-host. Here is the honest split of responsibility.
What TaskForce protects against
- Unauthorized workspace access
- Credential exposure
- Agent overreach beyond granted scopes
- Cross-project data access
- Prompt and context leakage
- Unauthorized model calls
- Malicious connector actions
What remains your responsibility
- Your own infrastructure and its hardening
- Your identity provider and its MFA policy
- The connector permissions you grant
- Local model hosting and its security
- Host, network and backup security when self-hosted
Security boundaries
- TaskForce controls the application layer.
- Your organization controls the deployment layer when self-hosted.
- Your identity provider controls authentication and MFA.
- Connected systems control their connector-level permissions.
- Model providers control their own hosted inference infrastructure.
Compliance
Compliance & certifications
Stated conservatively on purpose. We won't imply a certification we don't hold — if a row says “Not started,” that's the truth.
- GDPR Technical controls: export, erasure, anonymization
- DPA On request
- Subprocessors Documented on request
- SOC 2 Not started
- ISO 27001 Not started
Technical controls are not the same as full legal compliance — organizational and contractual obligations depend on your deployment and configuration.
Secure development lifecycle
Security runs in the pipeline, not after release
Security checks are part of how code ships, not a review bolted on at the end.
Code scanning (SAST)
Static analysis with Semgrep.
Dependency scanning
Known-vulnerability checks with Trivy.
Container image scanning
Image analysis with Trivy.
Dynamic testing (DAST)
OWASP ZAP against the running application.
Pull-request review
Changes are reviewed before they merge.
Automated CI checks
Security checks run in the pipeline, not after release.
Vulnerability triage
Findings are reviewed and prioritized.
Latest automated scan · July 2026
No high-severity findings detected across the latest SAST, DAST and dependency scans.
Found something? Responsible disclosure to security@taskforce.dev.
Availability & resilience
Keeping it up, and getting it back
When you self-host, resilience is in your hands; for the managed cloud these are Planned. Either way, here is the shape of it.
Backups
- Self-hosted — your backup policy
- Managed cloud — Planned
Recovery
- Backup restoration
- Database recovery
- Object-storage recovery
Monitoring
- Application health
- Infrastructure health
- Model-provider availability
Incident response
- Detection
- Triage
- Containment
- Recovery
Security roadmap
The security roadmap is public too
The honest way to avoid security theater: show what's live, and what we're still building.
Current
- Secrets encrypted at rest (AES-256-GCM)
- RBAC and per-project access
- SSO via OIDC (Keycloak)
- GDPR export, erasure and anonymization
- Audit logging
- Self-hosting
- SAST, DAST and dependency scanning in CI
Building
- Run-level model-call audit trail (with orchestration)
- Granular data-retention controls
- Independent third-party penetration test
- DPA and a public subprocessors register
- SOC 2 groundwork
Security resources
Documentation hub
Everything a review needs, in one place. Public where possible, available on request where appropriate.
- AI transparency
- Privacy policy
- Data Processing Agreement
- Subprocessors
- Security overview
- Security roadmap
- Vulnerability disclosure Coming soon
- Accessibility
Bring it to your security team
Send us your security questionnaire, or book a review and we'll walk your team through the architecture, the controls and the roadmap — including the parts that aren't done yet.
Security contact — security@taskforce.dev