Shared responsibility model for security in Cloudera AI in Agent Studio
Cloudera AI Agent Studio runs within the Cloudera AI Workbench. Security responsibilities are shared between Cloudera as the platform and product vendor and you as the customer deploying and operating Agent Studio.
Default Cloudera security
When you deploy Cloudera AI Agent Studio with default configuration on
a supported Cloudera AI Workbench version, the following controls are enabled
by
default:
- Authenticated access - Requires a valid Cloudera AI Workbench session for all routes.
- Deny-by-default Role-Based Access Control (RBAC) - Restricts all API routes and UI features to explicit permissions, returning a 404 error for unauthorized access.
- Tool sandboxing - Isolates all user-authored tool code and Model Context Protocol (MCP) subprocess runs within a Linux namespace (bubblewrap), preventing arbitrary filesystem access.
- Kubernetes network isolation - Blocks traffic between user namespaces using network policies.
- HTTPS for external calls - Enforces TLS with certificate validation for all Large Language Model (LLM) provider and external tool API calls.
- Workflow run tracing - Captures and tags run traces with user identity tags wiythin the Phoenix server.
- Audit logging - Logs all CRUD operations on all Agent Studio entities with user attribution.
Responsibilities of the user
The following security controls require active decisions or configuration from you as an
Administrator:
Project membership management
- The key security decision is determining who has Contributor access to an Agent Studio project. Contributors have the following capanilities:- Read all project environment variables, including LLM API keys.
- Modify workflow configurations, agent definitions, tool code, and MCP server registrations.
- Write to the shared project filesystem, including the Agent Studio configuration database.
Model Context Protocol server and external tool governance
- Agent Studio does not enforce a product-level allowlist of approved external Model Context Protocol (MCP) servers or tool endpoints. Any MCP server registered by a Contributor can make outbound network connections. Cloudera recommends taking the following actions:- Maintain an internal policy that lists approved MCP servers and external tool endpoints.
- Require security review before any new MCP server is connected.
- Consider deploying a network proxy and routing MCP and tool subprocess traffic through it to enforce egress allowlisting.
LLM token and cost control
- Agent Studio has no in-product per-user token limits. A single user or workflow can exhaust your LLM API quota. Cloudera recommends taking the following actions:- Setting budget limits, rate limits, and per-key usage quotas at your LLM provider account level.
- Consider deploying LiteLLM or a similar token gateway as a proxy to enforce per-user quotas within your environment.
Secrets hygiene
- LLM API keys and integration credentials are stored in the Cloudera AI Workbench project environment variables, which are accessible to all Contributor-level users on the project. Cloudera recommends taking the following actions:- Use unique API keys per workflow or integration if your LLM or tool provider supports it. This enables you to revoke a specific key without affecting all workflows and to attribute API usage to specific integrations.
- Rotate API keys periodically and immediately when a Contributor leaves the project.
- Do not store passwords, private keys, or human-user credentials in project environment variables. Use service account credentials scoped to Agent Studio's required permissions only.
Infrastructure hardening
- Agent Studio inherits its infrastructure security from your Cloudera AI Workbench on premises deployment. Cloudera recommends ensuring that your on premises deployment follows the Cloudera's security hardening guidance.Using service account
– Agent Studio utilizes the Service Account feature to deploy production or shared workflows, using a dedicated Service Account instead of a user's account. This allows for fine-grained permissions, limiting the access of the deployed agentic workflow. When a workflow such as a model and an application, is deployed, it runs within the Service Account's namespace. A user who creates an application in Agent Studio can choose to deploy the workflow using a Service Account, if they are a Project Administrator or Site Administrator, and the Service Account has already been added as an administrator of the project. For more information, see For more information, seeService account usage
