Skip to content
See where data goes during a Task
Public Preview

Security: data flow, controls, and production review limits

Maps data flow during a Duale AI Task, six security decision points, and four production review limits.

This page maps data flow during a Task, six security decision points, and four production limits for Duale AI.

  • Data flow paths during a Task.
  • Six security decision points covering identity, reach, and acceptance.
  • Production limits for prompt injection, approval, and tenant boundaries.

Summaries were generated by AI.

Duale AI runs each Task. You decide what each Agent Identity can reach, which SDK and MCP Tools its Tasks can use, which external actions your systems authorize, and what your application does with a result. Use this page to place each security concern with the page that owns its control.

See where data goes during a Task

Where data goes during a TaskYour SDK host and the Dashboard in a browser exchange requests with Duale AI over HTTPS with added end-to-end encryption. Document files go over HTTPS to a temporary upload area, and Duale AI then stores them. Duale AI stores documents, Task history, and records. During a Task, Duale AI sends model input to the model providers you configure, reads the public web and package registries, sends Tool requests to your MCP servers with the Connection credential, and sends Tool requests to your SDK Tool Host over the stream your host opened. Your SDK sends telemetry only to the collector you configure.

Data protection lists each path, each stored copy, and the copies that outlive a delete. The decision points below name the owner of each control.

Follow the six decision points

  1. Identity. Each protected Tenant request carries a platform token. Duale AI resolves the Tenant and the acting identity from that token, and the request body cannot override either. An SDK process gets its platform token with its Agent Identity API token; a person gets one by signing in. Identity explains the principal model.
  2. Transit and storage. Task traffic, documents, and Task Results cross different protected paths. End-to-end encryption explains the protection between your client and Duale AI. Data protection maps every path and stored copy.
  3. Reach. The access of the Agent Identity and the Tools available to the Task decide which sources a Task can use: Libraries, the public web, Tools, and earlier Tasks of the same Agent Identity. Threat model covers content you do not control.
  4. External Tools. Your SDK Tool Host and your remote MCP servers receive Tool requests through different boundaries. A Tool that a Task can use does not authorize an External Effect. Secure integration shows where your controls run.
  5. Acceptance. Your application checks a completed Task Result against its domain rules before it uses it. A schema-valid result is well-formed, not necessarily correct.
  6. Records. Evidence and audit states what Duale AI records and what those records cannot show.

Shared responsibility sets out the same split as a table you can take into a review.

Keep four limits in the production review

Prompt injection remains possible

Documents, web pages, Tool definitions, Tool Results, and earlier Tasks can contain instructions written by someone else. Duale AI does not identify and remove those instructions as a security control. Threat model shows where to add deterministic checks.

Approval stays outside an MCP Connection

An MCP Connection provides only Allow calls or Block calls. It cannot pause one Tool request for approval. When a person must decide, use a separate process that you control, or an SDK Tool that records a proposal before any External Effect. Secure integration shows this pattern.

Later Tasks of an Agent Identity can read its earlier Tasks

A Task can read the requests and final answers of earlier Tasks of the same Agent Identity, so use one Agent Identity for each end user or trust boundary when Tasks must not see each other’s work. What a Task can recall from earlier Tasks owns this capability.

A Tenant is a logical boundary

It separates authorization, configuration, records, and cost. It does not provide a separate model-provider account or credential, storage, compute, or region. Architecture patterns explains when a separate boundary is required.

For permitted use, read scope and limits. For binding commitments, read the legal documents. For controls, hosting choices, review material, and security or privacy contacts, use the Trust Center.