Document ProcessContainer ingress behavior by bbonaby · Pull Request #1081 · microsoft/mxc

Branden Bonaby (bbonaby) · 2026-09-01T18:53:44Z

📖 Description

Documents ProcessContainer ingress behavior across the networking reference, support matrix, schema guide, and example.
Replaces the old universal capability guidance and clarifies compatibility, host-loopback, and conditional firewall requirements.

🔗 References

Contract: Add Process Security Environment ingress contract #1076
Runtime implementation: Enforce ProcessContainer ingress policy #1080

🔍 Validation

Documentation-only change.

✅ Checklist

Signed the Contributor License Agreement
Linked to an issue
Updated documentation (if applicable)
Updated Copilot instructions (if build, architecture, or conventions changed)
If this PR changes Cargo.lock, the dependency-feed-check check passes (see docs/pull-requests.md)

📋 Issue Type

Bug fix
Feature
Task

azure-pipelines · 2026-09-01T18:53:53Z

Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run.

Copilot

Copilot review overview

🟡 Changes recommended

The support documentation contains inaccurate compatibility and contract-source details.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Balanced
Findings: 3

New issues introduced by this change (3)

Severity	Finding
	`docs/process-container/networking.md` — This preservation claim does not hold for `egress.default: "allow"` with `ingress.default: "deny"`…
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1…
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native…

What changed in this PR

Clarifies schema 0.8 ProcessContainer networking and fallback behavior.

Changes:

Documents native ingress enforcement and compatibility behavior.
Updates proxy requirements, examples, and support matrices.
Aligns repository guidance with the revised terminology.

File	Description
`docs/sandbox-policy/0.8.0/networking/schema-updates.md`	Clarifies schema migration behavior.
`docs/sandbox-policy/0.8.0/networking/networking.md`	Revises ProcessContainer enforcement guidance.
`docs/process-container/os-version-support.md`	Updates OS capabilities and fallback documentation.
`docs/process-container/networking.md`	Documents networking and proxy behavior.
`docs/process-container/examples/0.8.0-schema.md`	Revises proxy configuration examples.
`.github/copilot-instructions.md`	Updates architecture guidance.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Copilot

Copilot review overview

🟡 Changes recommended

The documentation contains inconsistent policy behavior and references an update not yet generally available.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Balanced
Findings: 3

New issues introduced by this change (1)

Severity	Finding
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:…

Pre-existing issues (2)

Severity	Finding
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View comment

Issues resolved since last review (1)

Severity	Finding
	`docs/process-container/networking.md` — This preservation claim does not hold for `egress.default: "allow"` with `ingress.default: "deny"`… View resolved comment

Suppressed comments (1)

docs/process-container/networking.md:38

Apply the native-versus-compatibility split to the allow/deny row as well. With native ingress, egress governs outbound public and private destinations independently, so private-network outbound is allowed while inbound remains denied; the existing row above still says all private-network traffic is denied, which only describes the compatibility capability mapping.

| `allow` | `allow` | Both capabilities | Native PSEC uses `internetClient` plus native ingress; compatibility paths use both capabilities. |

Copilot

Copilot review overview

🔵 Needs a closer look

Native-ingress and firewall guidance remains inconsistent within the documentation and its linked canonical example.

Review tier: Balanced
Findings: 3

Pre-existing issues (3)

Severity	Finding
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:… View comment
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View comment

Suppressed comments (2)

docs/process-container/networking.md:202

The canonical schema 0.8 example linked above still states unconditionally that the client uses privateNetworkClientServer and that a packaged proxy requires inbound firewall authorization (docs/process-container/examples/0.8.0-schema.md:44-57,113-114). That now contradicts both the native-ingress behavior and this temporary-update qualification, so update the example in this PR as well.

> [!IMPORTANT]
> Until the September 2026 Windows updates are installed on Windows 11 24H2 or later, proxy inbound traffic still
> requires a firewall rule. Add the rule manually or declare it in the proxy's MSIX package. Updated builds no longer
> require this rule.

docs/process-container/networking.md:165

This new native-ingress wording conflicts with the sentence immediately above, which still says MXC always grants a private-network capability selected by ingress.default. Native PSEC deliberately removes privateNetworkClientServer; describe the native-policy/compatibility-capability split consistently here.

The identity-scoped and host-loopback paths are mutually exclusive. When `allowedProxyPeer` is present, MXC resolves
the package family or AppContainer profile and applies native ingress or the compatibility capability selected by
`ingress.default`.

