Updated: November 06, 2026
Anaplan Analyst (“Analyst”) and Anaplan AI Gateway (“Gateway”) are two new AI offerings that let you query your Anaplan data using LLMs. Analyst is native to the UX and has been designed to understand Anaplan models, so your team can ask questions and act on answers without leaving the platform. Gateway takes a different route: it lets you access your Anaplan data using your own LLM.
Anaplan Analyst at a glance
Anaplan Analyst is a secure, generative AI assistant using our rich, agentic framework to help your team gain deeper insights, accelerate decision-making, and interact with natural language.
- Modern, Intuitive UX: Ask questions and get real-time answers using natural language, right in the Anaplan UX.
- Pre-tuned on Anaplan’s model logic: It understands modules, hierarchies, and relationships without additional setup.
- Causal & Diagnostic Analysis: Analyst will drill down to tell you the “why” behind your metrics.
- Traces answers through the calculation chain: Every response includes data lineage back to source models and logic, so users can verify and defend the result.
- Approved Model Write-Back: Update your forecasts and plans directly from Analyst using writeback into live Anaplan models.
Anaplan AI Gateway at a glance
Anaplan AI Gateway, a supported, governed MCP (Model Context Protocol) interface, connects external LLMs, assistants, and agents, such as Claude, Gemini, and Microsoft Copilot, to your Anaplan models.
- Bring Your Own LLM: Connect your team’s designated LLM, or a custom-built agent or solution, straight to your Anaplan models; Gateway provides access to data, your LLM brings the logic.
- Model awareness comes from your LLM: Because you control the prompts, context, and tuning, you can create the experience you can design.
- Read & Approved Write-Back: Retrieve data today, with write-back access coming soon, governed by the same Anaplan permissions as everywhere else.
Gateway gives your team a secure, governed connection to Anaplan data via MCP, allowing you to access your Anaplan data or create custom solutions via the LLMs your team already uses. However, it doesn’t include built-in understanding of Anaplan structures or how your data is designed. That context must come from the LLM, how it’s prompted and tuned. For reliable, self-service insights out of the box, though, we’d still recommend using Analyst.
Where they align
Analyst and Gateway both look directly at the underlying model data where they are enabled. This gives users insights from live data pulled directly from your models, while also giving Analyst and Gateway access to all data points in the models the user can access. Users can get answers to questions using data that hasn’t already been published to UX pages.
Because Analyst and Gateway can read the full model detail (modules, line items, lists, and notes), and Analyst can already write back to live plans, now is an ideal time to conduct a thorough model review before enablement. This guide gives COE leads, Solutions Architects, Model Builders, and AI Admins a checklist to see if your model security, role-based access, and approaches to data discoverability are properly configured, ensuring Analyst and Gateway surface only the data each user should see.
Quick comparison: Analyst vs. Gateway
Both tools give an LLM direct access to your Anaplan model data, respect your existing model permissions, and are enabled by your AI Admin. Where they differ is scope and entry point:
Neither product adds a separate layer to change read or write permissions; neither overrides your existing model governance.
Data access at the model level is the same for both products, governed by the model’s Role permissions, Selective Access, and Dynamic Cell Access. The only real difference is how it is applied: Analyst is enabled per App, so any model associated with that App is queryable, if the user has access to those models. Gateway is enabled per workspace, so any model in that workspace the user can access can be queried.
ALERT
Polaris models with DCA applied to any line item with over 10million+ addressable cells should not enable Analyst or Gateway at this time.
Permissions overview
The matrix below lays out every security setting side by side for both products, split by Standard User and Workspace Admin (WSA). The pattern is the point: almost every row is identical across all four columns. The only real difference is which role gets elevated access by default, and that holds true whether the request comes through Analyst or Gateway.
Please note, only the permissions already set in the model apply. Any user with No Access will not be able to query those models even if enabled by either Analyst or Gateway.
Key takeaway
Neither product adds a new permission layer. Only what is set in the models governs read/write access. Roles, Selective Access, and DCA are all honored based on the specific models for each user. Whatever a user can read or write in the model, they can read or write through Analyst and Gateway.
How Analyst & Gateway changes things
Today, most users access model data through the UX apps built on top of it. That means a user's actual access to data depends on two things: what's been published to the UX, and the permissions set within the model itself. For example, someone with broad Role or Selective Access to a module still won't see that data if it was never added to a page. Many Page Builders use UX techniques such as filtering out specific list members, leveraging saved views, hiding specific line items, and setting page-level Manage Access rights to restrict the data their users can view on pages. In effect, the UX layer acts as an additional filter on top of the model's real permissions. While these UX-level “view settings” help shape the page experience, they don’t replace model-level security. The underlying Role Permissions, Selective Access, and Dynamic Cell Access are ultimately what govern what Analyst or Gateway can read.
Because Analyst and Gateway can search across the entire model to answer a question, any data a user has access to through their Role, Selective Access, or Dynamic Cell Access (DCA) settings can surface directly in a response, whether or not that was ever intended.
As a model builder, this means thinking beyond what's exposed in UX apps and drilling into the underlying model architecture. When building or reviewing models, you should evaluate your current security configuration (Role Permissions, Selective Access, and DCA) for every line. You will want to start asking yourself:
- Access: Can an AI agent read or write to this line item in its current state?
- Risk: If accessed via AI, could it confuse users, deliver inaccurate data, allow accidental overrides, or expose sensitive information?
- Mitigation: If any risk is present, how will you restrict or secure this data?
Key takeaway
“We haven’t added this to a page” is no longer a valid mitigation. If the users access controls permit it, Analyst or Gateway can surface it. Treat every model enabled for either Analyst or Gateway as if every permitted data point is one prompt away from being shown to a user.
The model security review checklist
The sections below outline what to check before enabling Analyst or Gateway. This review should be done periodically as your models and ecosystem evolve.
Step 1: Walk through the decision tree
Use the decision tree below to assess, at a high level, whether a UX App or models in a Workspace are ready to have Anaplan Analyst or Gateway enabled, or whether updates are needed first.
On a practical note
If there isn’t sensitive data or personally identifiable information (PII) in the models, the data access review is still a good idea, but can focus more on usability. For models that do, work through the questions below, make any required updates, then test using a standalone UAT model to identify any gaps before enabling for your users.
Step 2: Review your models
Work through these questions for each model that will be enabled (by app for Analyst, or workspace for Gateway). These help you think through what Analyst or Gateway can surface in your models, or what you have intentionally hidden in your current setup. This list isn’t exhaustive; it’s meant to spark deeper thinking about whether your models may need additional data access settings.
Checking the UX
The UX layer has its own filtering and visibility logic, but that doesn’t affect what Analyst or Gateway can read. Review every page for UX techniques that hide data the model layer may reveal through Analyst or Gateway. You’re not looking for UX issues to fix; you’re identifying where the UX is being used to hide data. This may indicate that you need to address the issue directly in the model.
☑️ Are Saved Views or Custom Views used to filter out sensitive line items or list members?
☑️ Are you hiding line items in your UX Cards and removing user pivoting to ensure hidden lines aren’t exposed?
☑️ Are user-based filters applied in the UX to protect data?
☑️ Are UX filters used to hide line items or list members?
☑️ Have any modules been explicitly left out of UX pages because of their sensitive nature?
☑️ Do any Pages have Manage Access restrictions applied within the UX App?
☑️ Are My Pages disabled to prevent users from accessing data?
Checking the models
Since you can’t rely on the UX layer to hide or limit access to data, you need to verify that your model-level security and exposure are exactly as you intend. The following list of questions is designed to help you think through the various objects within each model and the potential risks. Even if your model does not contain sensitive data, this exercise still has value. For example, staging calculations could cause confusion if they surface, or could be inaccurate if they are only one step in the calculation; what would happen if a user relied on that information?
☑️ Are Model Role permissions set appropriately?Do you need to add additional Roles to be able to appropriately provide the right level of access to your users? Confirm access is not defaulted to Read for all modules, lists, and versions.
☑️ Is Selective Access enabled where needed?Confirm it is applied at the appropriate levels, considering all modules with Read/Write User Role access, and applied against list-formatted line items wherever sensitive data is present in lists.
☑️ Are Dynamic Cell Access (DCA) drivers being driven by any writable line items?
☑️ Are there any import line items set with write access for any Roles, or do any of those modules include override functionality for users?
☑️ Are you using Workflow?If so, are any cell writes (Booleans, approvals, comments, etc.) driven via workflow writes?? Are you using the user lists as a list-formatted line item anywhere in the model to specify recipients or approvers? Do you want to restrict them to see only their own requests or approvals? Use a combination of Role permissions, Selective Access, and DCA to provide the best security and experience available.
☑️ Are you using custom user lists anywhere in the model? Is this list restricted by Selective Access?
☑️ Do all the line items currently in a Read/Write module need write access, or should some be moved into a separate module? Of course, following the PLANS standards.
☑️ Are all the modules, line items, lists, or list members being used? Remove any that are no longer being used. Now is the time to ensure there is no technical debt in the model. PLANS standards.
☑️ Is your user list up to date? Remove users or change their access to No Access for any user who no longer needs access to the model. Do they have the right Role and Selective Access applied?
After checking your model and UX app, if you find that you need to apply additional data access protections to your model, your next step is to determine whether to update your Roles, apply Selective Access, add DCA to your models, or a combination of approaches. This may require some rearchitecture to properly secure any sensitive data. If you need help creating a plan, please reach out to your account team to engage with Professional Services.
Key takeaway
After your review of the model and UX, update the models’ security as needed to prevent accidental exposure. If that isn’t possible, do not enable Analyst or Gateway for the associated UX applications or workspace until you can.
Recommendations: Roles, Selective Access, and DCA
As you think through the appropriate updates for your models, you will want to consider how you can combine each layer to provide the appropriate data access for your teams. Each layer does a different job, and none of them substitutes for the others. Reach for the most precise tool only when a broader one genuinely can't do it to reduce the maintenance overhead.
Understand the scope and limitations of each.
- Model Roles. Default every new module, list, and version to the most restrictive Role permissions while still letting people do their job, then grant access deliberately for each Role rather than by default. If modules are set to read or write access, only include the line items that also need to be read or written; don’t pack extra line items into modules if they should have different access. See Model Roles on Anapedia for the full set of Role options.
- Selective Access. Apply it wherever a list holds sensitive members, such as employees, positions, or any list with members that only certain users should view. If your flat list includes sensitive data, see if there is a logical way to convert to a hierarchy in order to apply selective access. For any production lists with members added by end users that could include sensitive data, ensure they are added to appropriate parents to enforce selective access. See Selective Access on Anapedia.
- Dynamic Cell Access (DCA). Reach for DCA only when Roles and Selective Access can't get the granularity of access you need, for example, hiding a handful of cells within an otherwise read access module, or allowing write access only when specific conditions are met.
While Dynamic Cell Access is a tool model builders can use to hide data or further restrict a line item’s access, it's worth viewing it through the right lens: it's not true security. DCA is driver-based suppression. Rather than a structural permission like a Role, DCA hides a specific cell only if a Boolean line item evaluates that exact data point intersection and determines whether to hide or expose it. It's only as reliable as the driver logic behind it. Treat it as another modeling exercise to review carefully, not a control you can simply switch on and trust. For any workflow that includes writes to the model, DCA is an important tool to help mitigate any accidental approval overrides from Analyst or Gateway. Finally, while DCA can help you fine-tune data access, apply it thoughtfully, as it can affect model size and performance if you don't follow best practices. See Dynamic Cell Access on Anapedia.
A note on DCA and Polaris
DCA is evaluated live, as a Boolean calculation across every cell it's applied to. On Polaris models, applying it broadly, especially on line items with a large number of addressable cells, can force a dense calculation pattern and impact performance. Apply DCA carefully, and only where Roles and Selective Access genuinely can't achieve the same result.
Step 3: Build this into your routine
This isn’t a one-time exercise. Security reviews like this should already be part of ongoing model management and are important for any production model, whether it’s accessible by Analyst or Gateway or not.
- Inventory your apps and models. List every UX App enabled (or planned) for Analyst or every Workspace planned for Gateway, and every model behind each app or workspace. Queries in Analyst and Gateway follow the model, not what’s been added to a page.
- Run the decision tree per model. A single app or workspace can include more than one model; work through each one on its own.
- Work through the checklists with people who know the design. The COE leads, Model builders, and the Page builders for each app and model are best suited to confirmRoles, Selective Access, DCA, Saved Views, page-level settings, etc.
- Set a regular cadence. Pick an interval that fits your team, quarterly or aligned to your release cycle, and repeat this review for models in production.
- Revisit after changes. Any new module, workflow write back, or major structural change should trigger another security check, in addition to your regular cadence.
Step 4: Test before you enable
Before enabling on your live app or workspace, run a standalone test of any models in question. For Analyst, copy the model(s) and app; for Gateway, copy the model(s) to a different workspace, update access to only allow the designated testers, enable the copied app or workspace, and work through the types of prompts a real user would. Four steps: Copy, Ask, Trace, Adjust.
Copy
- Copy the model and app (repointing to the copied model) into a standalone test environment.
- Turn off access for all users except those performing the tests.
- If your model includes workflows, templates don’t come along automatically, so replicate and repoint them to the new model and pages to test any DCA triggers.
Ask
- Once your testers are set up, ask the questions a real user might ask. Plus,prompt as if you’re trying to access hidden data.
- Turn off access for everyone except the testers, then enable Analyst or Gateway only for the copied app or workspace.
- Test with realistic Roles and Selective Access, not just your own admin access.
- Use alias accounts to mimic real user permissions, so you can test across a representative sample of settings and scenarios.
Need a testing alias?
Talk to your IT team about setting one up if you don’t already have one. Alias accounts allow you to test across a range of real permission combinations without the need to modify your actual account.
Trace
- Trace unexpected or surprising answers back to the source to understand why Analyst or Gateway surfaced them.
- Pay close attention to anything with DCA triggers, confirming suppression behaves as expected.
Adjust
- Fix any gaps in your data access, or data you don’t want surfaced for clarity or accuracy. You may also want to look at line item naming conventions and adding notes to improve responses.
- Re-test before releasing access to real users.
Analyst and Gateway focus on the model(s) that make up apps or workspaces, respectively, not UX pages. For true user access testing, review at the model level, even if your prior testing focused mainly on the UX.
Key consideration
While Analyst attempts to understand the context and intent of the model architecture, model security can reduce, but may not fully eliminate, data being shared with users that you did not intend. For example, some line items require read access simply to support a calculation string, and others need write access for workflow, imports, or actions. If your review finds line items that can't be restricted and contain data that would introduce confusion, inaccuracy, or sensitivity if surfaced, you may want to hold off on enabling Analyst for the related apps.
Workspace hygiene: getting ready for Gateway
Because Gateway is enabled for the whole workspace, the state of your workspaces matters as much as the model-level review above. Many workspaces hold models that were never meant for end users; model copies used for testing, data hubs, or older versions kept “just in case,” and permissions on those models often haven’t been reviewed in a while. Now is the time to review your Workspace hygiene as well.
Conclusion
Getting a model ready for Anaplan Analyst or Anaplan AI Gateway is the same work that keeps any production model secure: confirming that Roles, Selective Access, and Dynamic Cell Access reflect exactly the data each user is meant to see. Because Analyst reads across the full model, the model layer is now the boundary that matters. Run the decision tree and checklists above for each app and model you plan to enable; make it a recurring check rather than a one-off, and you’ll be in a strong position to activate Analyst with confidence.
Contributors: Rob Marshall, Theresa Reid, Jason Blinn, Dave Waller, Ruth Juni, Adam Trainer, Elizabeth Schera.
