Data protection and isolation
DIAL governs requests routed through Core. Data protection also depends on the model providers, applications, tools, and infrastructure you connect. This page helps identify those boundaries; read Authentication and access control first.
Follow identity to the external system
Authorization at the gateway and authorization in a downstream system are separate decisions. The diagram follows a user request into an application and an MCP tool call. It omits model and storage calls to keep the transition between platform identity and external credentials visible.
Core checks platform access. Per-request keys carry caller context for delegated calls; application consent covers configured sensitive dependencies. External-system permissions depend on the credentials used there. A Toolset's authentication and credential level, including GLOBAL, APP, or USER, determines which credentials it uses. The diagram shows this credential boundary; it does not imply every Toolset uses a shared credential.
For example, Core can allow a user to invoke a document-search Toolset while the server uses a shared corporate account. The external system then sees that account's permissions, not automatically the user's individual permissions. The Toolset's authentication choice must therefore match the intended access model.
Distinguish the controls
| Control | What it establishes |
|---|---|
| Roles and resource permissions | Who can use or manage a DIAL resource |
| Configured interceptors | Inspection/transformation on the supported model/application paths; verify API and release coverage |
| Runtime isolation | Boundaries for executable code, files, and sessions in the selected runtime |
| Network policies and outbound restrictions | Which services and destinations a workload can reach |
| TLS, storage encryption, and secret management | Protection of connections, stored content, and credentials |
These controls compose: an application may need resource permission to receive a file, runtime permission to read it, and an allowed network destination to send it elsewhere. Passing one check does not grant the others.
Private-space ownership is a default, not an assurance that only the owner can ever read a resource. Sharing and delegated application access, request-attached files, and configured global readers extend access under their respective rules. Include those grants in a security review.
MCP and HTTP routes are separate from the model/application interceptor chain. A container or a resource ACL alone does not establish isolation between mutually untrusted tenants. Validate the combined runtime, identity, store, and network boundaries for that use case.
Protect data and its copies
Core's bucket-addressing encryption settings are separate from file-content encryption and Toolset credential encryption. The Toolset KMS provider defaults to unencrypted; select and configure a managed KMS for production. Configure the storage service, key management, and transport protection for your deployment.
Treat prompts, tool results, request logs, traces, analytics, evaluation datasets, indexes, and backups according to their sensitivity. Define redaction and retention for each destination; self-hosting Core does not prevent an approved external model or tool from processing data.
Further reading
- State and data lifecycle — persistence, deletion, and recovery boundaries
- Security hardening — configure deployment controls
- Toolset security settings — credential encryption
- DIAL Core settings: Encryption — the AES settings Core uses for bucket prefixes
- Per-request keys — short-lived keys Core issues to applications for a single request
- Auth matrix for apps — how Core enforces user consent across application call chains