An MCP server is a set of tools an AI agent can invoke, and most of them hold real credentials for whatever they reach — your ticketing system, your database, your cloud account. The ecosystem's default is that anything holding the server's URL gets every tool on it. KnoxCall makes that a policy decision instead.
What is enforced
Every claim below is a refusal you can reproduce, not a capability we assert. Each one names the status code it returns when it fires.
Tokens are bound to an MCP server's resource identifier at mint time
(RFC 8707). Presented at a different server it is 401 with a
WWW-Authenticate challenge — not a partial grant, not a
silent downgrade. A token carrying no resource binding is also
401: unbound is refused rather than treated as unrestricted,
because the fail-open reading of "no audience" is how audience checks stop
being audience checks. A token that is not tool-bound at all gets
403 insufficient_scope.
tools/list returns only what the server's allowlist names, so
the model is never shown a tool it may not call, and a
tools/call for anything else is refused. The part that matters
is the unconfigured state: an empty allowlist advertises
nothing, not everything. A governance control whose default is
"allow all" protects only the people who already knew to configure it.
A caller's own capability token intersects with that set — it can
narrow the tools it may reach, never widen them.
A prompt firewall that only reads the user's message misses the interesting
half: what the model decided to put in the tool call. Tool arguments and
tool results run through the built-in PII detectors, and an MCP server can
carry a prompt-injection policy that refuses a tools/call
outright. Every call writes an attributed row — which token, which
tool, which outcome.
What is not true yet
This is a security product, so the gaps are on the page rather than in a footnote. If one of these is load-bearing for you, it is the thing to ask us about.
| Capability | State | What that means |
|---|---|---|
| Audience-confined tokens (RFC 8707) | Enforced | Wrong resource is 401, unbound is 401, non-tool-bound is 403. All three are asserted in the test suite. |
| Tool allowlist | Enforced | Filters tools/list and refuses tools/call. Empty denies. The token intersects, never unions. |
| Prompt-injection policy on tool calls | Enforced | An MCP server can reference a firewall policy; a block policy refuses the call. |
| Built-in PII detectors on arguments and results | Enforced | The shipped detector set — SSN, PAN, IBAN, email, phone, JWTs, live provider keys. |
| Per-call attribution and audit | Enforced | Every tool call writes a row naming the token, the tool and the outcome. |
| Upstream SSRF pinning + secret-ref auth | Enforced | An MCP upstream URL is resolve-and-pinned on every hop including redirects; upstream credentials are secret references, never plaintext in the row. |
| Your own PII recognizers on the MCP path | Not shipped | Custom recognizers and compliance-pack recognizers run on model calls but not yet on MCP calls — that path is built once at boot with the shipped detector set. If you rely on a custom entity, it will not fire here yet. |
| Per-user credential passthrough / delegated OAuth | Not shipped | One upstream credential per MCP server today. Per-caller credentials are designed, not built. |
Audience-confined tokens, allowlists that deny by default, and inspection on the arguments — in the same gateway, on the same bill, as your model traffic.