Repository navigation
OPP: MCP tool permission modeling #1058
Description
Activity
- added a parent issue
on Apr 29, 2026 The MCP tool approach is superior to the network layer for many use cases. GitHub is a perfect example; an MCP tool could constrain an agent to open 1 PR or leave N comments. No rogue bots. You can't express those constraints at the network layer (easily).
A useful addition would be support for operator-provided MCP servers within the sandbox. I bring my own tool container with my own tools, OpenShell manages its lifecycle and gates which tools are callable via policy. The network layer sandbox is still potentially useful here - we still can benefit from sandboxing.
This way, I don't have to stand up separate infrastructure for hosting custom MCP endpoints.
One angle here would be for OpenShell to grow some opinion on speaking https://agentclientprotocol.com to the inner agent - that protocol already has provisions for the caller providing MCP servers.
GitHub is a perfect example; an MCP tool could constrain an agent to open 1 PR or leave N comments. No rogue bots.
I have also been digging into GH-AW and one thing that my (agent-assisted) research says is that the safe outputs stuff should be pretty reusable outside of GH-AW (of course, a caveat is they may not support it officially right now).
The way it's implemented right now is actually a full separate job (virtual machine) in the GHA workflow, but yes, it could also be implemented as something more like a oneshot MCP (their MCP server just writes a file the outer workflow reads).
I previously generated https://github.com/LobsterTrap/service-gator which is in this space, but for Github specificalliy the safe outputs stuff is generally better.
It is kind of tempting to create a more generic safe-outputs style wrapper that also handles e.g. jira and gitlab among other things.
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
Extend the policy prover to reason about MCP (Model Context Protocol) tool permissions alongside existing L4/L7 binary and endpoint modeling.
Agents increasingly use MCP servers to interact with external services (GitHub, databases, file systems, etc.). Today OPP models which binaries can reach which endpoints. MCP adds a layer: the binary (e.g., node) reaches the MCP server, but the security-relevant question is what tools the MCP server exposes and what those tools can do.
Problem
A sandbox policy might allow node to reach api.github.com, and an MCP server running inside the sandbox provides tools like create_issue, push_code, read_repo. The prover should be able to reason about:
Scope
Context
This bridges the gap between "which binaries can reach which endpoints" (current model) and "what can the agent actually do through its tool interfaces" (what users care about). Tracks under OS-43.