Which tools are visible?
Filter forbidden tool schemas in routed LLM traffic or discovery responses. Hiding a tool reduces exposure; it does not, by itself, prove the server would deny a direct invocation.
MCP security · Tool permissions · Actual enforcement
MCP tool permissions should govern calls, not just tool lists.
Giving an agent a tool is not the same as authorizing it to run. Learn where MCP discovery restrictions end, where tools/call denial begins, and why exact-action approval is a separate capability. Talon applies company policy only to the paths it actually intercepts.
AGENT → MCP PROXY → TOOLS/CALL
authenticated use case
policy decision: DENY
upstream calls: 0
evidence: signedTool visibilityTool-call permissionAuthenticated use caseHTTP action approvalVerifiable decision
Start with the boundary
Four questions an MCP gateway must answer
Before purchasing or configuring MCP security, distinguish the agent seeing a tool, requesting a call, receiving authorization, and causing a real downstream effect. Those are different events with different evidence.
Can this tool be called?
Evaluate an intercepted MCP tools/call before upstream forwarding. A denial must prevent dispatch on that routed path and record its reason.
What happens after permission?
A permitted tool call is not a guaranteed business success. Tool execution, returned results, externally asserted effects, and unknown outcomes require separate treatment.
Feature truth, October 2026
MCP tool blocking and exact HTTP action approvals are not the same feature.
The table distinguishes capabilities described in Talon's current public implementation from broader convergence that remains planned.
| Control | What Talon currently provides | Important limit |
|---|---|---|
| Authenticated use-case policy | A presented Talon agent key selects the authenticated use case and its effective organization + agent policy. | Client-asserted subagent/session labels do not independently authenticate a workload. |
| Tool exposure | Tool schemas visible in supported gateway requests can be filtered. | Not visibility into arbitrary local tools or all framework-internal actions. |
| MCP pre-call denial | Routed MCP tools/call can be denied before the upstream call, with signed denial evidence. | Full HTTP ActionGovernance operation/approval/dispatch lifecycle is not yet shared by MCP/native tool calls. |
| Exact action + approval | The separate HTTP Action Gateway on Talon main supports trusted action definitions, exact-operation binding and ALLOW | DENY | REQUIRE_APPROVAL. | Not a promise that any MCP server automatically gains the same approval mechanism. Check tagged release availability. |
| Audit and troubleshooting | Signed evidence for supported decisions; existing JSON logs and OpenTelemetry instrumentation provide diagnostics. | Logs are not signatures; bypassed tools are neither governed nor evidenced by Talon. |
A practical policy example
Read status, restrict publish.
Imagine an AI coding assistant that can inspect a release and publish one. The useful policy question is not whether it is allowed to “use MCP,” but whether this authenticated use case may invoke this tool through the intercepted path.
For a direct release_publish MCP call, Talon can deny the forbidden invocation before the upstream server is called. If the application needs approval of the exact release and destination, evaluate the separately integrated HTTP Action Gateway; never market that as automatically applied to native or MCP calls.
tools/list: release_status, release_publish
↓
authenticated use case + effective policy
↓
tools/call: release_publish
↓
DENY before upstream MCP invocation
↓
signed denial evidence
HTTP Action Gateway (separate path)
→ bound operation → approval decision
→ runtime claim → bounded dispatch attemptEvaluation checklist
How to test MCP tool governance in your own environment
1. Fix the trust boundary
Name the MCP client, the actual reachable MCP server, the authenticated agent/use case, and which alternative routes can bypass the gateway.
2. Prove a denial
Try one allowed read and one forbidden write with a deterministic test server. Verify that the forbidden upstream handler never ran.
3. Separate proof from telemetry
Inspect the recorded policy decision and integrity verification. Use log search or traces for troubleshooting, not to infer an unobserved business effect.
Local shell commands, file edits, browser actions and direct APIs that do not traverse Talon remain outside Talon's control. Approval never by itself dispatches an action. An unknown downstream result must not be presented as a confirmed success.
Frequently asked questions
MCP access control, answered precisely
Does hiding a tool prevent direct calls?
Not by itself. Restrict discovery for exposure and enforce tool-call permission at the intercepted execution path. Test both behaviors.
Does MCP denial include human approvals?
Talon can deny intercepted MCP tool calls. Exact human-bound action approval currently ships on a separate HTTP Action Gateway; canonical MCP convergence is in progress.
Can a gateway see every tool an agent uses?
No. Visibility depends on the runtime routing calls through supported interception paths. Local and out-of-band activity can bypass it.
Further technical reading
Follow the protocol, not the marketing label
Compare Talon's intercepted-action model with the MCP protocol migration guide. For a separate gateway design, agentgateway documents MCP authorization; and LiteLLM documents key/team MCP permissions. Their controls are not interchangeable, so test the required authorization boundary.
Reproducible action control
See a denied call before you claim governance.
Use the current technical proof to inspect the pre-dispatch decision, then check which MCP tool calls are actually intercepted in your integration.