Copilot

Copilot review overview

🔵 Needs a closer look

The networking guide still contradicts the newly documented native-ingress capability behavior.

Review tier: Balanced
Findings: 3

Pre-existing issues (3)

Severity	Finding
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:… View comment
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View comment

Suppressed comments (1)

docs/process-container/networking.md:165

This now describes the native-ingress/compatibility split, but the immediately preceding sentence still says MXC always “grants the private-network capability selected by ingress.default.” That contradicts this PR’s documented native PSEC behavior, where privateNetworkClientServer is omitted. Please make the whole paragraph conditional so readers do not expect that capability on native-ingress hosts.

the package family or AppContainer profile and applies native ingress or the compatibility capability selected by
`ingress.default`.

Copilot

Copilot review overview

🟡 Changes recommended

The revised guidance contains directional inaccuracies and conflicts with linked canonical documentation.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Balanced
Findings: 4

New issues introduced by this change (1)

Severity	Finding
	`docs/process-container/networking.md` — Native ingress is directional inbound policy, so it is not the mechanism that gives the client…

Pre-existing issues (3)

Severity	Finding
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:… View comment
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View comment

Suppressed comments (2)

docs/process-container/networking.md:38

The egress: allow / ingress: deny row still presents the compatibility result as universal. Native PSEC removes privateNetworkClientServer and applies egress independently (also stated at lines 24 and 283–285), so private-network outbound is allowed while LAN/private inbound remains denied. Distinguish native and compatibility results in this matrix.

| `deny` | `deny` | None | Internet and private-network traffic are denied. |
| `allow` | `deny` | `internetClient` | Internet outbound is allowed; private-network traffic is denied. |
| `deny` | `allow` | `privateNetworkClientServer` | Native PSEC permits inbound independently. Older PSEC pairs the capability with WFP outbound blocking; the AppContainer fallback rejects this combination. |
| `allow` | `allow` | Both capabilities | Native PSEC uses `internetClient` plus native ingress; compatibility paths use both capabilities. |

docs/process-container/networking.md:31

This clarification leaves the documents linked as authoritative sources contradictory. docs/sandbox-policy/0.8.0/networking/networking.md:72-74,379-382,420-421 still says ProcessContainer private traffic universally follows ingress.default, and docs/process-container/examples/0.8.0-schema.md:44-47 still says Windows always grants the bidirectional capability. Update those references alongside this behavior change so readers do not receive the pre-native-ingress model from the canonical links.

Newer PSEC contracts enforce `ingress` natively and remove the policy-owned
`privateNetworkClientServer` capability. Older contracts retain the bidirectional capability mapping, with WFP
narrowing outbound access where available. The AppContainer fallback rejects combinations that its capability mapping
cannot preserve. `ingress.hostLoopback: "allow"` requires native ingress support.

Copilot

Copilot review overview

🟡 Changes recommended

Several updated passages conflict with the directional model and leave the canonical proxy example outdated.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Balanced
Findings: 5

New issues introduced by this change (1)

Severity	Finding
	`docs/process-container/networking.md` — This exception conflicts with the immediately preceding claim that the scoped peer rule does not…

Pre-existing issues (4)

Severity	Finding
	`docs/process-container/networking.md` — Native ingress is directional inbound policy, so it is not the mechanism that gives the client… View comment
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:… View comment
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View comment

Suppressed comments (4)

docs/process-container/networking.md:37

The matrix still retains compatibility-only behavior in the preceding allow/deny row. With native PSEC, ingress is independent and egress.default: "allow" permits public and private outbound traffic while inbound remains denied; only compatibility paths deny private-network traffic without privateNetworkClientServer. Please distinguish those results in the row.

| `deny` | `allow` | `privateNetworkClientServer` | Native PSEC permits inbound independently. Older PSEC pairs the capability with WFP outbound blocking; the AppContainer fallback rejects this combination. |

docs/process-container/networking.md:70

Native ingress controls inbound traffic; it is not what gives the client outbound access to the proxy. The native path carries the proxy/WFP policy without privateNetworkClientServer, so describing client access as an ingress-policy requirement contradicts the directional behavior documented above.

| Client private-network access | Native PSEC ingress policy; `privateNetworkClientServer` on compatibility PSEC |

docs/process-container/networking.md:165

