Anaplan AI Gateway (“Gateway”) is a supported, governed MCP (Model Context Protocol) interface that connects external LLMs, assistants, and agents, such as Claude, Gemini, and Microsoft Copilot, to your Anaplan models. It lets your teams’ LLM clients query your Anaplan models directly. This means users can ask questions about their plans in natural language, or you can build custom agents or solutions using your LLM.
The AI Gateway supports both read and write (coming soon) access, so users can retrieve data from their models and update it from the AI tools they already use. The Gateway applies your existing Anaplan permissions to each request, so users can only read or write what they are authorized to.
Because the Gateway relies on native Anaplan permissions, the state of your workspaces matters. Before you turn it on, there are four things worth knowing:
- Available by request: Depending on your License edition, you can request that Gateway be made available in your Tenant through your Customer Success Business Partner.
- Enabled at the workspace level: Your AI Admin Role will select the workspaces that are Gateway-enabled from Agent Studio. Once Gateway is enabled for a workspace, any online model in that workspace (models that are not archived and not in offline mode) can be queried by your LLM client. Workspace Admins can also query models while they’re offline, just as they can access offline models in the modeling experience.
- Model access still applies: A user must still have access to a specific model before their LLM client can reach it.
- Hygiene is the key: Workspaces often hold models that were never meant for end users, and permissions on those models often aren’t reviewed regularly.
With AI Gateway, correct user permissions are more important than ever, so now is a great time to review the health of your workspaces. This guide gives Workspace Administrators, COE leads, Solutions Architects, and Model Builders a six-step review to run before enabling AI Gateway, plus many other resources to help maintain your Workspace hygiene over time. If your workspace allowance supports it, you can also reduce exposure by moving models into fit-for-purpose workspaces. For any live model you move, this guide walks through what to update so everything keeps working as intended.
How AI Gateway changes things
Many workspaces contain models that were never meant for end users; model copies used to test functionality, data hubs, or older versions kept “just in case,” to name a few. Additionally, Dev/Test/Prod models sometimes end up in the same workspace, even though that isn't considered best practice. Up to this point, it’s been easy to park models wherever and ignore them.
End users are unlikely to encounter these models if they aren’t exposed in a UX app or page, or if the model contents are turned off. As a result, builders rarely worry about verifying or updating user permissions. In practice, the lack of a UX has acted as protection: if users can’t view the data in an app, nobody sees it.
Gateway changes that. Because data access is enabled for the full workspace rather than for an App, it isn’t limited to what you’ve published. Any model a user has access to in that workspace is discoverable and queryable from their LLM client, whether or not that was ever intended.
The key takeaway for admins
“It isn’t in an App” is no longer a valid mitigation. If a user still has access to a model in a workspace where AI Gateway is enabled, their LLM client can reach it. Treat every model in the workspace as if it is one prompt away from the users who have access to it.
Workspace-level enablement also gives you a second lever. Beyond tightening permissions, you can group models into workspaces built for a specific purpose, so enabling AI Gateway on one workspace doesn’t put unintended models in reach.
The workspace review checklist
The steps below outline what to do before enabling AI Gateway on a workspace. Run them for each workspace you plan to enable, and repeat them periodically as your models and environment evolve.
The six steps at a glance:
Step | Action | Outcome |
|---|
1 | Audit your models | A clear list of which models are still needed, who uses them, and whether they belong in their current workspace. |
2 | Archive unused models | Fewer live models mean less to secure and maintain since archived models are not accessible via AI Gateway. |
3 | Perform a data access review of each model | Data permissions are set to protect any sensitive data within all models that will remain in the workspace. |
4 | Move models that belong elsewhere | Models grouped into workspaces by use case, user group, and lifecycle stage. |
5 | Follow the Moving models across workspaces guide (as needed) | Every moved model, integration, app, and report works as intended in its new workspace. |
6 | Check users in every model | Only the right users can see and query each model. |
Step 1: Audit your models
Start with an inventory of every model in the workspace. For each one, decide whether you need it to stay active and whether it belongs in this workspace.
Checking your inventory:
- Is the model still in use? Check when it was last used, and by whom.
- Does it need to be live? Some models only matter at certain points in the year, or for audit. Those may be better offline or archived, or moved to another workspace.
- Does it belong in this workspace? Consider its use case, its users, and its ALM role (Dev, UAT, or Production). Note: Production models should be the ONLY model in that workspace to simplify user access, enforce segregation of duties, streamline maintenance, and improve performance.
- Does it have an obvious owner? Models with no owner are the ones most likely to hold forgotten permissions.
- What is being used by the model? List target models, integrations, ADO pipelines, AXL workbooks, App pages, workflow tasks, and published links.
Record the answers in a register kept outside Anaplan, including the workspace ID and model ID for each model. It makes the next steps and any future audit much faster.
Step 2: Archive any unused models
Fewer live models mean less to secure, less to maintain, and less for Gateway to reach.
- Can the model be archived? Anything with no owner, no recent use, and no dependencies is a strong candidate.
- Is it a source for other models? If so, repoint the import data sources in those dependent models first.
- Would offline mode be a better fit? For models you need occasionally, taking them offline can be better than leaving them live.
- Is the model genuinely no longer needed? If so, delete it once you’re sure there is no reason to keep it.
Planning for archived models
You can bring archived models back online as needed, but doing so in a Gateway-enabled workspace requires a bit more caution. If you don’t intend for that model to be discoverable, there are a couple of things to consider:
- Are your archived models named consistently? You will want to apply a consistent naming convention to your models before putting them into an Archived state. This is a best practice anyway, but it is potentially more important for Gateway-enabled workspaces to create a clear signal to users and WSA that if they see something named ARCHIVE, for example, they should use caution before binding and querying that model. The recommended naming convention is a derivative of “ARCHIVE”_”Date of Archive”_”Model Name”, or a shortened version, as long as it is consistently applied. Example: ARCHIVE_Dec 26_FP&A Production.
- Are you restoring an archived model? To minimize discoverability to only WSA, it is recommended to bring the model out of the archived state and directly into offline mode. This allows you to perform any cleanup and data access checks before making it available, or to pull data without ever exposing it beyond the WSAs.
- Are users set to No Access? Another way to minimize accidental queries when you bring a model online is to ensure all users are set to No Access before archiving the model. However, you should verify No Access is set correctly anytime you unarchive models.
Step 3: Review data access in the models that remain
Every model that you plan to keep in a Gateway-enabled workspace should go through a data access review. Since AI Gateway can connect to all models in the workspace, you will want to verify that the data the user can access is as intended. Work through the model-level checklist in Anaplan Analyst & AI Gateway: A readiness guide for builders for each model.
Full model discovery
AI Gateway can discover the full model. As noted earlier, the assumption “if it isn’t published, users won’t see it” doesn’t hold for model data in Gateway-enabled workspaces. Gateway access isn’t limited to data published to a UX App or Page; it can access every line item users are permitted to see based on module-level permissions and every list member not restricted by Selective Access. The model layer, not the UX, determines what data is returned.
Checking data access:
- Are Model Role permissions set appropriately? Confirm no role has broader access than they need, including write access.
- Is Selective Access enabled where needed? Apply it wherever sensitive data is present.
- Is Dynamic Cell Access (DCA) in place where it is needed? Confirm data is restricted at the cell level where appropriate, and that the driver logic behind it is sound.
- Can you restrict access enough to protect the data in this model? If the answer is no, mark the model to move in Step 4.
If you can’t protect it, move it
A model whose data you can’t adequately restrict shouldn’t sit in a workspace where AI Gateway is enabled. Because enablement applies to every model in the workspace, relocating the model is often simpler and safer than trying to engineer around it.
Step 4: Move models that belong in a better workspace
Some models end up sitting in a workspace that has become a catch-all. If your workspace allowance allows, move models into workspaces designed for their purpose.
Planning your workspace ecosystem
- Are models grouped by use case or common user group? A workspace that serves one audience is easier to review and to secure.
- Do Dev, UAT, and Production each have their own workspace? This is already an ALM best practice, and it keeps AI Gateway exposure aligned with each environment.
- Are you stuffing everything into a few workspaces for simplicity? Convenience today becomes a wide access footprint later and can lead to performance issues.
To request new workspaces, reach out to your account team.
Step 5: Make sure moved models work as intended
Not all models you move will need these steps, but for any that will remain live, you will have a few additional items to verify and potentially action. Moving a model has real consequences; you will need to consider any impacts to integrations, users, ALM, etc., so read “Moving models across workspaces” later in this guide before you start.
Every model you move is a new model with a new workspace ID and model ID. Treat each move like a mini release: freeze changes in the original, validate the copy, then cut over. Lock or archive the original model once everything has been confirmed to be repointed and updated appropriately.
It is always easier to maintain a model in the original workspace, which is another reason to plan, review, and maintain your tenant ecosystem and to review your workspace hygiene periodically. You want to build your models where they will be used and retained.
Step 6: Check user permissions in each model
For each workspace that you plan to enable Gateway, review the user access permissions in every model that remains, confirming that only the appropriate users have access.
Checking your users
- Does anyone have access to a model they shouldn’t be able to discover? Set their access to No Access. This applies to all models, but may be more important to models that aren’t exposed in any App or Page.
- Are there users who don’t need access to any model in the workspace? Remove them from the workspace.
- Are users marked as workspace administrators (WSA) correct? Keep it to the users who genuinely manage or build models in this workspace. This should follow the recommendation that models should be added to fit-for-purpose workspaces whenever possible. Your WSA should also match the purpose of the models within as well. For example, for segregation of duties purposes, your Production Model environment should include only the WSA responsible for performing the model sync.
Note: These recommendations are focused only on the native Anaplan user access and do not include any additional permissions or access that may be applied via your LLM client.
Add new users with No Access
Whenever you add a new user to a model, add them without WSA access and with the Model Role set to No Access. That sets their permissions to No Access across all models in the workspace, and you can then apply WSA permissions and their role in each individual model as needed. If you add them with full access, that access applies across all models, including any new models added, and you will have to correct it in every model where it wasn’t intended.
Check WSA access for every new model
When you add a new model to a workspace, any user that is a WSA will automatically inherit the Full Access permission as their Role. This is also true for every new WSA added to a Workspace, they will be added to all existing models as WSA and Full Access by default. If this is not intended, you will need to update their Model Role to the appropriate role.
Build this into your routine
This isn’t a one-time exercise. Workspace reviews like this are good practice whether or not AI Gateway is enabled, and they keep working for you long after the first clean-up.
- Inventory your workspaces and models. Keep the register current, with an owner for every model and workspace.
- Work through the checklists with people who know the design. Workspace Administrators, COE leads, and Model Builders are best placed to confirm who should have access to what.
- Set a regular cadence. Pick an interval that fits your team, quarterly or aligned to your release cycle, and repeat the review.
- Revisit after changes. A new model, a new workspace, a new group of users, or AI Gateway being enabled on another workspace should all trigger another check.
- Keep sensitive models apart. If a model holds data that should never be queried through an LLM client, keep it in a workspace where AI Gateway isn’t enabled, or restrict access to it.
Design considerations
- AI Gateway follows the workspace, not the App. Review at the workspace and model level, even if your earlier checks focused on what’s exposed in UX Apps.
- Permissions are what decide reach. UX pages shape the experience, but a user’s access to a model within a workspace decides what their LLM client can reach.
- Clean workspaces narrow exposure; they don’t replace model security. For the models that remain, review Roles, Selective Access, and Dynamic Cell Access too. See Anaplan Analyst & AI Gateway: A readiness guide for builders for a model-level checklist.
- Make it routine. Add this review to your existing release testing and access reviews rather than treating it as a separate task.
Conclusion
Getting a workspace ready for AI Gateway is the same work that keeps any production environment healthy: knowing which models you have, keeping only what you need live, putting models in the workspaces they belong in, and making sure only the right users can reach each one. Because AI Gateway is enabled for the whole workspace, a tidy workspace is now part of your security boundary. Work through the six steps, make them a recurring check, and you’ll be in a strong position to enable AI Gateway with confidence.
Resources
Data access review
Workspace and model lifecycle
Contributors: Elizabeth Schera, Rob Marshall, Allison Slaught, Theresa Reid, Adam Trainer
