You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adds the MXC Policy Store feature spec, building on #779. After the design review, Policy Store ships inside MXC as SDK APIs (TypeScript, Rust, .NET) over one shared Rust resolver, with V1 policy data embedded at build time. It isn't part of MXC 1.0. Floors are best-effort baselines, not authorization or a guarantee that a workflow works, and Learning Mode is complementary rather than a replacement.
Lookup is keyed on tool identity (packageUrl strong, invocationName as an opt-in fallback), an optional tool-defined intent, and an optional detected version. Host and command line aren't lookup keys. Each entry has one unversioned default plus add-only platform and version overlays, with version ranges in purl vers syntax (npm, semver, pypi, nuget, intdot). Overlays use policyAdditions, intentAdditions for intents the default already declares, and newIntents for new ones.
Each requested tool+intent pair gets a status (matched_default, matched_version, version_out_of_range, version_unparseable, intent_unsupported, tool_unmatched), so a multi-tool request can return a policy that covers only the pairs that resolved. Composition keeps required access: read-write supersedes overlapping read-only, and a catalog filesystem or egress deny that conflicts with another requested tool's required access is removed in full and reported in diagnostics. Caller restrictions still win. Dependencies contribute their default plus platform additions only, unless the reference names dependency intents.
Still open (§13): the exact validator and version mapping, purl equality rules, and final API names, which I think should follow the policy-type rename.
Docs-only. Type-checked all TypeScript snippets together against the sdk/node types with tsc --noEmit --strict (passed), parsed the JSON examples (passed), checked internal anchors and relative links (none broken), and ran git diff --check (clean). No runtime build or test suite was run.
If this PR changes Cargo.lock, the dependency-feed-check check passes (see docs/pull-requests.md)
📋 Issue Type
Bug fix
Feature
Task
GitHub Actions runs the PR validation build automatically. The ADO pipeline
(MXC-PR-Build) is the Azure version of the PR pipeline, kept in parity with the GitHub
Actions build; it runs on merge to main, and Microsoft reviewers with write access can trigger it
on a PR with /azp run. See docs/pull-requests.md.
If the dependency-feed-check check fails on a new dependency, the crate must be added to
the feed before the PR can pass. See docs/pull-requests.md
for the steps.
Proposed feature spec for the MXC Policy Store: an integrity-validated,
versioned, read-only known-tool sandbox requirements catalog and SDK
resolver. Builds on microsoft#779's config-floor data model and
tightens it into a review-ready contract: independent catalog/entry/
policy versioning, ordered strong/weak tool identity, complete
per-platform requirement variants, deterministic cycle-rejecting
dependency resolution with an explicit v1 composition vocabulary, a
resolver API split from catalog metadata inspection, immutable
published revisions, and a reviewed PR/CI contribution pipeline.
Scoped to what MXC owns; consumers retain access-profile mapping,
authorization/elevation, persistence, composition, approval, audit,
and final sandbox creation. Status is proposed and review-ready, not
approved or shipped; open questions are called out explicitly with
recommended answers.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
The reason will be displayed to describe this comment to others. Learn more.
This doesn't belong in the mxc repository. If we want this, it should be in its own repo, perhaps named microsoft/sandbox-tool-requirements or some such.
Chaz Gordish (Chaz Gordish (@ChazGo)) - This work needs a broader discussion. Can you please schedule a meeting to go over the overall product story here?
Gudge (@MGudgin)Anis Mohammed Khaja Mohideen (@kanismohammed) sorry I was just getting this started and didn't mean to make it set off alarm bells, but it did get the conversation started early at least! I'll get something booked on the calendar. I think we do need to agree on where this should live first, because that should significantly influence how much scrutiny other design decisions will receive. Alexander Sklar (@asklar) FYI on this draft and the meeting I'll be setting up. This essentially takes your #779 design and expands upon it slightly.
Center the first-run containment problem, document the limited support horizon and Learning Mode replacement, and move catalog ownership outside MXC.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add an in-place feature-impact and omission-defaults subsection without restructuring the reviewed document.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Use the selected support designation while retaining the limited lifetime, proposed SDK boundary, and not-shipped disclaimer.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Use resolveSandboxPolicy and resolveSandboxPolicyWithDiagnostics throughout the spec, retain the original proposal's name as historical context, and make runtime and inspection declarations valid exported TypeScript signatures.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
“Supported by that SDK” does not ensure shared-catalog parity because the current SDK policy types have different field sets: Rust exposes version/filesystem/network/UI/timeout (src/core/mxc_engine/src/policy.rs:580-592), while Node also exposes runtimeConfig, telemetry, and processContainer (sdk/node/src/types.ts:465-523). Since §4.5 permits a single-entry policy to use otherwise non-composable fields, one revision can be representable in one binding but rejected or truncated in another. Define a common publishable field subset or explicit per-binding revision compatibility so unsupported fields are never silently lost and the §6.2 parity guarantee remains achievable.
Make the opening access and safety caveat explicit, map catalog failures to existing MXC error codes with optional reasons, and add the corresponding conformance check.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The entry shape defines dependencies, but no requires member exists, so this invariant refers to an undefined edge type. Use the field name from the example and the rest of the contract.
Ship as MXC SDK APIs with bundled V1 data, add intents and add-only
platform/version overlays (newIntents vs intentAdditions), per-pair
resolution statuses, default-only dependencies, and catalog filesystem
and egress deny removal on conflict. Linux invocation names match
exactly.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Dependencies, overlays and composition now follow the pushed spec
(microsoft#1309 at 5a2c52c, docs/mxc-policy-store.md):
- Dependencies contribute the referenced entry's default plus platform
base additions only. A reference may name intents
({ entryId, intents: [...] }); a named intent the dependency's default
does not define fails catalog validation. Dependency diagnostics report
intentSelection mode "none" or "named".
- Overlays use policyAdditions, intentAdditions (default intents only)
and newIntents. The former overlay `intents` field is renamed to
`newIntents` in the model, JSON schema, metadata and fixtures.
- A catalog egress deny that overlaps another requested pair's required
egress allow is removed in full, with a diagnostic naming the full
destination/port scope and the contributing entries. Non-overlapping
denies stay. Overlapping denies are no longer composition_conflict.
- Network rule validation parses CIDRs, requires `except` blocks inside
their peer, and rejects ports on icmp.
- The reviewer view adds an "Added to default" column per row.
- Catalog revision 2026-10-05.1 replaces 2026-10-02.1: git entryRevision
2 moves the >=2.50 bundle-fetch intent to newIntents.
- New composition-catalog conformance fixture and library tests.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Keep lookup command-free with ContainerRequirements using existing v1 SDK field types. Clarify validation, structured diagnostics, PURL matching, contribution attribution, and filesystem identity while preserving the catalog composition and partial-result contract.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| Approve the command-free requirements API surface? | `resolveToolRequirements` / `resolveToolRequirementsWithDiagnostics` return `ContainerRequirements` using existing v1 section types, with optional lookup context, Promise-based Node resolution, corresponding Rust/.NET bindings, and the documented partial-result contract. |
This branch has not been deployed
No deployments
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Needs-AttentionRequires attention or a decision from the MXC maintainers.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Gudge (MGudgin)
left a comment
microsoft-github-policy-service
Bot
added
the
Needs-Author-Feedback
📖 Description
Adds the MXC Policy Store feature spec, building on #779. After the design review, Policy Store ships inside MXC as SDK APIs (TypeScript, Rust, .NET) over one shared Rust resolver, with V1 policy data embedded at build time. It isn't part of MXC 1.0. Floors are best-effort baselines, not authorization or a guarantee that a workflow works, and Learning Mode is complementary rather than a replacement.
Lookup is keyed on tool identity (
packageUrlstrong,invocationNameas an opt-in fallback), an optional tool-defined intent, and an optional detected version. Host and command line aren't lookup keys. Each entry has one unversioned default plus add-only platform and version overlays, with version ranges in purlverssyntax (npm,semver,pypi,nuget,intdot). Overlays usepolicyAdditions,intentAdditionsfor intents the default already declares, andnewIntentsfor new ones.Each requested tool+intent pair gets a status (
matched_default,matched_version,version_out_of_range,version_unparseable,intent_unsupported,tool_unmatched), so a multi-tool request can return a policy that covers only the pairs that resolved. Composition keeps required access: read-write supersedes overlapping read-only, and a catalog filesystem or egress deny that conflicts with another requested tool's required access is removed in full and reported in diagnostics. Caller restrictions still win. Dependencies contribute their default plus platform additions only, unless the reference names dependency intents.Still open (§13): the exact validator and version mapping, purl equality rules, and final API names, which I think should follow the policy-type rename.
🔗 References
🔍 Validation
Docs-only. Type-checked all TypeScript snippets together against the
sdk/nodetypes withtsc --noEmit --strict(passed), parsed the JSON examples (passed), checked internal anchors and relative links (none broken), and rangit diff --check(clean). No runtime build or test suite was run.✅ Checklist
Cargo.lock, thedependency-feed-checkcheck passes (see docs/pull-requests.md)📋 Issue Type
GitHub Actions runs the PR validation build automatically. The ADO pipeline
(
MXC-PR-Build) is the Azure version of the PR pipeline, kept in parity with the GitHubActions build; it runs on merge to
main, and Microsoft reviewers with write access can trigger iton a PR with
/azp run. See docs/pull-requests.md.If the
dependency-feed-checkcheck fails on a new dependency, the crate must be added tothe feed before the PR can pass. See docs/pull-requests.md
for the steps.
Microsoft Reviewers: Open in CodeFlow