Repository navigation
Provider-covered endpoints cannot be extended through agent policy proposals #2921
Description
User Story
As an OpenShell policy reviewer, I need an agent's incremental policy proposal to reach normal review when it extends access to an endpoint already covered by a provider, so that provider defaults remain a baseline rather than a ceiling.
Problem Statement
With Providers v2 enabled and the built-in GitHub provider attached, an agent proposal for write access to api.github.com:443 is rejected before a draft is created. The provider contributes a read-oriented rule for the same endpoint, and candidate validation reports an overlapping-rule conflict because the rules differ on advisor_proposed metadata.
Removing an equivalent GitHub read rule from the sandbox's base policy does not help: the provider rule alone is enough to conflict with the proposed rule. The proposal therefore never reaches the configured manual reviewer.
Impact / Why This Matters
- Agents cannot request incremental access on an endpoint supplied by an attached provider.
- Provider defaults become a de facto ceiling for that host, even though provider and user policy layers are intended to compose.
- Reviewers never see the proposal, so a policy decision is replaced by a candidate-validation failure.
Acceptance Criteria
- An agent proposal may add narrower or broader access to a provider-covered host without conflicting solely because
advisor_proposeddiffers. - The proposal reaches the normal pending-review flow when the composed candidate is otherwise valid.
- Provider-owned policy remains immutable; approval changes only the sandbox/user policy layer.
- An integration test covers a provider read rule and an agent write proposal for the same host.
Reproduction Steps
- Enable Providers v2, agent policy proposals, and manual proposal approval.
- Create a sandbox and attach the built-in GitHub provider.
- From the sandbox, submit a proposal for
api.github.com:443that allowsPUT /repos/<owner>/<repo>/contents/<path>for/usr/bin/gh. - Observe that no pending draft is created and the proposal is rejected during candidate validation.
Environment
- OpenShell:
0.0.112-dev.5+g679fe4c3(679fe4c334f0c62a653b004fae7008a631bf7f22) - Also observed on gateway commit
d9d38a561944dd041342c004dbfe6ff5b3c8d8de - OpenShell SDK:
0.0.106 - Linux ARM64 under Docker
Logs
network endpoint ambiguity validation failed
overlapping rules for api.github.com:443 have conflicting metadata:
advisor_proposed=false vs advisor_proposed=trueRelated design context: provider policies supply defaults that compose with user policy (#734 and discussion #865).
Activity
johntmyers commentedon Aug 25, 2026
Implementation Plan
Issue type:
fixComplexity: Medium
Confidence: High — the failing path is reproduced from current code and the minimal validator fix is clear.
Summary
policy.localagent-authored proposals arrive withadvisor_proposed=trueon endpoints and the deprecated binary provenance bit set. Provider-composed endpoints use the same host and port withadvisor_proposed=false, and candidate validation currently treats that provenance bit as overlapping endpoint metadata, so the proposal is rejected before review. I will treatadvisor_proposedas provenance instead of endpoint-contract metadata, add a regression that uses the realpolicy.local-shaped input against a provider-covered host, and tighten the surrounding provenance semantics and docs where the current behavior is unclear.Scope
crates/openshell-policy/src/ambiguity.rs: stop reporting endpoint ambiguity solely becauseadvisor_proposeddiffers; add unit coverage for overlapping endpoints that differ only by advisor provenance.crates/openshell-policy/src/merge.rs: verify and, if needed, align endpoint merge/coverage behavior so explicit endpoint provenance dominates advisor overlays without breaking/waitconvergence or the SSRF two-step flow.crates/openshell-server/src/grpc/policy.rs: add an integration regression for a provider read rule plus apolicy.local-shaped agent write proposal on the same host, and verify approval mutates only the sandbox/user policy layer.docs/sandboxes/policy-advisor.mdxandarchitecture/gateway.md: clarifyadvisor_proposedsemantics for endpoint overlap, exact-host SSRF trust, and binary identity.Implementation Steps
advisor_proposedfrom endpoint ambiguity conflict detection and add focused policy-layer tests for compatible overlap./wait, or exact-host trust unexpectedly.policy.localproposal shape (advisor_proposed=trueendpoint, proposal binary provenance set) and assert the proposal reaches pending review instead of failing preflight.Test Plan
crates/openshell-policy/src/ambiguity.rsandcrates/openshell-policy/src/merge.rsfor overlap, provenance merge, and coverage behavior.crates/openshell-server/src/grpc/policy.rsfor provider-composed effective policy plus agent-authored proposal submission and approval.e2e/; the server integration path should cover the acceptance criteria directly.Risks & Open Questions
/waitstill reports the approved proposal as loaded.state:validated,state:acceptedor roadmap,agent:implementation-requested). Those labels are expected in the queued workflow, but this direct request authorizes implementation, so I am continuing without changing labels.Documentation Impact
Gateway Config Impact
None expected.
LSM Compatibility
None expected. This change stays in policy merge, validation, and docs paths; it does not alter
/procbinary identity collection, process execution, or SELinux/AppArmor-sensitive host inspection.Revision 1 — initial plan
johntmyers commentedon Aug 25, 2026
Implementation Complete
PR: #2935
What was built
Policy-advisor endpoint provenance no longer conflicts with otherwise compatible provider endpoints. Explicit endpoint and binary identity now dominate advisor provenance during merges, proposal coverage converges correctly, and the provider rule remains immutable through approval.
Tests
policy.localmarker coveragepolicy.local-shaped GitHub write proposal through pending review and approvalmise run e2e:mechanistic-existing-endpointpassed against a Docker-backed gateway and sandboxDocs updated
docs/sandboxes/policy-advisor.mdx: plain examples fortrue/falseendpoint provenance, binary identity, and SSRF exact-host trustdocs/sandboxes/policies.mdx: endpoint ambiguity semanticsarchitecture/security-policy.md: stable provenance and SSRF invariantsThe issue will auto-close when the PR is merged.