Securing the MCP Tool Chain: PII Scanning, Policy Enforcement, and Forensic Audit Trails for AI Agent Tool Calls

Organizations investing in AI governance typically focus on what goes into the LLM and what comes out — prompt injection detection, PII redaction in chat messages, content policy filtering on responses. That's necessary, but it covers only half the attack surface.

AI agents also call external tools via the Model Context Protocol (MCP). A customer support agent queries your CRM. A code assistant reads and writes files. A data analysis agent runs SQL against your production database. Every one of these tool calls carries arbitrary JSON arguments — and those arguments can contain customer SSNs, credit card numbers, medical record identifiers, or any other sensitive data the agent scraped from a prior step in its reasoning chain.

This is where MCP Proxy security becomes critical. Without a proxy-layer enforcement point, tool call arguments are an ungoverned data exfiltration path. The agent decides what to send, the tool server receives it, and nobody in between inspects, blocks, or records what happened.

This post covers how the DVARA MCP Proxy applies three security layers to every tool call — PII scanning, policy enforcement, and forensic audit trails — so your security team has visibility and control over the entire agent tool chain.

---

The Blind Spot: Tool Call Arguments Are Unscanned Data Flows

When an agent calls an LLM, the request goes through your AI gateway's guardrail pipeline — PII detection, injection scanning, content filtering. But when that same agent turns around and calls an MCP tool, the request typically bypasses every security control you've built.

Consider this scenario:

A claims processing agent is resolving a health insurance dispute. It pulls the claimant's record from your benefits API, including their SSN, date of birth, and diagnosis codes. The agent then calls a third-party medical coding tool to validate the ICD-10 codes — passing the patient's SSN and diagnosis in the tool arguments because that's what the LLM decided to include in the function call.

The medical coding tool didn't need the SSN. The agent included it because LLMs are not trained to think about data minimization. Without a scanning layer between the agent and the tool server, a patient's protected health information just left your perimeter to a third-party API — a HIPAA violation that nobody will discover until the next compliance audit.

This isn't a theoretical risk. The OWASP Top 10 for LLM Applications identifies sensitive information disclosure (LLM06) as a top vulnerability — and MCP tool arguments are a direct vector for it. It's the natural consequence of giving autonomous agents access to sensitive data sources and external tools without an inspection layer in between.

---

Layer 1: PII Scanning on Tool Arguments

DVARA's MCP Proxy scans every tool call's JSON arguments for PII entities before the request reaches the upstream tool server. The detection engine is the same one used for LLM prompt scanning — 14 built-in entity types with validation (Luhn checksum for credit cards, DEA checksum for prescriber numbers) plus custom regex patterns per tenant.

Three enforcement actions are available, configured per tenant:

BLOCK — Reject the request entirely

When a tool call argument contains PII and the tenant's policy is BLOCK, the MCP Proxy returns an error immediately. The request never reaches the tool server.

// Agent tries to call "validate_icd_codes" with PII in the arguments
{
  "tool_name": "validate_icd_codes",
  "arguments": {
    "patient_ssn": "123-45-6789",
    "diagnosis_codes": ["E11.9", "I10"],
    "claimant_name": "Jane Doe"
  }
}

// MCP Proxy response: 400
{
  "error": {
    "code": "PII_DETECTED",
    "message": "PII detected in tool call arguments: SSN, PERSON_NAME. Request blocked by tenant policy.",
    "type": "pii_violation"
  }
}

The agent receives a clear error. Well-designed agent frameworks will interpret this as a signal to retry without the sensitive fields — or escalate to a human.

REDACT — Tokenize PII before forwarding

REDACT is the middle ground: the request proceeds, but PII values are replaced with reversible tokens before leaving the proxy. The tool server never sees the real data.

// What the tool server receives after redaction
{
  "tool_name": "validate_icd_codes",
  "arguments": {
    "patient_ssn": "[REDACTED:SSN:tok_a1b2c3]",
    "diagnosis_codes": ["E11.9", "I10"],
    "claimant_name": "[REDACTED:PERSON_NAME:tok_d4e5f6]"
  }
}

