Access control in Treasure AI Studio splits across two layers, and knowing which layer owns a question is the fastest way to answer it. What data an agent can read is decided outside Studio, by whichever system holds that data — it applies its own permissions to every request the agent makes, unchanged. What an agent is allowed to do is decided inside Studio: which external domains it may reach, which skills it may load, how many credits a user may spend. This page maps both layers so an administrator can see, in one place, where each control is enforced and what action it requires.
Treasure AI Studio executes every data operation with your own authorization. If your permissions deny you a database, the agent receives the same denial. Studio adds controls over agent behavior; it adds no way to see data you could not already see.
Identify which access-control layer governs each Treasure AI Studio behavior, and what an administrator must configure in each.
- A Treasure AI account
- Familiarity with the Security Overview
- The account administrator role for the Studio-side controls, and Control Panel access for the Treasure AI-side controls
Treasure AI Studio introduces no permissions layer of its own for data. Every request an agent makes goes to the target system as you, and that system's permissions decide what succeeds. Nothing needs configuring in Studio for this layer — the access each user already has is the access their agent gets.
Which permission model applies depends on where the data lives:
- Treasure Data CDP — your organization's Policy-Based Permissions and IP allowlist, covered in the rest of this section. This is the layer most Studio work touches.
- Any other connector — the vendor's own permission model, applied to the account each user authorized through OAuth. Scoping an agent's reach in one of these systems is done there, not in Studio: grant the authorizing account only the access it should have.
Every query, segment push, and CDP API call an agent executes goes to Treasure AI as you, and your organization's Policy-Based Permissions decide what succeeds. Existing policies apply automatically — there is nothing to configure in Studio.
To keep PII out of the prompts sent to LLM providers, configure column-level masking at the data layer. Masking is applied where the query runs, so the agent receives an already-masked result — there is nothing for Studio, a skill, or a prompt to bypass, because the unmasked value never leaves the CDP. See Configure column-level access control to keep PII out of LLMs.
If your organization restricts Treasure AI API access to approved networks, Treasure AI Studio's agent workers must be on that allowlist or their queries will be rejected. Studio calls the Treasure AI API from a fixed set of outbound IP addresses per region — static addresses that do not change between sessions or deployments.
Add the addresses for your region to your Treasure AI IP allowlist configuration.
34.199.15.172
100.51.233.143
54.175.7.102Outbound addresses are per region and can change as capacity is added. Ask your Customer Success Manager to confirm the current list for your region before you configure an allowlist — an incomplete allowlist fails as a rejected query at query time, not as a warning when you save it.
Treasure AI Studio does not restrict inbound access by IP address. Once you authenticate, you can open the Studio web application from any network. Network-based restrictions on signing in come from your identity provider, not from Studio — see SSO Login.
| Scenario | Studio UI | Data Operations (Queries, API Calls) |
|---|---|---|
| You stay on the same allowed network | Works normally | Works normally |
| You move to a network your organization does not allow, after signing in | Works normally — the Studio UI is not IP-restricted | Works normally — agent workers use fixed outbound addresses, not your client IP |
| You try to sign in from a network your identity provider blocks | Sign-in fails | Not applicable — no session is established |
Your own network matters at sign-in, where your identity provider decides which networks may start one. It does not matter afterwards: an agent's queries leave from Studio's fixed outbound addresses, never from your laptop, and Studio does not look at your IP again once you are signed in. That is why moving to another network mid-session does not break your queries — and why adding your office to the allowlist does not help an agent whose Studio addresses are missing from it.
These controls do not change what data you can reach. They constrain what an agent may do with the access you already have, and each requires an account administrator to configure it.
| Control | What It Governs | Default |
|---|---|---|
| Network Policy | Which external domains agents may reach | Deny-by-default, with a seeded allowlist for Treasure AI, GitHub, and package registries |
| Plugin Marketplace policy | Whether users may register their own skill marketplaces | Open — any user may register a marketplace |
| Connector Settings | Which external services users may authorize a connection to | No connectors beyond Treasure Data CDP until an administrator adds them |
| Credit Policy | The per-user daily credit ceiling | Unlimited |
| Custom Instructions | Organization-wide guidance applied to every conversation | None set |
Custom Instructions steer an agent; a network policy stops it. Use instructions for conventions you want followed ("always validate before pushing") and the network policy or connector settings for boundaries that must hold even if a prompt asks otherwise.
By default, every user with a valid Treasure AI account has full access to Treasure AI Studio and to all of its AI features. There are no per-feature toggles inside Studio — a user who can open Studio can use every capability in it. Access is controlled at two coarser levels instead.
| Control | Current Behavior |
|---|---|
| Per-user Studio access | Off by default: every user has access. Once restricted (opt-in) mode is enabled for the account, administrators grant Studio access to specific users — see Controlling AI Studio access per user. Contact your Customer Success Manager to enable restricted mode. |
| Per-user usage limits | Administrators can cap each user's daily credit consumption — see Credit Policy. |
| Per-feature restrictions within Studio | None. Users who can access Studio have every feature available. |
| Admin-only features | Network Policy, Network Audit Log, Data Retention, Credit Policy, Credit Usage, Connector Settings, and organization Marketplace require the account administrator role. |
| Per-account opt-out | Available — contact your Customer Success Manager to disable Studio for the whole account. |
| Layer | What It Controls | Where It Is Enforced | Action Required |
|---|---|---|---|
| Policy-Based Permissions | Database, table, and API access per user or group in Treasure Data CDP | Treasure AI API (server-side) | None — existing policies apply automatically |
| Connected system permissions | What an agent can read or change in any other connected service | That service (server-side) | None in Studio — scope the account each user authorizes on the vendor's side |
| Treasure AI IP Allowlist | Which addresses may call the Treasure AI API | Treasure AI API (server-side) | Add Studio's outbound addresses if you run an allowlist |
| Studio inbound access | Which networks may open the Studio app | Not enforced by Studio; sign-in networks are governed by your identity provider | None |
| Network Policy | Which external domains agents may reach | Treasure AI Studio | Administrator configures rules and the default action |
| Plugin Marketplace policy | Whether users may add their own skill marketplaces | Treasure AI Studio | Administrator sets the policy to open or admin only |
| Connector Settings | Which external services users may connect to | Treasure AI Studio | Administrator configures and enables each connector |
| Credit Policy | Credits a user may consume per day | Treasure AI Studio | Administrator sets a daily limit |
| Per-user Studio access | Whether a user may open Studio at all | Treasure AI (server-side) | Ask your Customer Success Manager to enable restricted mode, then grant access per user |
| Account opt-out | Studio for the entire account | Treasure AI account settings | Contact your Customer Success Manager |
- Run a query in a chat against a database your Treasure Data CDP permissions deny, and confirm the agent reports the same denial you would see in the console
- (Admins) Confirm the Network Policy rule set and the Plugin Marketplace policy match your organization's intent
- (Admins) Confirm Studio's outbound addresses are present in your Treasure AI IP allowlist, if you run one
| Issue | Solution |
|---|---|
| Queries fail after your organization enabled an IP allowlist | Studio's outbound addresses are probably missing from the allowlist. Ask your Customer Success Manager for the current addresses for your region and add them. |
| Sign-in fails from a specific network | Your identity provider may enforce network-based policy. Sign in from an approved network, or ask your IT administrator to update the policy. |
| An agent operation fails but the data permissions are correct | The failure is probably the other layer. Check the Network Audit Log for a block against the destination host, then adjust the network policy. |
| A user cannot open Studio at all | Your account may be in restricted mode without that user granted. See Controlling AI Studio access per user. |
- Security Overview — Sandbox isolation, encryption, and data residency
- Network Policy — Configure which domains agents may reach
- SSO Login — Authentication flow, regions, and sessions
- Credit Policy — Per-user daily credit limits