Evidence
Source of Truth: docs/ARCHITECTURE.md
Status: Canonical repo cleanup aligned to the current architecture as of 2026-05-16. This post continues the core series from discovery into the security, policy, approval, audit, and redaction seams around tool execution.
VS MCP Bridge Blog Series: Part 6
Security Seams Around Tool Execution
Part 5 described how VS MCP Bridge keeps tool discovery explicit. Compiled tools are the default, MEF is an opt-in discovery seam, and discovered tools are not allowed to become their own execution system.
Part 6 looks at the next question: what happens after a tool is found?
The answer is the same for compiled tools, discovered tools, fake test tools, and future extension points: tool execution must flow through BridgeToolExecutor. That is the boundary where policy, approval, secret-reference checks, audit, redaction, correlation, and the actual tool call are kept together.
This is not a claim that VS MCP Bridge already has production authentication, OAuth, RBAC, vault-backed secrets, sandboxed plugins, or a compliance audit system. It does not. The current work is security architecture plumbing: narrow contracts and observable boundaries that make future hardening possible without scattering security decisions through every tool.
The Boundary Is The Security Feature
The most important rule is simple: a tool should not be able to bypass the executor just because it was registered successfully.
Discovery answers what tools exist. Execution answers whether this request is allowed to run, whether approval is required, what metadata must be audited, what should be redacted, and what result is returned.
Keeping those responsibilities in one boundary matters because every new tool adds risk. A search tool, a Visual Studio-backed tool, a future file-writing tool, or a future extension-provided tool may all have different capabilities, but they should still be evaluated through the same execution path.
What The Executor Owns
The current BridgeToolExecutor owns the security-sensitive execution sequence:
- resolve the requested tool from the catalog
- build a security context with tool metadata, request metadata, correlation identifiers, capabilities, approval requirement, and secret references
- evaluate the configured tool execution policy before running the tool
- resolve required secret references through the broker seam without making raw secrets part of normal flow
- ask the approval service when a descriptor requires approval
- invoke the tool only after policy, secret-reference, and approval checks allow it
- redact sensitive values before logging or audit output
- emit an audit envelope with structured outcome, classification, policy, approval, capability, secret-reference, and correlation metadata
That ordering is intentional. Policy denial stops execution before approval. Approval denial stops execution before the tool runs. Secret-reference failure stops execution before unresolved secret material can become accidental runtime behavior.
Policy Before Execution
The policy seam is deliberately lightweight today. The default policy allows execution so existing behavior stays unchanged. A capability-aware policy can be configured to allow or deny tools based on declared required capabilities, but it is not a user identity system and it is not RBAC.
That distinction is important. Capability metadata is declarative plumbing. It lets a tool say, for example, "this tool requires a Visual Studio document read capability" or "this tool will touch proposal state." A policy can inspect that metadata. The project has not yet attached those capabilities to authenticated users, accounts, roles, or external authorization decisions.
Even so, the seam is valuable now because the executor and audit pipeline can already preserve the evidence needed to explain why a request was allowed or denied.
Approval-Aware Execution
Approval-aware execution follows the same pattern. A tool descriptor can declare that execution requires approval. The executor sees that requirement and calls IToolExecutionApprovalService before invoking the tool.
The default service allows execution, so existing tools continue to run unless they explicitly opt into approval. Tests cover both paths: an approval-required tool can be allowed and executed, or denied and returned as a structured failure without running the tool.
This is not the same thing as a finished user-facing prompt system. It is the execution seam that a prompt system can use later. The important architectural point is that approval is not implemented inside each tool. It lives at the execution boundary.
Secrets Flow By Reference
Secret handling follows the same conservative pattern. The current architecture has secret-reference contracts and a broker seam, not real secret storage.
That means tools can describe required secrets as structured references instead of requiring raw values in tool descriptors, logs, prompts, or audit payloads. The default broker returns unresolved or not configured. That is intentionally boring behavior, but it is safer than pretending a real vault exists before one has been designed.
The key rule for future tool authors is that secret values should flow by reference, not by payload. Logs and audit envelopes may record reference metadata and resolution outcome, but not raw secret values.
Redaction Is Part Of The Boundary
Redaction is not a final line of defense, and it should not be treated as a substitute for careful data flow. It is still an essential part of the boundary because diagnostics are only useful if operators can safely read them.
The bridge redactor masks obvious secret-like keys and values before they enter logs and audit envelopes. That lets traces remain useful while reducing the chance that credentials, tokens, passwords, or synthetic test sentinels leak into developer-visible output.
This matters for anti-black-box diagnostics. The project needs enough evidence to reconstruct what happened, but not so much raw payload detail that the diagnostic trail becomes a secret leak.
Audit Envelopes Carry The Explanation
Audit envelopes are the durable explanation layer around tool execution. They preserve the request and operation correlation metadata, the tool name, policy decision, approval decision, required capabilities, secret-reference metadata, redacted payload summaries, terminal outcome, and structured classification.
The classification metadata is intentionally small: category, severity, risk, and outcome. A successful tool execution can be informational and low risk. A policy denial can be warning and medium risk. An unresolved secret can be warning and high risk. An exception path can be error and high risk.
That is observability plumbing, not a SIEM integration or compliance framework. The value is that a future session can inspect an audit record and understand the shape of the decision without relying on chat history or a debugger session.
Compiled And Discovered Tools Follow The Same Path
This is where Part 5 and Part 6 connect. MEF discovery can find extension-provided tools, but discovery does not grant those tools a private execution lane. They still become catalog entries, and execution still flows through the same executor boundary.
That keeps extensibility from erasing the security model. A discovered tool can have descriptor metadata, required capabilities, approval requirements, and secret references. The executor can then evaluate those declarations the same way it evaluates compiled tools.
The current system is intentionally not a plugin sandbox. Future sandboxing, signed manifests, capability attestation, and remote authorization are deferred. The useful thing today is that the project has a place to attach those decisions later.
Related Mermaid Trace Sources
The repo already has Mermaid sources that support this topic:
Those .mmd files are the diagram source of truth. This post references them directly rather than embedding generated images.
What Is Still Deferred
The current bridge has security seams, not finished enterprise security. The following remain intentionally deferred:
- OAuth and authentication
- user identity, roles, and RBAC
- real secret storage or vault integration
- encrypted persistence
- remote authorization
- plugin sandboxing
- signed plugin manifests
- tamper-evident audit storage
- SIEM export or compliance reporting
Calling those items out is part of the architecture. It prevents the current plumbing from being oversold, and it gives future work a clear place to land.
Takeaway
VS MCP Bridge does not make tool execution safer by hiding it. It makes execution safer by routing it through a visible boundary that owns policy, approval, secret-reference handling, redaction, audit, classification, correlation, and execution.
That boundary is what keeps compiled tools, discovered tools, and future tools from becoming black boxes. It also gives the project a practical path from today's lightweight seams toward stronger security without pretending that future hardening is already complete.
Next In The Series
The next useful topic is how durable trace artifacts, logs, and validation handoffs turn these seams into operational evidence that another developer or AI session can reconstruct without relying on memory.