5.4 Managing and Preventing Access to Specific Models
Key Takeaways
- In Einstein Setup, the Configure Model Providers section lets admins turn individual LLM providers on or off to allow or block their models org-wide.
- Turning off a model provider can stop agents, agent actions, Testing Center, prompt templates, and APIs that use its models, and can take up to 10 minutes to apply.
- A model configuration hidden in AI Models keeps working in existing templates, but builders must pick another model before saving a new version.
- The Agentforce model option is set in Einstein Audit, Analytics, and Monitoring Setup, and a subagent model override takes precedence over the agent and Setup defaults.
- Each prompt template version can use a different model configuration, and only the activated version's model is used.
5.4 Managing and Preventing Access to Specific Models
Quick Answer: To block a model provider org-wide, go to Einstein Setup → Configure Model Providers and turn that provider off. To steer which model a feature uses, hide model configurations in AI Models (formerly Einstein Studio), set the Agentforce model option in Einstein Audit, Analytics, and Monitoring Setup, choose a model per prompt template version, or set a model override on an agent or subagent. Test in a sandbox first, because turning off a provider can stop features that depend on it.
Why Model Access Is a Governance Topic
Organizations may need to restrict models for data residency, contractual, security-review, cost, or quality reasons. The Spring '26 exam guide lists this objective under Prompt Engineering: explain how to manage and prevent specific models from being accessed.
Control 1: Manage Model Provider Access (Org-Wide Block)
| Detail | Value |
|---|---|
| Where | Setup → Einstein Setup → turn on Einstein if needed → Configure Model Providers |
| What you do | Selectively turn on or off model providers |
| Default | Model providers are usually enabled by default |
| Permission | Admin permissions |
| Time to take effect | Up to 10 minutes |
| Amazon Bedrock nuance | Currently only Anthropic and Amazon models are affected |
When access to a provider is on, its LLMs can be used in agents, prompt templates, APIs, and other generative AI features. Turning a provider off blocks access to its models in your org. Salesforce shows a warning because disabling access can stop affected components from running, including:
- Agentforce agents and agent actions
- Agentforce Testing Center
- Prompt templates and APIs, including the Agentforce API
- Email Summaries, Knowledge Generation, Service Replies, Generative Campaigns, Sales Summaries
- Other Salesforce features that access LLMs
Salesforce recommends testing and verifying AI-enabled functionality in a sandbox before changing this in production. Features can depend on providers in less obvious ways. For example, enriched indexing in Data 360 requires Amazon Bedrock models (Amazon and Anthropic) to be enabled in Einstein Setup.
Control 2: Hide Model Configurations in AI Models
LLM configurations are managed in AI Models (formerly Einstein Studio). Standard configurations come with Prompt Builder, custom configurations are added with BYO-LLM, and modifying a standard configuration saves it as a custom one.
A configuration can be hidden in AI Models:
- A prompt template that already uses a hidden model continues to run.
- If a builder opens a template that uses an unavailable model, Prompt Builder requires them to select a different model before saving changes as a new version.
- If a template that uses a hidden model is cloned, the hidden model isn't available to the clone.
- Salesforce recommends replacing hidden models with available ones.
Hiding stops new use of a configuration without breaking existing activated templates. Turning off a provider blocks its models at run time.
Control 3: Choose Models per Template Version
- In Template Settings, choose the model configuration for a template version.
- Each version can use a different model, but only the activated version's model is used.
- The View this model link opens the model in AI Models, and it requires Data Cloud Admin permissions.
- Deployment and packaging: deploying a template with a custom LLM configuration fails if the target org has no model with the same name, and templates with custom models can't be packaged.
Control 4: Agentforce Model Option and Overrides
The model option for Agentforce applies to all agents and is set in Setup → Einstein Audit, Analytics, and Monitoring Setup. Salesforce recommends Salesforce Default, a managed mix of models chosen for accuracy, trust, and performance. As of September 2026, Help also lists an AWS-Hosted option (Anthropic Claude on Amazon Bedrock inside Salesforce's VPC) and a Google Gemini option (new builder only). Specific model versions change over time, so learn the options, not the version numbers.
Key rules:
- For any option, specific tasks such as subagent classification or citations may use Salesforce-owned models, like the HyperClassifier for routing.
- Although Agentforce limits the reasoning-engine options, a custom action using a prompt template, Apex, or the Models API can reference any Salesforce-managed or BYO model.
- After switching options, test custom prompts, actions, and subagents. Salesforce notes some models are more sensitive to input wording.
Model override order (new builder only)
When a subagent runs, Agentforce picks the model in this order:
- The model set on the subagent
- The model set for the agent
- The model selected in Setup (the Agentforce model option)
A subagent override doesn't change the model used by prompt templates in its actions, because those templates use their own configured model. Salesforce's guidance is to use small, fast models (or the HyperClassifier) for routing and simple lookups, large models for complex reasoning and structured output, and multimodal models for images and documents. Start with a capable model as a baseline, then try smaller ones.
In Agent Script, a model is configured with model_config, for example the HyperClassifier on the Agent Router:
start_agent agent_router:
model_config:
model: "model://sfdc_ai__DefaultEinsteinHyperClassifier"
If you remove model_config, classification falls back to the model option selected in Setup.
Scenario Practice
| Scenario | Best control |
|---|---|
| Security requires that no Amazon Bedrock-hosted Anthropic models be callable from the org | Turn off that provider in Configure Model Providers, after sandbox testing |
| A retired custom model configuration shouldn't be chosen for new templates, but three active templates still use it | Hide it in AI Models, then migrate the templates to new versions with another model |
| The General FAQ subagent can use a faster model while other subagents keep the default | Subagent model override in the new builder |
| A classification-heavy router needs speed and precision | HyperClassifier via model_config on start_agent |
| A template deploys to production and fails with a model error | The target org lacks a model with the same name as the custom LLM configuration |
Exam Traps
- Turning off a provider isn't cosmetic. It can break agents, templates, Testing Center, and APIs, so test in a sandbox.
- Hidden models keep running in existing templates. Hiding isn't an immediate block.
- Model overrides don't change prompt template actions. Templates use their own model.
- Only the active template version's model matters, not a draft version's selection.
A security review requires that an organization block all use of a particular LLM provider's models across agents and prompt templates. What should the admin do?
An admin hides a model configuration in AI Models. What happens to an active prompt template that already uses that model?
A subagent has a model override, the agent has no model set, and Setup specifies the Salesforce Default option. Which model does the subagent use when it runs?
An admin plans to turn off a model provider in production. What documented behavior should be considered first?