This paragraph remains internally inconsistent: line 161 says MXC always grants a private-network capability selected by ingress.default, while these new lines correctly distinguish native ingress from compatibility capabilities. Update the earlier sentence so readers are not told that native PSEC still grants privateNetworkClientServer.

the package family or AppContainer profile and applies native ingress or the compatibility capability selected by
`ingress.default`.

docs/process-container/networking.md:31

The linked canonical example still states that Windows always implements this policy with bidirectional privateNetworkClientServer and requires that capability for the packaged proxy (examples/0.8.0-schema.md:45-57). That now contradicts this native-ingress description, so the example must be updated in the same documentation change.

Newer PSEC contracts enforce `ingress` natively and remove the policy-owned
`privateNetworkClientServer` capability. Older contracts retain the bidirectional capability mapping, with WFP
narrowing outbound access where available. The AppContainer fallback rejects combinations that its capability mapping
cannot preserve. `ingress.hostLoopback: "allow"` requires native ingress support.

Copilot

Copilot review overview

🔵 Needs a closer look

The updated guidance conflicts with existing schema documentation and includes an unreleased Windows-update claim.

Review tier: Balanced
Findings: 5

Pre-existing issues (5)

Severity	Finding
	`docs/process-container/networking.md` — The linked parent contract and canonical example still describe every ProcessContainer as mapping… View comment
	`docs/process-container/networking.md` — The parent schema 0.8 networking document linked above still states that every ProcessContainer… View comment
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:… View comment
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View comment

Suppressed comments (2)

docs/process-container/networking.md:167

This new distinction conflicts with the immediately preceding sentence, which still says MXC always “grants the private-network capability selected by ingress.default.” On OS-ingress-capable PSEC that capability is explicitly omitted, so the deployment description should use the same conditional wording.

the package family or AppContainer profile and applies the OS ingress policy or the compatibility capability selected
by `ingress.default`.

docs/process-container/networking.md:31

The other schema-0.8 ProcessContainer references remain inconsistent with this new behavior. docs/process-container/examples/0.8.0-schema.md:44-47 still says the MXC client always receives privateNetworkClientServer and permits server traffic, while docs/sandbox-policy/0.8.0/networking/networking.md:379-382,413-435 describes that capability as mandatory on every ProcessContainer path. Please update those references so readers do not get contradictory enforcement guarantees.

Newer PSEC contracts enforce `ingress` through the OS ingress policy and remove the policy-owned
`privateNetworkClientServer` capability. Older contracts retain the bidirectional capability mapping, with WFP
narrowing outbound access where available. The AppContainer fallback rejects combinations that its capability mapping
cannot preserve. `ingress.hostLoopback: "allow"` requires OS ingress policy support.

Copilot

Copilot review overview

🟡 Changes recommended

The firewall note presents an unreleased September 2026 Windows update as already available.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Balanced
Findings: 5

Pre-existing issues (5)

Severity	Finding
	`docs/process-container/networking.md` — The linked parent contract and canonical example still describe every ProcessContainer as mapping… View comment
	`docs/process-container/networking.md` — The parent schema 0.8 networking document linked above still states that every ProcessContainer… View comment
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:… View comment
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View comment

Copilot

Copilot review overview

🔵 Needs a closer look

The new firewall exception conflicts with existing proxy guidance and the canonical example.

Review tier: Balanced
Findings: 5

Pre-existing issues (5)

Severity	Finding
	`docs/process-container/networking.md` — The linked parent contract and canonical example still describe every ProcessContainer as mapping… View comment
	`docs/process-container/networking.md` — The parent schema 0.8 networking document linked above still states that every ProcessContainer… View comment
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:… View comment
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View comment

Suppressed comments (1)

docs/process-container/networking.md:204

The build-dependent exception leaves the proxy guidance inconsistent: lines 191–196 still say the scoped peer does not bypass Windows Firewall, and docs/process-container/examples/0.8.0-schema.md:113-114 still requires the canonical example's inbound rule to cover the proxy port, while this says updated builds need no rule. Please qualify the earlier guidance as applying only to pre-update systems and update the canonical example so users on updated builds are not told to provision an unnecessary administrator/package rule.

> Until the September 2026 Windows updates are installed on Windows 11 24H2 or later, proxy inbound traffic still
> requires a firewall rule. Add the rule manually or declare it in the proxy's MSIX package. Updated builds no longer
> require this rule.

