Isolate each environment and release set

Learning objective

Isolate environments, configuration, credentials, and immutable agent versions in compatible release sets.

Core idea

A release set is your recorded combination of agents, prompts, model deployments, tools, orchestration code, and configuration that passes validation together. It is an application release artifact, not a Foundry object that automatically freezes every dependency. Environment isolation ensures that validating that set cannot accidentally execute against production accounts or alter production configuration.

For a multi-agent workflow, versioning only the coordinator leaves important behavior uncontrolled. Its specialists can change, a tool endpoint can adopt a different schema, and a model deployment name can point to a different model version. Define the compatible combination and the environment-specific bindings before promoting anything. See 4.3.1 for release-method selection and 4.3.4 for restoring the recorded combination.

How it works

Separate deployment targets from stage names

Use separate deployment targets for development, test, acceptance, and production according to your risk policy. For example, give production its own Foundry project and Container Apps deployment, with distinct tool endpoints and secret references. This is an architectural choice that you must provision and verify; calling a pipeline stage production does not create those resources.

The Foundry publishing documentation describes a project as a shared development workspace: people with project access can interact with its agents and share conversation context and permissions. Publishing creates an Agent Application with its own invocation URL, identity, and authorization scope. An Agent Application is therefore a concrete distribution mechanism, but publishing alone does not prove that its downstream tools and data are isolated from development.

Record a target map for each environment: project endpoint, agent identifiers, model deployment, tool service address, and credential source. Validate the map before executing acceptance cases. A correct container image connected to the wrong payment account is an isolation failure, even if its deployment is technically successful. Prefer checks of resolved resource identifiers over trusting a friendly environment label.

Freeze the configuration that defines behavior

Saved Foundry agent versions are immutable. Refer to prompt-based agents as <agent_name>:<version> and record the exact saved versions for the coordinator and each specialist. The prompt belongs to that agent definition; see 2.1.4 for prompt comparison and promotion. An identifier without its version does not supply the same evidence.

For hosted agents, each version snapshots the container image, resource allocation, environment variables, and protocol configuration. Environment variables are set per version and are immutable after creation. Changes require another version. Record the image artifact used to build that version and the dependency lockfile or build evidence alongside it, so the container implementation is traceable rather than identified only by an editable tag.

Container Apps also distinguishes configuration scopes. properties.template contains revision-scope settings such as container configuration and images; changing those settings creates a revision. properties.configuration contains application-scope settings such as ingress traffic rules and secret values; changes there apply across revisions without creating another revision. An immutable revision is therefore not proof that every runtime dependency remains fixed.

Use this distinction when deciding what belongs in the release record. Preserve the revision name and its template evidence, but also record the relevant application configuration and external bindings. A change outside the snapshot can invalidate acceptance results without changing the revision name.

Isolate credentials without embedding their values

Keep credential values out of the release record and agent instructions. Record the secret reference and the identity expected to retrieve it. See 4.1.6 for Key Vault retrieval and 4.1.7 for credential rotation. Here the release question is whether the environment uses the intended credential source and whether both active candidates remain authorized during their overlap.

Container Apps supports a Key Vault reference using keyvaultref with identityref. The managed identity must have permission to read the referenced secret. Its documented URI forms distinguish a specific secret version from a versionless reference. A URI ending in the secret version gives explicit selection; omitting it selects the latest version that exists in the vault.

For a versionless Key Vault reference, Container Apps retrieves an updated secret within 30 minutes and automatically restarts active revisions that reference it in an environment variable. For explicit adoption control, use a versioned URI and create a separately named application secret binding when candidates require different credentials. Do not overwrite a shared binding and assume the preceding revision still resolves its tested value.

Pinning a secret version is not permission to retain a revoked credential. Treat emergency rotation as a security constraint on every recoverable set. If a credential becomes unusable, rebuild and validate a replacement set rather than restoring that credential during rollback.

Record compatibility, not a collection of versions

The release record should identify which versions work together and where they were tested. The following fields describe an application-owned artifact, not a prescribed Microsoft schema:

For Azure OpenAI deployments that support automatic updates, versionUpgradeOption controls upgrade behavior. NoAutoUpgrade prevents automatic upgrading but makes the deployment stop working at retirement. Other policies can replace the model behind the deployment. Record the policy and resolved model version, rather than treating the deployment name as immutable. See 4.3.5 for model lifecycle governance.

Key distinctions and trade-offs

Environment isolation versus release compatibility: Isolation keeps production authority and data out of nonproduction validation. Compatibility ensures the selected components work together within an environment. You need both; perfect separation does not repair mismatched tool contracts.

Immutable definition versus mutable target: Agent versions and revisions freeze their documented configuration. A referenced tool service, model deployment, or secret source can have its own lifecycle. Evidence must cover the target as well as the reference.

Portable artifact versus environment binding: Promote the approved implementation, while resolving endpoints and identities separately for each target. Reusing a production credential in acceptance does not make acceptance more faithful; it changes the authority under which tests run.

Architecture / decision scenario

A procurement workflow has a coordinator and two specialists. Acceptance must never place a real order. The team creates distinct Foundry targets, tool accounts, and Container Apps deployments for acceptance and production. Its release record names all three saved agent versions, the orchestration artifact, and the tool schema accepted by the order adapter.

The acceptance revision resolves a nonproduction order endpoint and an acceptance-specific Key Vault secret reference. Production uses its own identity and binding. Before promotion, the team verifies the production endpoint map and checks published-agent permissions; project identity permissions do not automatically transfer on publishing.

A proposal to reuse one versionless secret binding for both production candidates fails the review: automatic secret adoption could change both without a revision change. The team records separate versioned bindings for the overlap, with a rotation plan that excludes revoked credentials. It also records the model version and upgrade policy so the set’s behavioral evidence has an explicit lifetime.

Common exam traps

• Treating pipeline environment names as resource isolation.
• Recording only the coordinator version in a multi-agent release.
• Assuming immutable hosted environment variables freeze external tool services.
• Expecting application-scope secret changes to create a Container Apps revision.
• Equating a model deployment name with a fixed model version.
• Including secret values in release evidence or restoring revoked credentials.

What to remember

Separate targets and authority first, then record the compatible components tested together. Preserve exact agent and runtime versions, environment bindings, and external dependency evidence. A release set is reproducible only within the availability, permission, and lifecycle constraints of everything it references.

Knowledge check

References

• Microsoft, Agent development lifecycle in Microsoft Foundry
• Microsoft, Agent applications in Microsoft Foundry
• Microsoft, Hosted agents in Foundry Agent Service
• Microsoft, Update and deploy changes in Azure Container Apps
• Microsoft, Manage secrets in Azure Container Apps
• Microsoft, Azure OpenAI in Microsoft Foundry Models working with models