Norce Backend MCP Servers — Security and Access

This page is for IT administrators, solution architects, and team leads who are responsible for deciding who gets access to the Norce Backend MCP Servers, and how that access is configured. It covers access scoping, credential management, production access controls, and the built-in safeguards that protect against accidental changes.

For connection and setup instructions, see Using the Norce Backend MCP Servers.

How access works

Access to the Backend MCP Servers is controlled through Norce OAuth2 clients. Each user or team that connects an MCP server authenticates using a ClientId and ClientSecret. The third header, AccountId, is not part of authentication — it identifies the account recorded as the author of any writes, which is what makes changes attributable afterwards. All three values are stored in the AI client's local configuration and passed as headers with every request.

The Backend MCP Servers do not have their own access layer. They call Norce's existing APIs on behalf of the authenticated client, using the same permissions that client has been granted. This means MCP access is exactly as powerful as the credentials behind it — no more, no less.

Two conditions must both be met for a credential to work with the MCP servers:

1. The OAuth2 client must have access to the relevant Norce APIs (Management API, Connect API, Query API, Commerce Services APIs).
2. MCP access must be explicitly activated for the client in Norce Admin under Users > OAUTH.

Access granularity in v1

The current version of the Backend MCP Servers uses the same authentication model as the Norce APIs — access is granted per API, not per operation. Within an API, access is all-or-nothing: enabling the Product API gives the credential access to all Product MCP tools, both read and write. There is no way in v1 to grant read-only access to an API or restrict access to a specific subset of tools.

This is a known limitation. More granular access control — including read/write separation and tool-level restrictions — is planned and will be available in a future release.

Who should have access

Access to the Backend MCP Servers should follow the same principle as access to the Norce Admin UI or direct API access: grant it to people who have a legitimate operational need.

Appropriate users:

• Developers and solution architects building or maintaining Norce integrations
• PIM managers, pricing managers, and operators who will use AI assistants as part of their regular workflow
• Support engineers diagnosing client environments

Not appropriate:

• End customers or end users of the storefronts
• Automated systems or pipelines that process large volumes of data continuously — these should connect to the Norce APIs directly, not through the MCP servers

Each person or team connecting the MCP servers should have their own OAuth2 client. Sharing credentials between users makes it impossible to audit who made a change and increases the impact if credentials are compromised.

Scoping OAuth2 clients

Given the all-or-nothing access model in v1, the most impactful scoping decisions are which environments to grant access to and who gets their own client.

Use separate clients for stage and production. This is the most impactful scoping decision. Stage credentials can be shared more broadly — mistakes on stage are recoverable. Production credentials should be restricted to users who specifically need to make changes in production and should not be used for day-to-day exploration.

Developers and solution architects typically need full access across all APIs. These clients should be created with care, connected to production only when needed, and rotated regularly.

If you need stricter access control today

If your use case requires finer-grained access control than the current model supports, the recommended approach is to build a proxy layer in front of the MCP servers — your own layer that holds the Norce credentials, enforces your access rules, and exposes its own auth mechanism to the AI client.

Production vs stage access

The most important access boundary is between stage and production. For teams working with the MCP servers regularly, the recommended pattern is:

1. Create separate OAuth2 clients for stage and production — even for the same user.
2. Use stage credentials by default. Keep production credentials disconnected from the AI client unless a production task is active.
3. If both are connected simultaneously, use a clear naming convention and an explicit instruction in your LLM context that prevents the AI from writing to production without confirmation. See Multi-environment setup.

Built-in write protection

The Backend MCP Servers include a built-in guard for write operations that reduces the risk of accidental changes. Each write operation is classified by impact, and stage is guarded as strictly as production:

• Lower-risk write operations — go through, with a warning attached to the result on stage and production so the change is visible and can be reviewed.
• Higher-risk write operations — refused on stage and production until the call is explicitly confirmed. This applies to bulk imports and other operations with wide data impact.
• A few destructive operations — such as deactivating a warehouse — are refused on every environment, including test, until explicitly confirmed.

The guard runs at the MCP server level and is always active. Treat it as protection against accidents, not as a security boundary: the confirmation is a parameter on the tool call, so a determined caller — including the AI itself, if instructed to — can supply it. The security boundary is the credential: anything the client's API access does not permit fails at the API level regardless of what the AI attempts. Note that v1 access is granted per API, not per operation — see Can I restrict the AI to read-only access for what that means in practice.

Credential storage and management

Credentials are stored in the AI client's local configuration file. Several practices reduce the risk of accidental exposure:

• Store credentials in the env block, not inline in the args array. Credentials in args may appear in process listings; credentials in env do not.
• Do not commit configuration files with credentials to version control. Add the MCP configuration file to your .gitignore.
• Rotate credentials regularly, especially for production clients. Treat MCP credentials with the same discipline as any other API key.
• Create a new OAuth2 client when a team member leaves — do not reuse or reassign their credentials. Revoke the old client and issue a new one.

What happens if credentials are compromised

If you suspect a credential set has been exposed:

1. Revoke the OAuth2 client immediately in Norce Admin under Settings > Users > OAUTH.
2. Create a new OAuth2 client with new credentials.
3. Update the MCP configuration with the new credentials and restart the AI client.

Because each user should have their own credentials, revoking a compromised client does not affect other users' access. The blast radius of a compromised credential is limited to what that client was permitted to do — which is why scoping credentials by role matters.

A read-only credential that is compromised cannot be used to change any data. A full-access production credential that is compromised can be used to modify or import data until it is revoked. This asymmetry is the strongest argument for using the narrowest scope possible for each user.

Frequently asked questions

Can I use the same OAuth2 client for all five MCP servers?

Yes. A single OAuth2 client with the appropriate API access rights can authenticate against all five Backend MCP Servers simultaneously. This simplifies credential management and is the recommended approach for a single environment.

Use separate clients only when you need different scopes for different servers — for example a read-only client for the Product MCP and a read-write client for the Pricing MCP.

Can the AI make changes without my knowledge?

The guard makes it hard to do by accident, but it is not a guarantee. Lower-risk writes go through with a warning in the result rather than a stop-and-ask; higher-risk writes are refused until explicitly confirmed, but the confirmation is a tool parameter the AI supplies. In practice this means every write is visible in the conversation, and reviewing what the AI reports after a change is part of using the servers responsibly. The hard restriction is the credential — anything its API access does not permit fails regardless of what the AI attempts.

For read operations, no confirmation is needed — reads do not change any data.

Does Norce log what the AI does?

The Backend MCP Servers use Norce's existing APIs, which are subject to Norce's standard API logging. Writes made through the MCP servers appear in the same audit trail as writes made through other API clients. This means activity is attributable to the OAuth2 client that was used, making per-user credentials important for accountability.

Can I restrict the AI to read-only access, or limit it to specific products or price lists?

Not through the current MCP server configuration. The v1 access model is all-or-nothing per API — enabling an API gives the credential access to all tools in that server, including writes. There is no built-in way to grant read-only access or restrict the AI to a specific subset of entities.

If you need this today, the recommended approach is a proxy layer in front of the MCP servers that enforces your own access rules. See If you need stricter access control today.

More granular access control is planned for a future release.

Is it safe to connect the MCP servers to a shared team AI account?

With caution. If multiple team members share an AI account and the same MCP credentials, it becomes difficult to attribute specific changes to individuals, and a shared credential has a wider blast radius if compromised. The recommended approach is one credential per user, connected to their own AI client. If shared access is unavoidable, scope the shared credential as narrowly as the v1 access model allows — stage rather than production, and only the APIs the shared use case needs — and treat the shared account as a read-and-inspect tool by convention.