This page sets out how Decisive is built, operated and audited: the tenant-isolation model, what customer content reaches an AI provider, how the coding agent is sandboxed, and the commitments we make about your data. It is written for the person conducting your security review, and is deliberately specific enough to be verified rather than taken on trust.
1. Compliance programme
Formal certification is our highest compliance priority, and the control work it rests on is already implemented and enforced in code rather than described in a policy document. The sections below are that programme: tenant isolation proven by automated tests, credential handling designed so that no shared secret reaches an untrusted process, a gated supply chain, and a recurring adversarial audit cycle.
SOC 2 readiness is in progress. No report has been issued yet, and we will not describe ourselves as certified before an auditor has issued one — when that happens, it will be published here. If certification status is a gating requirement for your review, contact [email protected] and we will tell you precisely where the programme stands and the timeline we are working to.
Controls in place today
Enforced in Postgres by row-level security, with regression tests that fail the build if a policy weakens.
TLS in transit. Stored credentials encrypted with AES-GCM under a key held outside the database.
Passwordless authentication, administrator and member roles, single-use invitations consumed transactionally.
Recurring AI-driven audits against the whole codebase; every confirmed finding becomes a regression test.
Secret scanning on every commit, static analysis, dependency review, and hash-pinned build steps.
Full workspace export on every plan, with a contractual 60-day wind-down commitment.
Framework status
Readiness is underway and the underlying controls are implemented and enforced in code. No report has been issued yet; we will publish it when it has.
Its control requirements overlap substantially with the SOC 2 readiness work above. No certificate has been issued yet.
Data Processing Agreement available on request, sub-processors published, data-subject requests honoured, analytics processed in the EU.
Decisive is not a business associate and does not offer a BAA. Protected health information must not be stored in a workspace.
We complete customer security questionnaires, and a Data Processing Agreement is available on request.
2. Continuous adversarial auditing
Decisive's architecture and codebase are audited on a recurring basis using frontier AI models, directed adversarially at our own system: instructed to defeat tenant isolation, to escalate a standard member to administrator capability, to reach another workspace's data, and to extract credentials from the environments that hold them. Because the audit is automated, it runs against the whole codebase rather than a sample, and it is repeated as the product changes rather than once a year.
A finding is not considered closed when the code is fixed. Every confirmed issue is remediated and then converted into an automated regression test that fails the build if the defect is ever reintroduced, so the security posture ratchets in one direction only. Claimed findings are verified against a live database before being accepted, because an analysis that reads plausible in the abstract is not evidence of a vulnerability, and a control that depends on someone remembering it is not a control.
3. Architecture
Decisive operates on managed infrastructure rather than self-administered servers. The application and its API run on Cloudflare's edge network; customer data is held in a managed Postgres database, with file storage and authentication provided by Supabase; real-time audio and video are carried by LiveKit. Every provider that processes data on our behalf is enumerated in the sub-processor list in our Privacy Policy.
All traffic is served over TLS. Credentials held on your behalf — AI provider API keys, connected-account tokens such as Google, and agent secrets — are encrypted with AES-GCM before storage, under a key held outside the database.
4. Tenant isolation
The boundary between workspaces is enforced in the database itself, through Postgres row-level security, rather than in application code alone. Every query — including one issued in error by our own front-end — is constrained by policies that evaluate the caller's authenticated identity against their workspace membership. Columns that confer a capability, such as the GitHub installation a workspace is bound to, are writable only by the server, an invariant enforced by database triggers on both insert and update.
We treat this as the control that matters most, and it is therefore held in place by tests rather than by review discipline. A suite of regression tests fails the build if a policy loses its constraints, if an identity column ceases to be bound to the authenticated user, or if the trigger protecting capability columns is weakened. A separate audit script sweeps the live database's policy catalogue, so that a policy altered in the hosting dashboard — outside our repository — is still detected.
Switching between workspaces always performs a full page load. This is deliberate: it guarantees that in-browser state belonging to one workspace cannot survive into another session or reach the AI's context. That behaviour is itself enforced by an automated test and cannot be removed as an optimisation.
5. Customer content and AI
AI features transmit the relevant portion of your workspace — the messages, tasks, documents or code the request concerns — to an AI provider in order to generate a response. Claude is the default provider; a workspace administrator may additionally enable OpenAI for certain features. No content is sent to a provider that a workspace administrator has not enabled.
Customer content is not used to train models. Decisive neither builds nor fine-tunes models, and we access providers through their API tiers, under which submitted content is not used for model training. Your workspace content is not used to improve the Service for other customers.
Model access is metered per workspace and routed through our own server, so an AI provider key is never present in the browser.
6. The coding agent
Decisive can run a coding agent against a GitHub repository you connect. That agent executes code in a cloud container, and the container is treated as the least-trusted component in the system by design, because the instructions it follows originate in task titles and comments that any workspace member can author.
- No shared credential enters the container. It receives no AI provider key, no database service key, and no broadly scoped access token.
- Model calls are proxied. The container holds only a short-lived, cryptographically signed token scoped to a single run; the provider key is injected server-side. A leaked token is usable only through our metered proxy, only for that run, and only until it expires.
- Repository access is scoped to the bound repository. The GitHub token is minted for that repository alone, with a minimal permission set, never for the full breadth of the installation.
- Administrator secrets remain with administrators. Build environment variables are injected only where the member launching the run holds administrator privilege.
- Changes are delivered as pull requests. The agent proposes; a human reviews and merges. It does not write to your default branch.
These properties are enforced by an automated test that fails the build if a launcher places a resolved provider key on the container payload or omits the run-scoped token.
7. Authentication & access
Decisive accounts are passwordless. Authentication is by one-time code sent to a verified email address, or via Google. No password is requested, stored, or capable of being disclosed. Sign-in is protected by a bot-prevention challenge, and disposable email domains are rejected at account creation by a database-level hook covering every sign-up path, including OAuth and direct API calls.
Workspaces distinguish administrator and member roles, enforced by the same row-level security layer as the rest of the data model. Invitations are single-use and are consumed within the transaction that creates the membership, so a revoked or previously used invitation cannot be replayed. Removing a member revokes access to workspace data, real-time sessions and outstanding invitations.
Every workspace keeps an append-only audit log — access changes, configuration changes, every coding-agent and AI run, and each export of the data — readable by its administrators on every plan. Anything the browser can change is recorded by a database trigger inside the same transaction as the change itself, so the action cannot occur without its record; the rest is written where the action is only possible, on the server. No client, of any role, can edit or delete an entry. It exports to CSV.
8. Secrets & supply chain
Our build pipeline treats a disclosed credential and a compromised dependency as the same class of risk.
- Secret scanning gates every commit and pull request. A scanner runs as a pre-commit hook and as a required continuous-integration check, and can sweep the full repository history on demand.
- Static analysis. CodeQL analyses the codebase on every change.
- Dependency review. Pull requests introducing a dependency with a known vulnerability are flagged before merge.
- Pinned build actions. Every third-party continuous-integration step is pinned to a full commit hash rather than a mutable tag, so a compromised upstream release cannot silently enter the pipeline. Application dependencies are pinned to exact versions.
- No credential resides in the repository. Environment files are excluded from version control, and their committed counterparts contain placeholders only.
9. Source confidentiality
Decisive's source code is not published. This is a data-protection decision rather than a commercial one. The codebase is a precise description of how customer data is stored, isolated and accessed; publishing it would provide anyone probing for a way in with the same map our own engineers work from. We are not prepared to accept that exposure on behalf of the teams whose private work we hold.
Transparency about what happens to customer data does not require public source. This page describes the architecture and its controls, the Privacy Policy enumerates every sub-processor able to touch that data, and any question a review still needs answered is answered directly.
10. Data ownership, export & continuity
- Export is self-serve, on every plan. A workspace administrator may download the workspace's full contents at any time from Settings → Danger Zone. There is no paywall, no request form, and no dependency on our availability to action it. Our Terms of Service commit us to maintaining this.
- Source code remains in your repository. Decisive reads from, and opens pull requests against, your own GitHub repository. It is not the system of record for your source, so disconnecting the integration carries no data cost.
- Deletion is effective. Deleting a workspace or account removes the associated data, subject to residual copies in routine backups for a limited period and to any legally mandated retention. The detail is set out in our Privacy Policy.
- Wind-down is contractual. Should we discontinue the Service, we commit to a minimum of 60 days' notice with export available throughout — a term of the contract, not a marketing statement.
11. Reporting a vulnerability
Email [email protected]. This is the sole reporting channel; please do not disclose details publicly before a fix has shipped.
Response targets: acknowledgement within 48 hours, and an assessment with a remediation plan or a fix within 7 days. The hosted product deploys continuously, so confirmed fixes reach production without waiting on a release cycle.
Research conducted against the live product must use only accounts and workspaces you have created yourself, must not access or exfiltrate another customer's data, and must not include denial-of-service or volumetric testing. Good-faith research observing these conditions will not result in legal action, and we offer credit for confirmed reports, or anonymity where preferred.
12. Data location & sub-processors
Product analytics are processed within the European Union. Our infrastructure and AI providers operate globally, and certain providers process data in the United States; where required, we rely on appropriate transfer safeguards. The complete and current list of providers, and what each processes, is maintained in the Privacy Policy.
Security questionnaires, Data Processing Agreement requests and architecture questions are answered directly at the address below.
13. Common questions
Is Decisive SOC 2 certified?
Not yet. SOC 2 readiness is in progress and the underlying controls are implemented and enforced in code, but no auditor has issued a report and Decisive holds no certification today. We will publish it here when that changes. ISO 27001 is under evaluation only.
Do you train AI models on our content?
No. Decisive neither builds nor fine-tunes models, and we reach providers through API tiers under which submitted content is not used for training. Your workspace content is never used to improve the service for other customers.
Can Decisive be self-hosted?
No. Decisive is a hosted product at app.decisive.rocks and there is no self-hosted edition today. Running the model and the agent on hardware you control is a direction we are committed to, but there is no date to give you.
Is Decisive HIPAA compliant?
No. Decisive is not a business associate, offers no BAA, and protected health information must not be stored in a workspace.
Is a Data Processing Agreement available?
Yes, on request, and we complete customer security questionnaires. Product analytics are processed in the European Union; the complete list of sub-processors and what each one handles is maintained in the Privacy Policy.
Is there an audit log?
Yes, on every plan, readable by workspace administrators. It records access changes, configuration changes, every coding-agent and AI run, and data exports. It is append-only — no client, of any role, can edit or delete an entry — and it exports to CSV.
How is one workspace kept out of another?
Tenant isolation is enforced in Postgres by row-level security rather than in application code, so a bug in our front end cannot reach another team’s data. Every confirmed audit finding is converted into an automated regression test, so the same defect cannot return.