SaaS Connector Environment Isolation & Credential Design Risk

Issue in ./help/landing/saas.md

Dear Adobe Commerce Product & Engineering Team,

I am writing to formally raise a serious concern regarding the architectural design of the Commerce Services Connector and SaaS integration model, specifically in relation to environment isolation and credential handling.

This concern is based on a real incident that occurred while working in a staging environment and has highlighted what I believe to be a structural design risk within the current implementation.

Summary of the Issue

After synchronising a stripped production database to a staging environment, the production SaaS identifier remained selected in the configuration. At the client’s request, Live Search needed to be enabled on staging for testing purposes.

Initially, sandbox keys were entered, but the service did not activate. The official documentation states that all four keys (Production and Sandbox, Public and Private) are required when selecting or creating a SaaS project. Following this guidance, production keys were also entered.

Because the production SaaS identifier persisted from the database clone, the staging environment began interacting with the production SaaS data space once the service was activated.

At no point was it expected that enabling services on staging could impact live production data. However, incorrect host information was subsequently published to production.

This was operationally disruptive and professionally damaging. After more than 20 years working in enterprise systems, it is not reasonable to expect that a staging environment could affect production merely through configuration persistence.

Technical Concerns
1. Lack of Enforced Environment Isolation
A cloned production database retains its SaaS identifier and associated configuration. There is no automatic re-binding, invalidation, or warning when an environment changes.
2. Simultaneous Storage of Production and Sandbox Credentials
The connector UI allows both Production and Sandbox keys to be entered and stored at the same time. There is no enforced mutual exclusivity or environment activation toggle.
3. Four-Key Requirement
The documentation explicitly states that all four keys are required to select or create a SaaS project. This design makes it technically possible for a non-production Commerce instance to authenticate against production SaaS services.
4. No Host or Domain Validation
The system does not validate that the Commerce base URL matches the intended SaaS environment before allowing publishing. A simple host verification mechanism could significantly reduce cross-environment risk.
5. Reliance on Documentation Rather Than Safeguards
The documentation clarifies that Production and Sandbox refer to SaaS data spaces rather than Commerce environments. However, this distinction is not enforced programmatically. The system relies entirely on procedural awareness rather than architectural barriers.

This is not a defect in code execution. The system is behaving as designed. The concern is that the design itself allows cross-environment contamination under standard operational workflows (e.g., production-to-staging database sync).

Expected Enterprise Behaviour

In modern enterprise architecture, environment isolation is typically enforced by design, not by documentation warning. Reasonable safeguards would include:

• Allowing only one active credential pair (Production OR Sandbox) at a time
• Explicit environment binding confirmation before activation
• Automatic invalidation or reset of SaaS identifiers after database cloning
• Host/domain validation prior to publishing
• Clear visual indication of active SaaS data space and risk level

Without these safeguards, staging systems can unintentionally affect production services, particularly in workflows involving database cloning and client-requested testing.

Request for Review

I respectfully request:
1. A formal architectural review of the SaaS connector environment isolation model
2. Clarification on whether enhanced environment safeguards are planned
3. Consideration of design changes to prevent cross-environment publishing
4. Documentation updates that more strongly highlight the operational risk

This issue is not theoretical. It has already resulted in unintended production impact.

Adobe Commerce is positioned as an enterprise platform. Enterprise systems must enforce environment separation at system level. Relying on documentation warnings for isolation is not sufficient.

I would appreciate confirmation that this concern has been escalated to the appropriate product and engineering teams.

Kind regards,

Start by reading ./help/landing/saas.md, especially its explanation of Production and Sandbox SaaS data spaces and the four-key requirement. Review the reported staging database-clone scenario and the requested isolation safeguards with the product and engineering teams; done requires an agreed architectural response and any confirmed documentation updates.

Written by the indexing model from the issue text.