Copilot

Copilot review overview

🔵 Needs a closer look

Related documentation remains contradictory, and the update guidance describes unreleased behavior as available.

Review tier: Balanced
Findings: 5

Pre-existing issues (5)

Severity	Finding
	`docs/process-container/networking.md` — The linked parent contract and canonical example still describe every ProcessContainer as mapping… View comment
	`docs/process-container/networking.md` — The parent schema 0.8 networking document linked above still states that every ProcessContainer… View comment
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:… View comment
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View comment

Suppressed comments (1)

docs/process-container/networking.md:31

These semantics now conflict with the other schema 0.8 guidance this page directs readers to. docs/sandbox-policy/0.8.0/networking/networking.md:73-74,379-385,413-435 still says ProcessContainer always relies on the bidirectional capability, and docs/process-container/examples/0.8.0-schema.md:44-47 says every proxy grants it and permits server traffic. Those statements are false when PSEC uses native ingress and omits the capability, so please update the related documentation in this PR to keep the contract guidance consistent.

Newer PSEC contracts enforce `ingress` through the OS ingress policy and remove the policy-owned
`privateNetworkClientServer` capability. Older contracts retain the bidirectional capability mapping, with WFP
narrowing outbound access where available. The AppContainer fallback rejects combinations that its capability mapping
cannot preserve. `ingress.hostLoopback: "allow"` requires OS ingress policy support.

Copilot

Copilot review overview

🔵 Needs a closer look

The canonical schema 0.8 example still documents the obsolete bidirectional capability behavior.

Review tier: Balanced
Findings: 5

Pre-existing issues (5)

Severity	Finding
	`docs/process-container/networking.md` — The linked parent contract and canonical example still describe every ProcessContainer as mapping… View comment
	`docs/process-container/networking.md` — The parent schema 0.8 networking document linked above still states that every ProcessContainer… View comment
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:… View comment
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View comment

Suppressed comments (1)

docs/process-container/networking.md:31

The linked canonical schema 0.8 example still says that ingress.default: "allow" always grants privateNetworkClientServer and therefore permits private-network server traffic (docs/process-container/examples/0.8.0-schema.md:44-47). That now contradicts this native-ingress behavior and can give readers the wrong security posture depending on which ProcessContainer page they follow. Please update the canonical example and its firewall guidance as part of this documentation change.

Newer PSEC contracts enforce `ingress` through the OS ingress policy and remove the policy-owned
`privateNetworkClientServer` capability. Older contracts retain the bidirectional capability mapping, with WFP
narrowing outbound access where available. The AppContainer fallback rejects combinations that its capability mapping
cannot preserve. `ingress.hostLoopback: "allow"` requires OS ingress policy support.

Copilot

Copilot review overview

🔵 Needs a closer look

The networking guide contains contradictory descriptions of compatibility enforcement and firewall requirements.

Review tier: Balanced
Findings: 5

Pre-existing issues (5)

Severity	Finding
	`docs/process-container/networking.md` — The linked parent contract and canonical example still describe every ProcessContainer as mapping… View comment
	`docs/process-container/networking.md` — The parent schema 0.8 networking document linked above still states that every ProcessContainer… View comment
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:… View comment
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View comment

Suppressed comments (3)

docs/process-container/networking.md:167

The preceding sentence still says MXC always grants a private-network capability, which contradicts the newly documented PSEC behavior here: with OS ingress support, privateNetworkClientServer is omitted and ingress is serialized instead. Update that sentence to distinguish the native and compatibility paths.

the package family or AppContainer profile and applies the OS ingress policy or the compatibility capability selected
by `ingress.default`.

docs/process-container/networking.md:192

This unconditional statement conflicts with the new note below that updated builds no longer require a firewall rule. Qualify it with the pre-update OS scope so readers on updated systems are not given contradictory requirements.

The scoped peer rule does not bypass Windows Firewall's block-inbound-to-non-allowed-apps policy. A packaged
AppContainer proxy uses the package-owned firewall

docs/process-container/networking.md:74

This row covers both PSEC variants, but it now describes only the newer directional path. On compatibility PSEC, ingress.default: "allow" still grants the bidirectional privateNetworkClientServer capability (as the preceding row notes), while WFP narrows only client egress. Please state both enforcement modes here.

| Enforcement | The OS ingress policy is directional; WFP permits client egress only to the configured proxy endpoint |

