Governance

Governance covers the rules that platform teams set once and that apply to everything built in Studio: who can build and deploy, which identities workloads run as, where credentials live, how data is handled, what models may say, how much teams can spend, and who did what.

Most of these rules live in the Admin Panel, and the Admin documentation is the reference for each of them. This page maps them to the Studio features they govern. Builders don't need to set any of this up to start building.

Everything in Studio belongs to a workspace: API keys, agents, workflows, deployments, secrets, usage, limits, and observability data. Switching workspace in Studio switches all of them. Use separate workspaces to isolate teams or environments, such as development, staging, and production.

When workspaces don't isolate enough, Enterprise accounts group several organizations.

• Workspaces in Studio: what changes for Studio users, and what admins configure per workspace.
• Create your first workspace
• Enterprise accounts

Access follows predefined roles at two independent scopes: the organization and each workspace. Permissions are additive: a user gets everything their roles grant. For Studio, the workspace roles that matter most are:

To manage access at scale, assign roles to groups rather than to individual users, and sign members in with your identity provider.

• Roles and permissions: every organization and workspace role, and what it grants.
• Groups and user management
• SAML SSO (Enterprise) and domain verification

Run production workloads, such as workflow workers, under a service account rather than a person's API key. The workload keeps working when that person's key is rotated or when they leave, and audit logs name the workload. In your own Kubernetes cluster, workload identity federation lets the worker authenticate with short-lived tokens instead of a stored key.

API keys belong to a workspace and use its quota, rate limits, and resources. An expiration policy caps how long new keys stay valid, and each key's connector access scope decides whether it can use private connectors.

• Service accounts
• Workload identity federation
• API keys, including the connector access scope
• API key expiration policy

Secrets Manager stores the credentials that managed deployments read at runtime. Secrets are scoped to a workspace: every member sees their names, and creating, editing, or deleting them requires the Developer role or a role that includes it. Secret values are write-only.

Organization admins connect shared apps once in the Admin Panel and decide which connector tools members can use in Studio and Vibe.

• Secrets Manager
• Connectors in Admin, and Connectors for the developer side

A hardened deployment restricts which users and service accounts can register workflows on it, so no one can replace a production workflow by accident. Hardening is required for on-behalf-of workflows, which act as the user who triggers them. Managed deployments created in Studio are hardened by default, with an opt-out at creation.

• Hardened deployments
• Deployments: access control

With zero data retention (ZDR), Mistral doesn't store the inputs and outputs of supported stateless API requests. ZDR doesn't cover stateful products, such as agents, conversations, libraries, files, and batch processing files, because they must store data to work. ZDR is separate from opting out of model training.

Traces sent to observability are redacted on the client before export, by default, and are kept for 30 days. Reading them requires an Enterprise organization and a role with observability access.

• Zero data retention, including how ZDR differs from training opt-out
• Data redaction and Observability

Guardrails check what goes in and out of a model. Declare moderation rules in chat completion and conversation requests, or in an agent's configuration. For custom pipelines, the moderation API returns raw scores per policy category.

• Moderation and guardrails

Each workspace tracks its own consumption. Set a monthly spending limit per workspace to cap a team or an environment, and use the organization usage dashboard to see where spend comes from. Rate limits apply per workspace.

• Workspace usage and limits
• Usage and limits for the organization

Audit logs record who did what, and when, across Studio and Vibe: sign-ins, API key creation and deletion, and actions on resources, whether a user, an API key, or the system performed them. Audit logs are available on Enterprise plans and enabled by default for all workspaces.

To automate administration, the Admin API (Enterprise) manages users, groups, workspaces, API keys, and limits, and retrieves usage and audit logs.

• Audit logs and the event reference
• Admin API