AI Safety and DevOps Strategy

AI as a development tool can be effective and can speed developers up tremendously, but using AI for development without safety controls is irresponsible. We Summit Mountains has developed sophisticated environment controls to give power to our team to use AI while removing all risks we are aware of.

The biggest risks we have identified so far:

Our DevOps pipeline is built on two safety principles:

1. AI tools are unable to change production.
2. Humans must validate and QA all changes (Human and AI) before deployment.

Every stage is engineered so that an AI mistake cannot silently propagate into a client-facing system. Depending on the client, the pipeline can look different, but the ideal pipeline runs across these sequential stages:

1. Development (Dev Sandbox)
2. Merge Testing (ideally in a Dev Sandbox, but could also be performed inside of a user testing environment that is not production)
3. Training & Fit Testing (User Testing Environment like Partial Sandboxes or Full Copy Sandboxes)
4. Production Deployment (100% Human Deployment)
5. Production Feedback

All deployments other than deployment to production can be orchestrated by our DevOps AI agent, ASPEN.

Work moves between Salesforce orgs using GitHub as the system of record, which gives us a complete, auditable, and reversible history of every change made by either a human or an AI.

The Development stage is where work can be done either by a human developer or by an AI agent directed by a human. All of that work happens inside a Dev Sandbox, which is the only environment where new metadata or new code is authored. The Dev Sandbox is fully isolated from production, so anything that goes wrong here is contained.

Smoke testing happens at the end of this stage so that broken work never leaves the Dev Sandbox. Whether the change was authored by a person or by an AI under human direction, it has to pass smoke testing before it is eligible to move into Merge Testing.

Once a change has been smoke-tested in the Dev Sandbox, it needs to be merged with everything else that is in flight and validated as a whole. Merge testing is ideally performed in a Dev Sandbox dedicated to merging, but it can also be performed inside of a user testing environment (that is not production !).

The goal is simple: confirm that all of the changes work together if there's any crossover between the two different development features. Anything failures are patched in the originating Dev Sandbox, so the GitHub source of truth always reflects reality. ASPEN can orchestrate this merge and the deployment into the merge environment, because the target is never production.

Once the merge is clean, the combined release is deployed into a User Testing Environment (typically a Partial Copy Sandbox or a Full Copy Sandbox). This is where real users from the client team validate the release against their actual workflows, with real-shaped data, before anything is allowed to approach production.

Two kinds of testing happen here:

ASPEN can orchestrate the deployment from merge testing into the User Testing Environment, because the User Testing Environment is still not production.

This is the deliberate choke point in our pipeline. Once Training & Fit Testing has signed off, the move to production is performed by a human, every time. ASPEN does not deploy to production. ASPEN does not have credentials to deploy to production. By design.

The deployment uses the same project GitHub repo as the source of truth, deploying the validated package set into the production org. If anything goes wrong, the GitHub history makes the rollback easy.

Once a release is live, real users provide feedback against real production data. That feedback shapes the next round of development work back at Stage 1, closing the loop. The AI agent has no write path into the production org at this stage or any other, so there is no way for production feedback to be acted on by an AI without first passing back through human-validated Dev, Merge, and Fit Testing stages.

Our development AI agents are never allowed to change any data or metadata inside of a production org. That is the single most important rule in our entire DevOps strategy.

However, AI is most useful for debugging when it can see what is actually happening in production. To support that without compromising the rule above, we expose production to AI through a dedicated MCP server that is hard-wired to be read only. Through that read-only channel, an AI agent can:

1. Read debug logs from production
2. Read Flow errors and Flow execution history
3. Read Apex errors and exception emails
4. Read object and field metadata for diagnosis

What the MCP server cannot do, by construction:

1. Update, insert, or delete records
2. Modify metadata or deploy code
3. Run anonymous Apex or invoke Flows
4. Grant itself any permission it does not already have

The read-only constraint is enforced at the MCP server boundary, not just by policy. There is no API surface, no credential, and no code path by which the AI can write to production.

The safety properties of our DevOps pipeline are not accidents. They are the explicit goal of the architecture:

1. AI tools are unable to change production. Period.
2. Humans validate and QA every change, AI-authored or human-authored, before it deploys.
3. AI agents only operate inside a Dev Sandbox and only under direct human direction.
4. Every change is smoke-tested in the Dev Sandbox, merge-tested together, and fit-tested with real users before it can reach production.
5. GitHub is the system of record, giving full auditability and reversibility for every change.
6. Production deployment is 100% human. ASPEN has no credentials to push to prod.
7. AI access to production is read-only and enforced at the MCP server boundary, not just by policy.

The result is a development pipeline that captures the speed of AI-assisted development while ensuring that no AI mistake, and no AI hallucination, can ever directly impact a clientΓÇÖs production Salesforce org.