Controlling what a model serving endpoint is allowed to access

Model serving endpoints run inference code that often needs to call other resources (Unity Catalog tables/functions, vector search indexes, external APIs, MLflow artifacts) on behalf of the deployed model, so Databricks provides mechanisms to securely pass credentials to the endpoint without hardcoding secrets. Access control is managed primarily through Databricks secrets and endpoint-level permissions, ensuring the serving environment can authenticate to dependent resources while following least-privilege principles.

1 · Learn the must-know

• 1Model serving endpoints execute in a secure, isolated environment separate from the workspace, so they cannot automatically inherit a user's or notebook's ambient credentials and must be explicitly configured with access.
• 2Databricks Secrets (secret scopes) should be used to store API keys, tokens, or credentials needed by the model at inference time rather than embedding them in model code or environment variables in plaintext.
• 3Serving endpoints can be granted access to Unity Catalog resources via the endpoint's service principal or the identity under which it runs, and permissions must be explicitly granted on the underlying tables, functions, or indexes.
• 4Endpoint permissions (CAN VIEW, CAN QUERY, CAN MANAGE) control who can invoke, view, or modify the serving endpoint itself, and should be scoped to the minimum necessary role for each user or group.
• 5When a model needs to call external services (e.g., third-party APIs), credentials should be injected via environment variables backed by secrets at endpoint creation/update time rather than baked into the model artifact.
• 6Using a dedicated service principal for the serving endpoint (rather than a personal user identity) is the recommended pattern for production deployments to ensure stable, auditable, and least-privilege access to dependent resources.

2 · Check your understanding