Do not force protocol security and action policy into the same box
The official MCP security guidance covers serious implementation risks, including OAuth confused-deputy conditions, token passthrough, SSRF, session hijacking, local server compromise, authorization URL validation, proxy security, and over-broad scopes. These controls are not optional hygiene; they are the foundation of a trustworthy MCP client, proxy, gateway, or server.
A separate risk remains after those controls pass. An agent can hold a correctly issued, correctly scoped token and produce a schema-valid tools/call request that conflicts with the user’s purpose or business policy. That is not proof that MCP authorization failed. It is evidence that protocol access and runtime action approval are different decisions.
AgenticDome complements MCP by adding the latter decision at a forwarding boundary the application controls. For explicitly supported methods, the public MCP adapter can authorize the request before forwarding, filter discovery, remove recognized internal delegation fields, and review configured returned content before it re-enters the agent loop.
What changes when AgenticDome is in the path
Use MCP authorization, TLS, consent, audience and issuer validation, narrow scopes, secure sessions where used, server-side resource authorization, validation, isolation, and monitoring. Then route sensitive application-controlled JSON-RPC traffic through AgenticDomeMCPHostFirewall. The wrapper evaluates supported methods with tenant, actor, agent, server, purpose, session, tool, and argument context. Requests that bypass the wrapper or use unknown/custom methods are not automatically governed by it.
The two security layers answer different questions
A production architecture needs both a secure protocol path and a policy decision about the business action travelling through it.
Protocol and access security
MCP and OAuth controls establish secure transport, correct token use, consent, client/server trust, scope, session handling, and resource access.
Action-level authorization
AgenticDome evaluates supported methods, tools, URIs, prompts, final arguments, actor, agent, purpose, and tenant policy before forwarding.
Returned-content review
Configured tool, resource, prompt, sampling, discovery, and streaming paths can be reviewed before content becomes trusted planner context.
Runtime context and evidence
Stable session, trace, actor, and agent context can correlate decisions and configured behavioural controls beyond an isolated request.
Stateless transport does not mean context-free security
MCP Streamable HTTP permits a server to assign an MCP-Session-Id for stateful sessions; it does not require every server to do so. A stateless deployment can simplify scaling, but it does not prove safe intent. Conversely, a protocol session does not automatically provide business-action history. Pass stable application session, run, trace, actor, and agent identifiers to AgenticDome where policy or behavioural correlation requires them. Normal SDK checks do not require the customer application to operate Redis.
How AgenticDome creates the control point
1. Secure the MCP connection
Implement the current transport and authorization specifications, validate issuer/audience/resource, preserve consent, and minimize scopes.
2. Authorize the real resource
The MCP server and downstream service enforce the authenticated principal’s entitlement to the requested data or operation.
3. Apply action policy
The host or gateway routes supported JSON-RPC through AgenticDome with trusted actor, agent, purpose, server, session, and final arguments.
4. Review the response
Configured supported results are filtered or sanitized before storage, display, logging, transcript persistence, or planner reuse.
5. Correlate and respond
Use runtime evidence, SIEM export, rate controls, behavioural signals, and incident procedures without weakening protocol-layer logs.
What this changes for real teams
Keep server authorization authoritative
“We already validate OAuth, scopes, schemas, and downstream resource access and do not want a gateway pretending those controls are unnecessary.”
AgenticDome contribution: AgenticDome explicitly complements those controls. It adds customer-specific action policy at a controlled host/gateway boundary and does not replace the server’s authorization or secure design.
Govern intent across many servers
“Each server knows its API, but none has the full customer policy for every agent, user, purpose, and delegated workflow.”
AgenticDome contribution: Wrap the shared forwarding path and evaluate supported operations through one tenant policy vocabulary while retaining per-server authentication and resource checks.
Scale without losing correlation
“We want stateless server instances, but high-risk decisions still need actor, session, and multi-step context.”
AgenticDome contribution: Keep the MCP service stateless if that architecture fits, and supply stable application context to the assigned AgenticDome runtime. Redis is optional only for specific cross-process SDK handoff state, not normal authorization.
The risks this helps contain
| Risk | Why it matters | Public AgenticDome control |
|---|---|---|
| OAuth confused deputy or token passthrough | MCP proxies can mishandle consent or accept tokens not issued for the MCP server. | Follow the MCP authorization and security specifications. AgenticDome does not repair an invalid OAuth architecture. |
| Valid token, wrong business action | Correct access does not prove that the exact tool, arguments, purpose, or sequence is appropriate. | Evaluate the supported action immediately before forwarding using tenant policy and trusted runtime context. |
| Poisoned discovery or returned content | Tool descriptions, resources, prompts, and results can influence later planning decisions. | Use configured filtering and sanitization for explicitly supported list/read/get/call/sampling and iterator paths; maintain allowlists for unknown methods. |
| Stateless blind spot | An isolated request may be one step in a larger exfiltration, loop, escalation, or resource-exhaustion sequence. | Pass stable application correlation identifiers and enable appropriate behavioural, trust, topology, and rate controls. Do not claim history where identifiers are absent or calls bypass enforcement. |
| Session hijacking | Where MCP sessions are used, stolen or weak session identifiers can enable impersonation or prompt-injection flows. | Apply the MCP specification’s session protections. AgenticDome application session context is not a substitute for MCP-Session-Id security. |
| Local server compromise | A protected request can still reach a vulnerable or over-privileged process. | Keep process isolation, sandboxing, least privilege, filesystem and network controls, patching, signing, secrets management, and server monitoring. |
A practical path to production
Implement the specification
Use current MCP transport, authorization, security, session, consent, token, scope, and proxy guidance.
Find the owned boundary
Identify the host, router, proxy, or gateway function that actually forwards sensitive JSON-RPC.
Pass trusted context
Include authenticated human/workload, agent, purpose, server, session, trace, tool, URI, and final arguments as available.
Test both layers
Test OAuth and protocol attacks separately from semantic misuse, returned-content poisoning, altered arguments, delegation, and outage behaviour.
Where this control ends
AgenticDome does not replace MCP authorization, OAuth security, consent, token audience/resource validation, server-side authorization, session security, schema validation, SSRF defences, secure tool implementation, sandboxing, process isolation, egress control, secrets management, patching, or incident response. The public adapter has explicit handling only for documented supported methods. Unknown and custom methods pass through unchanged unless the gateway rejects them. Behavioural correlation depends on stable context and configured enforcement.