Copilot

Copilot review overview

🔵 Needs a closer look

The networking guidance conflicts with linked examples and includes an unreleased update claim without a verifiable build floor.

Review tier: Balanced
Findings: 5

Pre-existing issues (5)

Severity	Finding
	`docs/process-container/networking.md` — The linked parent contract and canonical example still describe every ProcessContainer as mapping… View comment
	`docs/process-container/networking.md` — The parent schema 0.8 networking document linked above still states that every ProcessContainer… View comment
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:… View comment
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View comment

Suppressed comments (2)

docs/process-container/networking.md:31

The canonical schema example linked later in this document still says every ProcessContainer implements ingress.default: "allow" with privateNetworkClientServer and therefore permits server traffic (docs/process-container/examples/0.8.0-schema.md:44-47). That is now false on OS-ingress-capable PSEC hosts. Please update that example in this PR so users are not given two incompatible descriptions of the same schema 0.8 policy.

Newer PSEC contracts enforce `ingress` through the OS ingress policy and remove the policy-owned
`privateNetworkClientServer` capability. Older contracts retain the bidirectional capability mapping, with WFP
narrowing outbound access where available. The AppContainer fallback rejects combinations that its capability mapping
cannot preserve. `ingress.hostLoopback: "allow"` requires OS ingress policy support.

docs/process-container/networking.md:167

This still conflicts with the immediately preceding sentence, which says MXC always “grants the private-network capability.” On OS-ingress-capable PSEC, the implementation removes that policy-owned capability. Consolidate the paragraph so it describes the conditional encoding consistently.

The identity-scoped and host-loopback paths are mutually exclusive. When `allowedProxyPeer` is present, MXC resolves
the package family or AppContainer profile and applies the OS ingress policy or the compatibility capability selected
by `ingress.default`.

Copilot

Copilot review overview

🔵 Needs a closer look

Fallback fidelity is overstated, and the future servicing requirement lacks a verifiable build floor.

Review tier: Balanced
Findings: 5

Pre-existing issues (5)

Severity	Finding
	`docs/process-container/networking.md` — The linked parent contract and canonical example still describe every ProcessContainer as mapping… View comment
	`docs/process-container/networking.md` — The parent schema 0.8 networking document linked above still states that every ProcessContainer… View comment
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:… View comment
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View comment

Suppressed comments (1)

docs/process-container/networking.md:31

This overstates fallback fidelity. egress.default: "allow" with ingress.default: "deny" is accepted by the AppContainer validator, but it receives only internetClient, so requested private-network egress remains unavailable (as row 36 notes). The fallback rejects mappings that would over-grant access, while accepted mappings can still be more restrictive.

narrowing outbound access where available. The AppContainer fallback rejects combinations that its capability mapping
cannot preserve. `ingress.hostLoopback: "allow"` requires OS ingress policy support.

Copilot

Copilot review overview

🔵 Needs a closer look

The documentation contains contradictory capability guidance and prematurely describes an unreleased Windows update.

Review tier: Balanced
Findings: 5

Pre-existing issues (5)

Severity	Finding
	`docs/process-container/networking.md` — The linked parent contract and canonical example still describe every ProcessContainer as mapping… View comment
	`docs/process-container/networking.md` — The parent schema 0.8 networking document linked above still states that every ProcessContainer… View comment
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:… View comment
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View comment

Suppressed comments (2)

docs/process-container/networking.md:31

This new OS-ingress distinction leaves the linked schema example contradictory: docs/process-container/examples/0.8.0-schema.md:44-47 still says every such request is implemented with privateNetworkClientServer and therefore permits private-network server traffic. That is false on the newly documented OS-ingress path, which removes that capability. Update the companion example to distinguish OS ingress enforcement from compatibility mapping.

Newer Windows builds enforce `ingress` through the OS ingress policy and remove the policy-owned
`privateNetworkClientServer` capability. Compatibility paths retain the bidirectional capability mapping, with WFP
narrowing outbound access where available. The AppContainer fallback rejects combinations that its capability mapping
cannot preserve. `ingress.hostLoopback: "allow"` requires OS ingress policy support.

docs/process-container/networking.md:165

This conditional OS-policy/capability wording conflicts with line 161 immediately above, which still says MXC always grants a private-network capability selected by ingress.default. On OS-ingress-capable hosts that capability is explicitly omitted, so consolidate the paragraph around the new distinction.

