Security and data

What Dcision storesCopy Anchor Link

Where your state goesCopy Anchor Link

To answer a decision, Dcision sends the engine provider:

• the state — all of its fields, including fields the schema doesn't declare — and the decision's context, as decision_context;
• the question instructions, the options, levels and criteria, as text or JSON;
• the model name.

Composite weights, policies and settings stay in Dcision: they are applied after the engine answers.

Destinations can send data on after the decision — only where you configure it:

• Webhooks and workflows send the answers, the action and the params you map — never the state itself.
• API requests send what your URL, headers and body template contain.
• Agents receive the whole state as input; LLM destinations send the state — or the input you set — to your model provider, under your key.
• Fixed replies and functions are returned to the caller; nothing leaves Dcision.

See Destination security and limits.

With Dcision's engine key, the call goes directly to TypeSafe's API (Jev) under Dcision's account; TypeSafe states that Jev is not trained on customer requests or responses — see its legal documents. With your own key, it goes to the provider you chose, under your account and its terms. See Engines and BYOK.

Dcision doesn't write your state or your keys to its application logs.

Retention and deletionCopy Anchor Link

• Executions are deleted after the shorter of your plan's retention (Genesis 7 days, Developer 14, Growth 30, Enterprise 365) and the workspace's Execution log retention setting.
• Deleting a decision deletes its versions and executions immediately.
• Idempotency records expire after 24 hours, whatever the decision's storage settings.
• Revoking an API key disables it at once; the hashed record stays for your history.
• Destination deliveries are deleted 30 days after they were created, whatever the log retention — also when their decision was deleted.
• Deleting a workspace (its Owner can) deletes its decisions, versions, executions, API keys, invitations, secrets and deliveries. The Stripe customer is kept, so past invoices stay available.
• Sign out everywhere, in Account, ends every session of your account at once.

Keep sensitive data outCopy Anchor Link

• Turn off storeInput — and storeOutput if answers are sensitive too — on decisions that receive personal data. See Decision settings.
• Send only what the decision needs: undeclared fields are forwarded to the engine. It also makes answers more accurate — see Writing good questions.
• Keep personal data out of instructions, options and context: they are part of the schema, stored with every version and sent with every call.
• Replace direct identifiers (names, e-mails, document numbers) with your own IDs when they don't change the answer.
• Shorten Execution log retention in Settings.
• Map into destination params only what each receiver needs: destination entries — function params included — are kept with the execution even when storeInput and storeOutput are off.

Access controlCopy Anchor Link

• Workspace isolation. Every query is scoped to a workspace. An API key resolves exactly one workspace and can only run that workspace's decisions — anything else is 404 DECISION_NOT_FOUND — and only list that workspace's executions.
• Inputs stay in the app. GET /v1/executions returns answers, actions and metrics but never the stored state: inputs, which may hold personal data, are only shown to workspace members in the app.
• Keys and sessions are separate. API keys only work on the public API (/v1); the app's endpoints refuse them with 403 FORBIDDEN, and a session token is not accepted on /v1.
• Sign-in. Google, a 6-digit e-mail code, or an optional password: at least 10 characters with letters and numbers, never your e-mail or a common password, stored as a scrypt hash. Wrong passwords lock sign-in with a password for 15 minutes after 5 attempts, and the answer is the same for an unknown e-mail. Setting or changing a password sends you an e-mail, and changing it ends your other sessions.
• Sessions. A signed token in an httpOnly cookie, never exposed to the browser's JavaScript, valid 30 days. Sign out everywhere revokes them all.
• Roles. Every member is an Owner, Admin, Member or Viewer. Viewers read; Members build, deploy and run decisions, API keys and destinations; Admins also manage people, settings, provider keys and secrets; only the Owner manages billing, transfers ownership and deletes the workspace. Refusals answer 403 FORBIDDEN. See Team, roles and account.
• Workspace access. Every app request is checked against your membership of the workspace; a workspace you don't belong to answers 403 FORBIDDEN with details.reason = "workspace_access".

Secure integration checklistCopy Anchor Link

• Call the API from your backend over HTTPS; never expose an API key in a browser, a mobile app or a repository.
• Use one key per service and revoke keys you no longer use. Use test keys for staging and CI.
• Send an Idempotency-Key so retries can't duplicate a decision — see Idempotency.
• Log execution_id and X-Request-ID instead of the state when you need to trace a decision.
• Verify Dcision-Signature on every webhook, workflow, agent and API request you receive from Dcision, reject old timestamps and deduplicate on the delivery ID — see Webhooks.
• Keep tokens and secret URLs in workspace secrets and reference them as {{secrets.NAME}} — never type them into a destination's URL, headers or body.
• Keep livemode: false events — test keys and the Playground — out of production systems.

Responsible useCopy Anchor Link

Dcision returns probabilities, not certainties. For consequential decisions about people — credit, employment, housing, healthcare, legal matters — use it to triage and route, keep a person in the loop (for example with escalate), and review outcomes regularly.

LegalCopy Anchor Link

• Privacy Policy
• Terms of Service