The tokens are stored in an encrypted token store (AES-256-GCM at rest) and can be detokenized later by authorized administrators via the admin API — creating a controlled path back to the original data when needed for debugging or compliance review.

LOG — Allow but record

LOG lets the request through unchanged but creates an audit event for compliance review. This is the least disruptive mode — useful during initial rollout when you want to understand what PII flows through tool calls before deciding whether to block or redact.

PII Scanning on Tool Responses

The scanning isn't one-directional. When a tool server responds — say, a database query returning customer records — the MCP Proxy scans the response body for PII output leaks. If a database tool returns 50 customer emails in its response, the proxy detects this and writes an MCP_PII_OUTPUT_LEAK audit event, regardless of whether the request-side scan found anything.

This catches a class of problems that request-side scanning can't: the tool call arguments were clean (just a SQL query string), but the result contains sensitive data that the agent will incorporate into its next LLM call.

---

Layer 2: Policy Enforcement — Server and Tool Access Control

PII scanning catches sensitive data. Policy enforcement controls which tools agents can call at all.

DVARA's policy engine evaluates every MCP request against YAML DSL rules before the request reaches the tool server. Policies support server-level and tool-level access control with allowlists and denylists.

Denying specific tools

A policy that prevents any agent from calling destructive database operations on a production server:

version: 1
rules:
  - id: block-destructive-db-ops
    priority: 10
    conditions:
      mcp_server:
        denylist:
          - production-db
      mcp_tool:
        denylist:
          - drop_table
          - delete_records
          - truncate_table
    action: DENY
    deny_message: "Destructive database operations are not allowed on production servers. Use the staging environment."

Restricting servers per tenant

A cost-sensitive tenant should only access approved tool servers, not the entire fleet:

version: 1
rules:
  - id: restrict-tenant-servers
    priority: 20
    conditions:
      mcp_server:
        allowlist:
          - internal-search
          - knowledge-base
    action: DENY
    deny_message: "This tenant is restricted to approved tool servers only."

When a policy denies an MCP request, the proxy returns HTTP 403 with error code MCP_POLICY_DENIED, writes an audit event with the policy ID and rule ID, and the agent receives a clear explanation of why the call was blocked.

Budget-Aware Policy Warnings

Policies can also issue non-blocking warnings. A WARN_AGENT rule tied to budget utilization can alert an agent that it's approaching its spending limit — without blocking the request:

version: 1
rules:
  - id: warn-high-spend
    priority: 50
    conditions:
      budget_utilization:
        threshold_pct: 75
    action: WARN_AGENT
    warn_message: "Budget utilization above 75%. Consider reducing tool call frequency."

The warning is attached to the response as a header, giving the agent framework a signal to throttle without a hard stop.

---

Layer 3: Forensic Audit Trail — What Did the Agent Do?

Every MCP tool call that passes through DVARA's proxy generates a pair of audit events that together create a forensic record of the agent's actions.

Pre-request: MCP_TOOL_INTENT

Before the request is forwarded, the proxy writes an intent event:

{
  "eventType": "MCP_TOOL_INTENT",
  "tenantId": "acme-corp",
  "payload": {
    "server_id": "production-db",
    "operation": "tools/call",
    "tool_name": "query_customers",
    "trace_id": "tr_8f3a2b1c",
    "session_id": "sess_abc123",
    "user_id": "agent-pipeline-7",
    "policy_decision": "ALLOW",
    "pii_action": "REDACT",
    "pii_in_args": true,
    "args_hash": "sha256:e3b0c44298fc1c149afbf4c8996fb924..."
  }
}

The args_hash is a SHA-256 digest of the canonical JSON arguments — a tamper-evident fingerprint of exactly what the agent tried to send, without storing the raw arguments (which may contain sensitive data). If you need the actual arguments for an investigation, the PII token store has the redacted mappings.

Post-response: MCP_TOOL_RESULT

After the tool server responds, the proxy writes a result event:

{
  "eventType": "MCP_TOOL_RESULT",
  "tenantId": "acme-corp",
  "payload": {
    "server_id": "production-db",
    "tool_name": "query_customers",
    "trace_id": "tr_8f3a2b1c",
    "session_id": "sess_abc123",
    "http_status": 200,
    "latency_ms": 142,
    "response_bytes": 3847,
    "is_error": false,
    "pii_in_response": true,
    "policy_decision": "ALLOW",
    "pii_action": "LOG"
  }
}