the package family or AppContainer profile and applies the OS ingress policy or the compatibility capability selected
by `ingress.default`.

azure-pipelines · 2026-09-02T16:22:14Z

Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run.

Copilot

Copilot review overview

🟡 Changes recommended

The updated guidance conflicts with the parent specification, misstates identity-less proxy fallback, and references an unpublished update.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Balanced
Findings: 6

New issues introduced by this change (1)

Severity	Finding
	`docs/process-container/networking.md` — The PR says it replaces the universal bidirectional-capability guidance, but the parent GA document…

Pre-existing issues (5)

Severity	Finding
	`docs/process-container/networking.md` — The linked parent contract and canonical example still describe every ProcessContainer as mapping… View comment
	`docs/process-container/networking.md` — The parent schema 0.8 networking document linked above still states that every ProcessContainer… View comment
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:… View comment
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View comment

Suppressed comments (1)

docs/process-container/networking.md:139

This identity-less configuration has hostLoopback: "allow", so it cannot run on a compatibility path: the runtime rejects that value unless the PSEC support query reports native ingress support, as this page also says at lines 108-109 and 266-270. Saying compatibility paths grant the capability implies this deployment can fall back. State that this deployment requires OS ingress support and that compatibility paths reject it.

When OS ingress policy support is available, MXC enforces `ingress.default: "allow"` directly; compatibility paths
grant `privateNetworkClientServer`. MXC identifies this proxy only by the configured endpoint and enables

Explain directional ingress support and compatibility-path limits across the ProcessContainer and schema 0.8 networking documentation. Clarify host proxy, deny-path, and conditional firewall behavior so the guidance matches runtime enforcement. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: e995fbb0-4ea4-4aa3-a8bb-efa0d3bf01a4

Branden Bonaby (bbonaby) · 2026-09-02T18:55:16Z

Copilot review

Copilot

Copilot review overview

🟡 Changes recommended

The connectivity summary omits a mandatory proxy setting, and the direction-default matrix misstates private-network outbound behavior.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Balanced
Findings: 1

New issues introduced by this change (1)

Severity	Finding
	`docs/sandbox-policy/0.8.0/networking/networking.md` — The ProcessContainer Model 2 requirements no longer mention that `network.ingress.default` must be…

Issues resolved since last review (6)

Severity	Finding
	`docs/process-container/networking.md` — The PR says it replaces the universal bidirectional-capability guidance, but the parent GA document… View resolved comment
	`docs/process-container/networking.md` — The linked parent contract and canonical example still describe every ProcessContainer as mapping… View resolved comment
	`docs/process-container/networking.md` — The parent schema 0.8 networking document linked above still states that every ProcessContainer… View resolved comment
	`docs/process-container/networking.md` — The newly documented native-ingress behavior now contradicts the linked schema 0.8 documentation:… View resolved comment
	`docs/process-container/os-version-support.md` — The sources list now points only to the legacy BaseContainer FlatBuffer bindings, but the native… View resolved comment
	`docs/process-container/os-version-support.md` — This note still treats the legacy `SANDBOX_CAP_DENY_PATHS` probe as the sole T1 gate, but native T1… View resolved comment

Suppressed comments (1)

docs/process-container/networking.md:33

The matrix still says the egress: allow / ingress: deny combination denies all private-network traffic, which contradicts the newly documented directional behavior: with OS ingress support, egress allows private-network outbound while ingress denies inbound. Only compatibility paths lose private-network outbound because they cannot grant the bidirectional capability. Split the result by path so this central matrix reflects the behavior described below.

| Egress default | Ingress default | Compatibility capabilities | Result |

Co-authored-by: bbonaby <105318831+bbonaby@users.noreply.github.com>

Copilot · 2026-09-02T19:06:00Z

Copilot review

Reviewed the doc changes against the runtime in 2e52d5e and fixed four issues in 332a5a9:

docs/process-container/networking.md: the proxy paragraph still said MXC "grants the private-network capability selected by ingress.default", contradicting the OS-ingress path where privateNetworkClientServer is omitted.
Restored the unconditional ingress.default: "allow" requirement for runtimeConfig.networkProxy (enforced in network_parser.rs regardless of OS ingress support) in examples/0.8.0-schema.md and the GA doc's Model 2 bullet; only the capability-grant consequence is now scoped to compatibility paths.
Restored the unconditional inbound firewall requirement — nothing in the runtime probes or reports Windows Firewall behavior, so the "depends on the installed Windows build" conditional was untestable guidance.
Replaced "Newer Windows builds…" with probe-conditional wording ("hosts that report OS ingress policy support"), matching os-version-support.md, since the behavior is selected by the PSEC support flag and not by a build floor.

