Treasure AI Studio runs AI agents that read your customer data, execute queries, and call external services on your behalf — so the boundaries around those agents are the product's security story. This page explains the boundaries Treasure AI operates: where agent code runs, how your data is encrypted, which geography processes your prompts, why your credentials never reach the agent, and which controls an account administrator holds. Read it before rolling Studio out to a team, and use it to answer the governance questions your security reviewers will ask.
Every chat's agent runs server-side in its own isolated sandbox. It has no access to your local computer, no access to other users' chats or files, and no access to your real credentials — the platform substitutes those at the network boundary. All outbound traffic is recorded in the Network Audit Log, and traffic leaving the sandbox is filtered by an account-level network policy — with one connector exception, described in External Service Connections.
Understand the security boundaries that protect your data in Treasure AI Studio — platform architecture, encryption, LLM data handling and residency, sandbox and credential isolation, per-user data isolation, and the administrator controls and customer responsibilities that complete the picture.
- Signed in to Treasure AI Studio (Getting Started)
- The account administrator role to reach the controls under Settings → Organization (network policy, audit log, data retention, credit policy, connector settings)
Treasure AI Studio is a multi-tenant AI agent platform hosted on AWS. Three architectural facts shape everything else on this page:
- Multi-tenant with logical isolation. Each organization's data is logically isolated from every other tenant's.
- Agents reach your data through APIs, not your data stores. Studio calls Treasure Data CDP and other services through their APIs; it holds no direct connection to your underlying warehouses or storage.
- All execution is server-side. Every command, query, and file operation an agent performs runs in Treasure AI's infrastructure. Nothing executes on your computer, phone, or in your browser — including on Desktop, where the app is a shell around the same server-side execution.
Treasure AI Studio encrypts all data in transit and at rest.
| Protection | Details |
|---|---|
| In transit | TLS 1.2 or higher for all connections. |
| At rest | AWS-managed encryption keys. |
| Connector credentials | OAuth access and refresh tokens for Connections are additionally encrypted at the application layer before storage, and are scoped to the individual user who authorized them. |
Treasure AI Studio runs LLM inference on Amazon Bedrock, under two guarantees that matter for a data protection review.
| Protection | Details |
|---|---|
| No model training | Amazon Bedrock does not use customer data to train or improve foundation models. Your prompts, queries, and data never become training data. |
| Zero data retention by the model provider | Amazon Bedrock does not retain prompts or responses after an inference request completes. The LLM provider stores none of your data. |
Prompts reach Bedrock through Treasure AI's own inference proxy rather than through any model vendor's public API — the agent's API base URL is overridden to point at that proxy — and the agent runtime's non-essential traffic, such as telemetry and error reporting, is disabled.
Zero retention applies to the LLM provider, not to Studio itself. Your conversations, and the files agents produce, are stored so you can return to them — governed by your organization's Chat Data Retention setting.
Treasure AI Studio processes LLM inference inside a fixed geographic boundary determined by your account's region. The region you sign in to selects both the AWS region that hosts your Studio data and the geography that may process your prompts.
| Account Region | Primary AWS Region | Inference Geography |
|---|---|---|
| US01 (United States) | us-east-1 (N. Virginia) | US regions |
| AP01 (Japan) | ap-northeast-1 (Tokyo) | Japan regions |
| EU01 (Europe) | eu-central-1 (Frankfurt) | Europe regions |
| AP02 (Korea) | ap-northeast-2 (Seoul) | Asia Pacific regions |
Treasure AI Studio uses Amazon Bedrock cross-region inference to absorb traffic bursts, which means a request can be served by a different AWS region than the one it originated in. Every region uses a regional inference profile, whose list of destination regions is fixed, so prompts and model responses never leave the geography in the table above. Traffic between regions travels the AWS private network, encrypted in transit.
Each chat's agent runs inside its own sandbox on Treasure AI's infrastructure. The sandbox is a virtual machine with hardware-level isolation, not a shared container, and it is created and destroyed with the chat session.
| Boundary | What It Means |
|---|---|
| No access to your device | The agent cannot read or write files on your computer or phone. Uploads and downloads move deliberately between your device and the managed sandbox — see File Upload & Download. |
| One sandbox per chat | Sessions do not share a sandbox, so one chat's processes and working files are not visible to another. A work folder is shared storage attached to each of those sandboxes rather than state held inside one, so every chat reads and writes the same work folder files — all of your work folders, not just the chat's own (Working Across Work Folders) — see What Persists After a Chat Ends. |
| A clean environment for every chat | Each chat starts from the same base image. Packages the agent installs and the working files it writes outside your work folders belong to that chat alone and never carry into the next one — see What Persists After a Chat Ends. |
| Unprivileged execution | The agent process runs as an unprivileged user under a restricted system-call filter, so a misbehaving command cannot escalate inside the sandbox. |
| All egress is filtered and logged | Outbound traffic leaves only through the platform's network boundary, where the Network Audit Log records it and the network policy allows or blocks it — except for a connector whose requests are made outside the sandbox, which is recorded but not policy-filtered (see External Service Connections). |
If a sandbox terminates unexpectedly, Studio shows: "The sandbox environment crashed unexpectedly and is restarting. Please wait a moment and try again."
In Treasure AI Studio, the files an agent produces for you land in one of two places, and only one of them outlives the conversation.
| Where the Agent Wrote It | Lifetime |
|---|---|
| Inside a work folder | Persistent. Reports, datasets, images, the work folder's CLAUDE.md, and any skills under .claude/skills/ belong to the work folder rather than to a chat, so every chat sees them — not only chats saved in that folder — and they remain after those chats are gone. See Chat Data Retention. |
| Anywhere else in the environment | Scoped to the single chat that wrote it. The agent's working files, temporary directories, and the packages it installed are private to that chat, unreadable from any other chat, and never outlive it — they are gone at the latest when the chat is deleted or passes the retention period. |
Two consequences are worth stating plainly.
The data an agent pulls in does not outlive the chat. An API response, an exported dataset, or a scratch copy of customer records left outside the work folder is not sitting in a directory the file browser never shows — it goes when the chat goes. What remains of the work is what you can see and delete yourself.
Each chat starts from the same known state. Previously a chat inherited whatever earlier conversations had installed or reconfigured — state that no screen in Studio displayed, so when two chats answered the same question differently, there was no way to see what differed. Setting up an environment on purpose still works — the agent redoes the setup in each chat, from instructions you can see and edit: the files in the work folder, its CLAUDE.md, and organization-wide Custom Instructions.
The practical rule follows from the table: if you want to keep something, keep it in a work folder. Ask the agent to write it there, move it there from the work folder page, or download it before the chat expires. Files that used to accumulate in the agent's home directory were moved into your work folders when this behavior took effect — see The MIGRATED_HOME Folder.
Treasure AI Studio never places a real credential inside the agent's sandbox. The sandbox holds a placeholder token; when the agent makes a request to a connected service, the platform substitutes the real access token at the network boundary, outside the sandbox.
This holds for Treasure Data CDP itself. When the agent runs a tdx command, tdx reads a placeholder token from a read-only file in the sandbox and sends it. The platform swaps in your real Treasure AI access token as the request leaves, refreshing it as needed. The same substitution covers every connector — Databricks, Snowflake, and GitHub included.
The consequence is worth stating plainly: an agent cannot leak a credential it never had. No prompt, no generated script, and no custom skill can read your access tokens out of the sandbox, because they are not there. In the Network Audit Log, these substituted requests appear with the rewrite action.
Chats and files in Treasure AI Studio are isolated per user. Account administrators hold organization-wide policy controls, but that role does not grant access to other users' chats or files — there is no administrative view of another user's conversations. Files are scoped per user, and within a user's space per chat or per work folder. See Work Folders for how a chat reaches your work folders.
Treasure AI Studio agents reach external services through connections: an administrator enables a connector for the organization, and each user authorizes their own connection to it via OAuth 2.0. Users can revoke a connection at any time from Settings → Connections, and administrators can disable or delete a connector for everyone. The full workflow, the available connectors, and the credential-substitution behavior are documented in Connections.
Two security properties are worth carrying over here. The agent handles no raw service passwords. And where a connector's requests come from the agent's sandbox — Databricks, Snowflake, GitHub, and Treasure Data CDP — they are subject to your network policy, so the agent cannot reach a host your policy blocks.
One connector works differently and the exception matters when you plan controls: Treasure AI Voice requests are made by Treasure AI's connector service, outside the sandbox. They are recorded in the Network Audit Log like any other outbound request, but the network policy is not applied to them, so a Block rule for that host does not stop them. Control that connector at the connector itself — disable or delete it in Connector Settings — rather than in the network policy.
Treasure AI Studio gives account administrators five organization-wide controls, each on its own page under Settings → Organization.
| Control | What It Governs |
|---|---|
| Network Policy | Which external domains agents may reach. Ordered allow/block rules plus a default action. |
| Network Audit Log | The record of outbound agent connections, by domain, user, chat, and outcome. |
| Chat Data Retention | How long chat history is kept before automatic deletion (14, 28, or 60 days). |
| Credit Policy | The per-user daily credit ceiling and the timezone its reset follows. |
| Plugin Marketplace policy | Whether users may register their own skill marketplaces, or only administrators may. |
Access to the data itself is not one of these controls. Each connected system enforces its own permissions, and Studio passes your authorization through rather than layering anything on top — so an agent sees exactly what you see in that system, and nothing more. For Treasure Data CDP that means your Policy-Based Permissions and IP allowlist; for every other connector it means whatever the vendor's own permission model grants the account each user authorized. See Access Control.
Treasure AI Studio generates queries, segment rules, journey definitions, configurations, and recommendations. Treat all of it as a draft:
- It may be incorrect or incomplete. Review generated SQL, segment rules, and configurations before they touch production.
- Validate it with the tools built for that. Ask the agent to check query performance with the
sql-skills:trino-optimizerskill, to validate segment definitions withtdx sg validate, and to validate journeys withtdx journey validate. - Ask the agent to confirm before it acts. A confirmation step is something you request rather than a dialog Studio imposes, so make it explicit: "show me what you'll change before you push it" in your message, or the same rule in Custom Instructions or a work folder's instructions so it applies to every conversation without repeating it. For changes where a mistake would be expensive, back that up with account permissions rather than relying on the agent to ask.
Stop response ends the rest of the turn, which is useful when an agent starts down a path you did not intend. It is not an undo and not an instant halt: tool calls already shown in the chat have run, and an operation already in flight may still complete. Use it to prevent the work that would follow, and treat permissions as the boundary for anything that must not happen at all.
- Set the network policy before the rollout, not after. Start from the default deny-with-baseline rule set, add only the hosts your skills and connectors need, and record why in each rule's comment. See Network Policy.
- Write the rules into instructions, not into an onboarding doc. Organization-wide Custom Instructions and work folder instructions ("always validate before pushing", "never modify production segments directly") reach every conversation automatically, while a rule that lives only in a team wiki depends on each person remembering it. Instructions steer an agent rather than stop it, so keep them for conventions and use the network policy and account permissions for boundaries that must hold.
- Restrict marketplaces if unvetted skills are a concern. Setting the plugin policy to admin only keeps third-party skills out of your environment until an administrator reviews them. See Plugin Marketplace.
- Review the audit log on a schedule. Filter the Network Audit Log by time range and domain periodically, and remember its roughly four-week retention when planning a compliance cadence.
- Match retention to your data policy. Choose the chat retention period deliberately — it applies to every user at once.
- Read the tool calls, and know what they are. Every command an agent runs appears in the chat stream, and expanding a tool call shows the exact command and its result. It is a record of what already ran rather than a request to approve it, so watch the stream to catch a wrong turn early — and use Stop response to cut the rest of the turn short, keeping in mind it does not undo what has already happened.
- Ask for a confirmation step when you want one. An agent will pause and check with you if you tell it to — "explain the change and wait for my OK before pushing". Put a rule you want every time into the work folder's instructions instead of repeating it in each message.
- Ask for validation when it matters.
validate-segmentandvalidate-journeycatch configuration mistakes before they reach your account, but they cover segments and journeys only, and the agent runs them when something tells it to. "Validate before pushing" in your message or in the folder's instructions is what triggers them. - Do risky work where a mistake is cheap. If a change would be painful to undo, run it against a development account or a copy first. Studio has no undo.
- Keep only the connections you use. Authorize the services you actively need and remove the rest from Settings → Connections.
- Never paste a secret into a chat. Credentials belong in a connector's OAuth flow, which keeps them out of the conversation and out of the sandbox.
Treasure AI operates the platform boundaries described on this page. You are responsible for:
- Reviewing and validating AI-generated output before deploying it
- Keeping secrets, passwords, and access tokens out of chat messages
- Configuring the administrator controls above to match your organization's policy
- Reporting security concerns to security@treasure-data.com
Penetration testing, vulnerability scanning, and other security assessments of Treasure AI Studio require Treasure AI's prior written consent.
No. Treasure AI Studio runs inference on Amazon Bedrock, which does not use customer data to train or improve foundation models, and does not retain prompts or responses after a request completes. Studio retains your chat history separately, under your organization's Chat Data Retention setting.
No. Every Treasure AI Studio agent runs server-side in an isolated sandbox with no access to your device's filesystem — on Desktop as well as Web and Mobile. Files move between your device and the sandbox only through explicit upload and download.
No. Chats and files in Treasure AI Studio are isolated per user. The account administrator role grants organization-wide policy controls — network policy, audit log, retention, credit limits — but no access to another user's conversations or files.
Inside the geography tied to your account region: US regions for US01, Japan regions for AP01, Europe regions for EU01, and Asia Pacific regions for AP02. Each uses a regional Amazon Bedrock inference profile, whose destination regions are fixed, so prompts never leave the stated geography.
No. The agent's sandbox holds only a placeholder token. Treasure AI Studio substitutes the real access token at the network boundary, outside the sandbox, so no prompt or generated script can read your credentials.
Ask it to. A Treasure AI Studio agent carrying out your request will act on its own unless something tells it to pause, so make the checkpoint explicit — "explain the change and wait for my OK before pushing" in your message, or the same rule in Custom Instructions or a work folder's instructions so it applies to every conversation. Instructions steer the agent reliably but are not an enforced gate, so for changes that must never happen, use account permissions as the boundary instead.
Add a Block rule for its domain in the network policy, placed above any broader Allow rule that would match first. Enforcement is server-side, so the agent cannot override it.
- (Admins) The Network Policy page under Settings → Organization shows the rule set you expect
- (Admins) The Network Audit Log returns records for recent agent activity
- (Admins) The Data Retention period matches your organization's data policy
- The Environment value on Settings → Profile (for example,
production-us01) matches the region whose inference geography your compliance requirement assumes
| Issue | Solution |
|---|---|
| "The sandbox environment crashed unexpectedly and is restarting" | Wait a moment and resend your message. If it recurs, start a new chat — the operation may have exceeded the sandbox's resource limits. |
| An agent operation cannot reach an external service | Your network policy likely blocks the host. Confirm in the Network Audit Log, then allow it in the network policy. |
| The Organization section is missing from Settings | Those controls require the account administrator role. Confirm your role with your organization administrator. |
| A query fails with a permission error | Studio passes your own credentials through, so the agent sees exactly the permissions you have. See Access Control. |
- Network Policy — Control which external domains agents may reach
- Network Audit Log — Review outbound agent connections
- Access Control — Permissions, IP allowlists, and per-user Studio access
- Chat Data Retention — Retention periods and the data lifecycle
- SSO Login — Authentication, regions, and session handling
- Connections — Connectors, OAuth authorization, and credential substitution