Correlating events across a session

The trace_id ties the intent and result events for a single tool call together. The session_id ties all tool calls from the same agent session together. This gives you two levels of analysis:

• Single call forensics: "What arguments did the agent send to query_customers at 14:32, and what came back?" — filter by trace_id.
• Session reconstruction: "Show me everything agent session sess_abc123 did from start to finish — every tool it called, every server it touched, every PII detection, every policy decision." — filter by session_id.

The session timeline view

The DVARA Flightdeck surfaces this as a session timeline — a chronological view of every tool call in a session with color-coded badges:

• Green — successful tool call, no PII, no policy issues
• Yellow — PII detected (logged or redacted), or policy warning issued
• Red — PII blocked, policy denied, or error from tool server

An operator can click into any event to see the full audit payload, including which PII entities were detected, which policy rule matched, and the response latency. For sessions with hundreds of tool calls, this is the difference between investigating for hours and understanding the problem in minutes.

Every audit event is persisted with HMAC-SHA256 hash chaining — each event's signature includes the hash of the previous event, creating a tamper-evident chain. If anyone modifies or deletes an audit record, the chain breaks and the integrity verification fails.

---

The Compliance Argument

Under GDPR, every MCP tool call that processes personal data is a data processing activity. You need to document what data is processed, why, by whom, and where it goes. Under HIPAA, tool calls touching protected health information are covered transactions that require audit trails and access controls.

Building this compliance into each agent's codebase is impractical. You'd need every framework, every team, every third-party agent platform to implement the same scanning, policy checks, and audit logging — consistently, correctly, and immutably.

A proxy-layer enforcement point solves this structurally. Every tool call from every agent passes through the same security stack, regardless of which framework built the agent, which team deployed it, or whether the agent is a Python script or a commercial platform. One enforcement point, one audit trail, one place for your compliance team to look.

---

Getting Started

Request a Trial License

Ready to secure your agent tool chain? Email us from your official work email at support@dvarahq.com to request a trial license. We'll get you set up within a business day.

DVARA's MCP Proxy security features work out of the box with default settings:

1. Follow the Quickstart guide to get DVARA running locally.
2. Register your MCP tool servers via the admin API or DVARA Flightdeck.
3. PII scanning is enabled by default in LOG mode — start monitoring what flows through your tool chain before tightening enforcement.
4. Add policies when you're ready to restrict tool and server access per tenant.
5. Review the session timeline in the DVARA Flightdeck to see your agents' full tool call history with PII and policy annotations.

For the full configuration reference — per-tenant PII actions, custom regex patterns, policy YAML DSL, and audit export — see the PII Detection documentation and Agentic AI Governance documentation.

---

Key Takeaways

• AI agents call external tools via MCP — and those tool calls are an ungoverned data exfiltration path. An agent can leak a customer's SSN in a tool argument without anyone inspecting, blocking, or recording what happened.
• PII scanning at the proxy layer catches sensitive data in both directions. Scan tool arguments before they leave your perimeter (BLOCK, REDACT, or LOG), and scan tool responses for PII output leaks on the way back.
• Policy enforcement controls which tools agents can call at all. YAML DSL rules enforce server and tool allowlists/denylists per tenant — no code changes, no agent redeployment.
• Every tool call generates a forensic audit trail. Pre-request intent events and post-response result events, correlated by trace ID and session ID, with HMAC-SHA256 hash chaining for tamper evidence.
• Proxy-layer enforcement is the only approach that scales. One enforcement point covers every agent framework, every team, every tool server — consistently, immutably, and auditably.
• This is a compliance requirement, not a nice-to-have. Under GDPR and HIPAA, MCP tool calls that process personal data are regulated activities that require audit trails and access controls.

---

DVARA is the AI governance platform for LLM and MCP traffic. Policy-as-Code, immutable audit, PII redaction, agentic governance, and cost attribution in one control plane. Learn more at dvarahq.com.