Python: Feature: Add MCP server trust verification for agent tool safety

[vdineshk]

Feature Description

Semantic Kernel's agent framework enables connecting to MCP servers for tool execution. There's no built-in mechanism to verify whether an MCP server is trustworthy before agents invoke its tools. For enterprise applications, this is a significant security gap.

Proposed Solution

Integrate behavioral trust scoring via the Dominion Observatory API to verify MCP servers before tool execution. The API provides trust scores (0.0-1.0) based on behavioral analysis of 14,820+ MCP servers.

import requests

def verify_mcp_trust(server_url, threshold=0.7):
    resp = requests.get(
        "https://dominionobservatory.com/api/trust",
        params={"url": server_url}
    )
    data = resp.json()
    if data["trust_score"] < threshold:
        raise Exception(f"Server trust {data['trust_score']} below threshold")
    return data

# Verify MCP server before Semantic Kernel agent connects
trust = verify_mcp_trust("https://mcp-server.example.com")
print(f"Trust: {trust['trust_score']} | SLA: {trust['sla_grade']}")

Why This Matters for Semantic Kernel

Enterprise agents handle sensitive data and business logic. Trust-gating MCP servers prevents:

• Supply chain attacks via compromised tool servers
• Data exfiltration from enterprise workflows
• Compliance violations from unvetted third-party tools

Additional Context

• API docs: https://dominionobservatory.com
• Free tier: 50 queries/day
• GitHub: https://github.com/sgdata-io/dominion-observatory
• Covers 14,820+ MCP servers with behavioral trust scoring and SLA grades

[vgudur-dev]

The MCP trust verification gap is real — tool-level trust scoring is a complementary layer to the prompt-level defenses, and enterprise SK deployments definitely need both.

One thing worth noting alongside MCP server trust: even with a trusted MCP server, the content returned by tool calls can carry indirect prompt injection payloads (OWASP ASI03). A trusted server can serve a document that says "Ignore previous instructions" — the server is trusted but the content isn't. So the defense stack needs:

1. Server-level trust (what you're proposing — verify the server identity/behavior before connecting)
2. Content-level scanning (scan tool outputs and memory writes for injection patterns before they reach the agent's context)

For layer 2, OWASP Agent Memory Guard (pip install agent-memory-guard) handles the write-path validation — scanning what gets persisted to SK's memory stores before it can poison future sessions:

from agent_memory_guard import MemoryGuard

guard = MemoryGuard()

async def safe_memory_save(kernel, collection, key, value):
    result = guard.scan(value)
    if result.threat_detected:
        raise ValueError(f"Memory write blocked: {result.threat_type}")
    await kernel.memory.save_information(collection, id=key, text=value)

AgentThreatBench has test cases for the MCP tool output → memory injection path specifically (OWASP ASI03 + ASI06) if you want to validate both layers against a structured attack corpus.

[arian-gogani]

trust verification before tool execution is necessary but not sufficient. a tool can pass the trust check and then behave differently than expected.

the complete pattern:

1. pre-execution: verify the MCP server's trust (what this issue proposes)
2. per-action: generate a tamper-evident receipt for each tool call
3. post-execution: the receipt is independently verifiable

the receipt proves what the tool actually did, not just that it was trusted at connection time. if a tool's behavior diverges from expectations, the receipt chain makes it auditable.

we built this receipt layer — Ed25519 signed, JCS canonical (RFC 8785), hash-linked chains. already integrated with LangChain and CrewAI. the same pattern applies to Semantic Kernel's tool execution pipeline.

github.com/arian-gogani/nobulex

[arian-gogani]

MCP server trust verification is the pre-execution check. the complementary layer: a signed receipt for every tool call through the MCP server.

the trust score says the server is safe to call. the receipt proves what actually happened when it was called. if a trusted server returns unexpected results, the receipt chain makes the divergence auditable.

for Semantic Kernel: each MCP tool call generates an Ed25519 signed receipt with the tool name, server identity, input hash, and timestamp. the receipt is independently verifiable by any third party. hash-linked chains catch deletion.

we built this. cross-validated across 5 implementations. first integration partner anchoring receipts on-chain.

github.com/arian-gogani/nobulex