Now
Local MCP Boundary workflow
Install mcpboundary locally, add one MCP server profile, route selected calls through the boundary, and inspect tools, policy, and activity in the local dashboard.
ROADMAP
Where the boundary goes next.
This roadmap describes what we are working on, not a release schedule or a promise that every item is already available.
MCP Boundary leads the near-term work. Core hardening and further target systems follow as foundation tracks.
Next
Human approval and clear agent feedback
Approval flow for exact pending actions: the tool result says approval required, the dashboard shows the queue, and there is no generic run-anyway bypass.
Next
Email action verification
Keep email work scoped: read metadata, create drafts, send only when intentionally enabled, and tell the agent when an email was not sent.
Soon
Simpler setup and better diagnostics
Easier first-run setup and profile import, plus clearer activity views for blocked, failed, and completed calls.
Soon
Releases and scoped server evidence
Refreshed Windows ZIP, a Linux artifact with checksums, and more real MCP servers tested with exactly labeled evidence.
Foundation
Core: decision hardening, evidence, and replay
Deepen explicit policy inputs, observed state, and outcome recording, with a replay path that explains decisions without recreating impact.
Later
Larger local workspace control
More configured profiles, better diagnostics, and richer policy authoring while staying local and profile-based.
Later
More target systems, cloud later
Apply the same pattern to more bounded target systems; hosted convenience only after local scope and isolation are strong enough.
No claim of production security, DLP, prompt-injection protection, or broad tool compatibility. See current limits.
Have a real MCP workflow that needs a boundary?
The most useful roadmap input is one concrete MCP server or workflow: which tools should be visible, which calls may run, and which effects must be stopped or reviewed before they reach the real system?