Connection authority is not business authority
MCP provides a standard way to connect agent applications with tools, resources, and prompts. Authentication, OAuth, scopes, and user consent remain essential because they establish access. But a valid connection cannot determine whether a particular refund, export, database operation, or cross-agent handoff matches the user’s intent and the organisation’s policy.
AgenticDome puts that decision in the forwarding path. It evaluates the authenticated actor or workload, agent, purpose, MCP server, method, tool, and final arguments immediately before the request leaves the host or gateway. For supported methods, it also reviews returned content before that content is stored, displayed, or treated as trusted context for the agent’s next decision.
What changes when AgenticDome is in the MCP path
Route the request through AgenticDomeMCPHostFirewall. A denied action never reaches the MCP server; an allowed or sanitized request is the only version forwarded; and the reviewed response is the only version returned to the agent. The result is an enforcement boundary, not another after-the-fact alert.
Why MCP teams use AgenticDome
MCP solves interoperability. AgenticDome adds a consistent action-control and evidence layer across the internal and external servers an enterprise connects, without requiring each MCP vendor to implement the customer’s business policy independently.
Authorize the real action
Decide on actor, agent, purpose, server, tool, and final arguments—not only possession of an access token.
Govern both directions
Control supported requests before forwarding and review configured results before they become new agent context.
Use one gateway policy
Apply a common tenant policy model across internal services, SaaS connectors, and third-party MCP servers routed through the boundary.
Preserve agent lineage
Carry human or workload identity, source agent, specialist, session, and action context into delegated-tool decisions and evidence.
Identity and intent in; governed request and reviewed result out
What this changes for real teams
One policy across internal and external servers
The platform team can govern a CRM lookup, ticket update, GitHub action, and third-party SaaS call through the same actor, purpose, tool, argument, and evidence model.
- Carry authenticated human or workload context
- Authorize high-impact tool arguments before forwarding
- Review supported returned content before planner reuse
A clearer route through enterprise review
A server or connector vendor can give enterprise buyers a documented path for external policy, controlled forwarding, returned-content review, and repeatable assurance testing.
- Supports security-review evidence; it does not guarantee approval
- Complements the vendor's authentication and secure-tool controls
- Does not certify the vendor or transfer legal responsibility
One place to enforce customer policy
The gateway team can wrap its central forwarding function once and make supported traffic from different agent teams answer to a common policy and evidence model.
- Filter supported discovery responses
- Remove recognized internal handoff fields from tool arguments
- Retain framework and agent identity in runtime evidence
For MCP suppliers: make governance part of the product story
Enterprise buyers increasingly need more than a statement that the server uses TLS, OAuth, and a valid schema. They need to understand how a customer can constrain high-impact use, preserve the originating actor and agent, review returned content, and investigate a disputed action. A published AgenticDome integration gives the supplier a concrete answer without requiring the supplier to embed every customer’s policy inside the MCP server.
Stronger review evidence
Document the protected forwarding path, supported methods, test cases, failure posture, and known limits for customer security review.
Customer-owned policy
Let each enterprise apply its tenant policy before routed calls reach the server while the vendor retains its own authorization and validation.
Clearer incident reconstruction
Correlate AgenticDome decision context with server and downstream logs to distinguish the proposed request, policy result, execution, and response.
Tenant isolation by design
Customer policy and evidence remain tenant-scoped. Cross-customer telemetry or threat sharing is not implied and requires separate lawful design and agreement.
What a supplier should not claim
An AgenticDome integration does not certify the MCP server, create an immutable record by itself, prove that every request reached the protected path, eliminate vendor responsibility, or transfer legal liability. It provides an independently operated action-policy and evidence boundary that can improve assurance when it is correctly integrated, tested, monitored, and retained with the vendor’s own security records.
Implemented MCP coverage
The public Python adapter has explicit handling for the operations below. It does not claim to cover every MCP method. Unknown and custom methods pass through unchanged unless the gateway applies its own protocol-method allowlist.
| MCP operation | Before forwarding | After response |
|---|---|---|
tools/call |
Tool, arguments, intent and optional delegation verification | Configured structured/text result sanitization |
tools/list |
Method authorization | Policy-based tool discovery filtering |
resources/read and resources/list |
URI/read or list-method authorization | Configured content sanitization or discovery filtering |
prompts/get and prompts/list |
Prompt/arguments or list-method authorization | Configured content sanitization or discovery filtering |
sampling/createMessage |
Method and argument authorization for compatible protocol use | Configured result sanitization |
| Supported streaming iterator | Request follows its method path | Chunk-by-chunk review when the transport exposes an iterator |
MCP-specific risks and the corresponding control
| Risk | Why it matters | AgenticDome control and boundary |
|---|---|---|
| Returned-content poisoning | A tool or resource can return instructions that a planner mistakes for trusted context. | Configured review of supported tool, resource, prompt, sampling and streaming results before reuse. |
| Misleading discovery | Descriptions and schemas influence which capability an agent selects. | Policy-based filtering for supported tools, resources and prompts list responses. |
| Delegated-tool misuse | An upstream agent's recommendation can be mistaken for authority to execute. | Optional manager authorization plus runtime verification and consumption at the matching specialist boundary. |
| Internal metadata leakage | SDK handoff fields should not become third-party business arguments. | Recognized AgenticDome decision/source fields are removed from forwarded tools/call arguments. |
| Sensitive reads and sampling | Resource, prompt and sampling paths can carry sensitive context across a trust boundary. | Independent method decisions and configured response review for the explicitly supported operations. |
| Unreviewed server routes | A direct client path can bypass a central gateway. | The wrapper governs routed traffic; inventory, egress control and removal of bypass routes remain operator responsibilities. |
From developer trial to governed production path
Network-free first proof
Run allowed, blocked, and poisoned-result scenarios locally before creating an account or contacting a live runtime.
Assigned enforcement runtime
Connect the same wrapper to a managed regional sidecar or a contracted Sovereign runtime inside the customer-controlled environment.
Open integration surface
Use the published Python and TypeScript SDK contracts while AgenticDome operates the tenant policy and decision service.
Testable production evidence
Prove live allowed, blocked, delegated, mutation, returned-content, and outage behavior against the assigned tenant sidecar.
Start without an account, then prove live policy
The local simulator demonstrates SDK control flow only. It does not contact AgenticDome, load a customer's policy, certify an MCP server, or generate production assurance evidence.
python3 -m venv .venv
source .venv/bin/activate
pip install "agenticdome-python-sdk[mcp]"
export AGENTICDOME_MODE=local_sim
agenticdome-demo --framework mcp --scenario bothFor live use, obtain the assigned runtime sidecar URL, tenant-scoped Runtime/SDK key and matching tenant ID. Wrap the real forwarding function, test allowed and blocked calls, test returned-content handling, confirm the selected outage posture, then run SDK Assurance and Performance Smoke against the same sidecar.
What remains your responsibility
Retain MCP authorization, consent for consequential actions, server-side authorization, schema and argument validation, secrets management, protocol allowlists, secure tool design, sandboxing, workload isolation, inventory, egress control, monitoring, backups and incident response.