Is it possible to limit accessible orgs?

[jwalke]

Is there a way to configure this MCP server so that it would be difficult/impossible for it to connect to a production org?

We are interested in testing out this MCP server but we'd like to be 100% sure it couldn't grant an AI agent access to our production org.

I reviewed the documentation around configuring orgs.

Consider this scenario:

A Salesforce dev configures this MCP server using DEFAULT_TARGET_ORG as the --orgs argument.

The dev's default org is set to a scratch org where they're building out a new feature with the assitance of an AI agent.

Then, the dev switches their default org to production (where the user has admin access) so they can run some queries.

Then, the dev continues their agentic development, not realizing that they're still pointed to prod.

What options are there to prevent this scenario from happening?

• Ideally, this could be enforced at the enterprise/policy level so that an employee couldn't intentionally or unintentionally point their MCP server to prod
• Is there a Salesforce permission that determines this access? Assume that the user requires admin access to prod though, could a permission be set to ensure that their coding agent doesn't have admin access to prod?
• If there is no way to prevent this, is there a way to detect/report that it happened?

[cristiand391]

Ideally, this could be enforced at the enterprise/policy level so that an employee couldn't intentionally or unintentionally point their MCP server to prod

There's no settings in org UI for these kinds of local servers so this is unlikely to happen.

Is there a Salesforce permission that determines this access? Assume that the user requires admin access to prod though, could a permission be set to ensure that their coding agent doesn't have admin access to prod?

You could create a connected app for CLI auth and not give it the "API request" scope but it would also block CLI operations.
Not sure how we could use permsets to block this scenario, on the org side these are usually "API perms" which also cover CLI, vscode extensions, etc.

If there is no way to prevent this, is there a way to detect/report that it happened?

When you authenticate to an org using the CLI we can tell the kind of org (scratch, sandbox, devhub, etc), we could make the MCP server throw if DEFAULT_TARGET_ORG is not a scratch or sandbox org and ask for a --allow-prod-org flag to get user confirmation.

Would this work for your use cases? I agree that MCP servers should have tighter access control and scratch/sandoxes only by default could work as a safety measure.

[jwalke]

@cristiand391 Yes, we would really appreciate the enhancement you proposed:

we could make the MCP server throw if DEFAULT_TARGET_ORG is not a scratch or sandbox org and ask for a --allow-prod-org flag to get user confirmation

Our biggest concern is the MCP server accidentally getting pointed to a production org, so having this blocked by default unless the user specifically confirms they mean to be pointed to a production environment would be great.

[cristiand391]

Cool, I'll get a ticket for this feature to discuss with our team.

Related:
Still haven't got it setup but I was planning to use https://github.com/dagger/container-use to to isolate orgs.
The flow would be like:

1. get JWT authentication for headless auth: https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_jwt_flow.htm
2. start container with only the scratch org authenticated.
3. connect agent tool (claude code, amp, etc) with salesforce DX MCP.

It's mostly thought for headless agents (copilot, claude, etc) but would work for local too.