Also qualified the leftover "capability gate" prose in schema-updates.md so it reads as compatibility-path behavior.

Copilot

Copilot review overview

🔵 Needs a closer look

The documentation contains unresolved moderate inaccuracies about AppContainer fallback, firewall requirements, and runtime support probing.

Review tier: Balanced
Findings: None

Issues resolved since last review (1)

Severity	Finding
	`docs/sandbox-policy/0.8.0/networking/networking.md` — The ProcessContainer Model 2 requirements no longer mention that `network.ingress.default` must be… View resolved comment

Suppressed comments (5)

docs/process-container/networking.md:30

This still overstates AppContainer fallback rejection. The validator rejects ingress: allow with denied egress because the bidirectional capability would broaden access, but it accepts egress: allow with ingress: deny even though private-network outbound is unavailable (as documented later at lines 262–267). State both directions explicitly instead of claiming every unpreservable combination is rejected.

narrowing outbound access where available. The AppContainer fallback rejects combinations that its capability mapping

docs/process-container/networking.md:282

This broad rejection claim conflicts with the compatibility limitation above: AppContainer accepts egress.default: "allow" with ingress.default: "deny", but cannot provide the requested private-network outbound access. Name the one rejected asymmetric direction rather than implying all unpreservable asymmetric requests fail.

AppContainer fallback rejects asymmetric policy it cannot preserve.

docs/process-container/networking.md:195

This now makes firewall authorization unconditional, contradicting the PR's stated “conditional firewall requirements” and the resolved requirement that it is needed only when the installed build lacks equivalent OS enforcement. Restore the build-dependent qualification so users on builds providing that enforcement are not instructed to add an unnecessary firewall rule.

Neither the scoped peer rule nor the private-network access granted to the MXC client container bypasses Windows
Firewall's block-inbound-to-non-allowed-apps policy for the proxy process. A packaged AppContainer proxy uses the
package-owned firewall declaration shown in the
[schema 0.8 examples](examples/0.8.0-schema.md); its application entry uses
`uap10:RuntimeBehavior="packagedClassicApp"` with `uap10:TrustLevel="appContainer"`. An unpackaged AppContainer proxy
requires its installer or administrator to own an equivalent rule scoped to the AppContainer profile SID, proxy
executable, and configured port.

docs/process-container/os-version-support.md:123

The updated row now covers the active contract, but the note immediately below still describes only the legacy SBOX SANDBOX_CAP_* probe and even calls SandboxSpec the native T1 path. PSEC is preferred and gates deniedPaths with PSE_SUPPORT_FS_DENY; document both contract-specific probes so the row and note agree.

| `deniedPaths` | ✅ (T3 DENY ACE) | ✅ (T3 DENY ACE) | ✅ (T3 DENY ACE) | ✅ (T3; T1 when the active contract reports deny-path support) |

docs/process-container/os-version-support.md:208

This source pointer no longer identifies where the documented PSEC ingress probing and contract construction live. Those operations moved to base_container_helpers.rs (query_psec_support and build_psec_spec), while base_container_runner.rs retains the legacy SBOX probe and selection. List both locations so the implementation reference is actionable.

- BaseContainer capability probing and contract construction:
  `src/backends/appcontainer/common/src/base_container_runner.rs`

This was referenced Sep 1, 2026

Add Process Security Environment ingress contract #1076

Merged

Enforce ProcessContainer ingress policy #1080

Open

Clarify ProcessContainer networking documentation #1077

Closed

microsoft-github-policy-service Bot added the Copilot-Instructions PR modifies Copilot instruction files (.github/copilot-instructions.md or .github/instructions/) label Sep 1, 2026

Copilot AI balanced review requested due to automatic review settings September 1, 2026 23:58

Branden Bonaby (bbonaby) force-pushed the user/bbonaby/process-container-network-docs-runtime-stack branch from 1b0cb8e to 9390d44 Compare September 1, 2026 23:58

Copilot started reviewing on behalf of Branden Bonaby (bbonaby) September 1, 2026 23:59 View session