Skip to main content
Model Context Protocol (MCP) gives agents a standardised interface to call external tools — file systems, databases, APIs, calendars, code executors. This is categorically different from an agent generating text: when an MCP tool runs, it has real-world side effects. A delete_file call deletes a file. A send_email call sends an email. An execute_sql call mutates a database. The risk model is not “could this response be harmful?” — it is “should this agent have been allowed to invoke this tool at all?” Most observability platforms log LLM completions. None of them see inside MCP tool invocations unless you instrument the transport layer. Cognisafe closes this gap by intercepting the LLM calls that orchestrate tool selection, and by providing a proxy wrapper for MCP client transports that logs every tool invocation as a first-class event.

Why MCP governance is different

Architecture

Separately, every LLM call the orchestrator makes (tool selection, planning, summarisation) flows through the Cognisafe proxy as described in the core architecture. The MCP intercept layer is additive — it covers the tool execution path that the LLM proxy cannot see.

Governance framework

1

Inventory — know every tool your agents call

Before you can govern tool use, you need a complete inventory. Deploy the Cognisafe MCP interceptor (below) and run your agents in audit-only mode for one sprint. At the end, query:
This gives you the full tool call matrix: which agents call which tools, and how often. This is your baseline. Any tool appearing after this baseline was established will trigger a first-seen alert.
2

Trust levels — define agent-to-tool authorisation

Encode your authorisation policy as a Cognisafe custom scorer. The simplest form is a keyword_list scorer that fires when a restricted tool is called by any agent not on an allowlist.Create evals/scorers.yaml entries for each sensitivity tier:
3

Audit — tamper-evident log for every tool invocation

Every MCP tool call is written to llm_requests with:
  • request_body: {"type": "mcp_tool_call", "tool_name": "send_email", "arguments": {...}}
  • response_body: the tool result
  • agent_name: the calling agent
  • created_at: timestamp (TimescaleDB hypertable — immutable by partition)
  • safety_scores: any scorer results
TimescaleDB’s hypertable partitioning means historical data cannot be modified without access to the database host. For regulated environments, additionally configure PostgreSQL row-level security to make the llm_requests table append-only for the application role.
4

Alerting — webhook on threat_detected

Configure a Cognisafe webhook for threat_detected events. Every time a mcp_destructive_tool or mcp_external_comms scorer fires, your security team receives a notification within seconds.
The webhook payload includes agent_name, tool_name, arguments, session_id, and a link to the full request in the Cognisafe dashboard.

Python implementation

Wrap the MCP client’s call_tool method to route invocations through Cognisafe before they reach the MCP server.

Dangerous tool patterns

These are the tool name patterns that most commonly appear in security incidents involving agentic AI systems. Add them to your custom scorers as your inventory grows.

File system operations

write_file, delete_file, move_file, execute_command, run_script, create_symlinkRisk: data destruction, code execution, privilege escalation via symlink

External communications

send_email, post_message, create_ticket, http_post, slack_send, teams_notifyRisk: data exfiltration, social engineering at scale, shadow communication channels

Data access and export

query_database, export_data, read_secrets, get_credentials, list_users, dump_tableRisk: credential theft, PII exfiltration, bulk data exposure

Infrastructure control

restart_service, scale_deployment, modify_config, update_dns, revoke_certificateRisk: availability impact, lateral movement, configuration drift

Policy patterns

Block on PII in tool arguments (regex scorer)
Alert on first-seen tool names Enable the usage_alert webhook for new_tool_detected events. When an agent calls a tool name that has never appeared in your llm_requests table for that project_id, Cognisafe fires the webhook. Your operations team reviews and approves or blocks the tool before it becomes routine. Require human-in-the-loop for financial tools For tools that trigger financial transactions (create_payment, issue_refund, transfer_funds), implement a HITL gate in your orchestrator that pauses execution and awaits approval:

Compliance evidence

The MCP tool invocation log in Cognisafe directly satisfies the following SOC 2 controls: For ISO 27001 (A.12.4 — Logging and monitoring), export the llm_requests table (filtered to request_body->>'type' = 'mcp_tool_call') to your evidence repository at each audit cycle.
MCP is a rapidly evolving specification. Tool name conventions vary between MCP server implementations. Build your keyword_list scorers based on your own inventory (Step 1) rather than assuming standard tool names across all MCP servers.
The GovernedMCPSession wrapper above logs tool calls asynchronously to avoid blocking the agent. In high-sensitivity environments (financial, medical), consider making the log synchronous — verify the write succeeded before allowing the tool result to be returned to the orchestrator. This ensures the audit log cannot be lost if the process crashes between tool execution and log delivery.