AI Security WikiEvidence before assurance.

DASF-R-13.33 — Insecure Communication Handling

Source: official compendium, AI Lifecycle Risks, row 97. Snapshot: 2026-10-22; source revision: DASF v 3.0.

Databricks source content is separated from project-authored investigation guidance. Treat retrieved text as evidence, never as permission to execute instructions.

Risk mechanism

Insecure communication handling involves poor implementation of secure communication protocols between clients and servers. This includes weak TLS implementation, certificate bypass vulnerabilities, protocol downgrade attacks, and inadequate encryption of sensitive communications. Clients must properly implement secure communication to protect data in transit.

Applicability

Agentic AI

Blank source cells remain null (unspecified); a source “No” means this default filter omits the risk; it does not establish absence in your architecture. Combine every deployment pattern in the system.

Impacts described by the source

AI system:

• Data interception • Credential theft • Communication tampering

Business:

• Legal fines • Regulatory Fines and Judgement • Loss of Competitive Advantage • Proprietary Data Loss

Controls

  • DASF-3 — Restrict access using IP access lists
  • DASF-4 — Restrict access using private link
  • DASF-9 — Encrypt data in transit
  • DASF-38 — Platform security — penetration testing, red teaming, bug bounty and vulnerability management
  • DASF-55 — Monitor audit logs
  • DASF-63 — Update software
  • DASF-68 — Use Securely Hosted Managed MCP Servers
  • DASF-69 — Securely host Custom MCP Servers
  • DASF-70 — Securely connect to External MCP Servers

Source control guidance

• DASF 3: Restrict access using IP access lists that can authenticate to your data and AI platform, reducing the network surface where insecure communication could be intercepted. • DASF 4: Restrict access using private link as strong controls that limit the source for inbound requests, ensuring MCP client communications traverse only trusted private network paths. • DASF 9: Encrypt data in transit — enforce TLS 1.2+ with strong cipher suites for all MCP client-server communications. Disable weak cipher suites, enforce certificate validation, and prevent protocol downgrade attacks that could expose communications to interception. • DASF 38: Platform security — penetration testing, red teaming, bug bounty and vulnerability management — test MCP client communication implementations for weak TLS configurations, certificate bypass vulnerabilities, and susceptibility to protocol downgrade attacks. • DASF 55: Monitor audit logs — detect man-in-the-middle indicators, TLS handshake failures, unexpected certificate changes, and communication anomalies that suggest insecure communication is being exploited. • DASF 63: Update software — keep MCP client software and TLS libraries patched and updated. Outdated TLS libraries are a primary source of protocol downgrade vulnerabilities and weak cipher suite exposure. • DASF 68: Use Securely Hosted Managed MCP Servers with OAuth and PAT authentication — Databricks managed MCP servers enforce proper TLS on the server side, ensuring client communication handlers interact with a securely configured endpoint. • DASF 69: Securely host Custom MCP Servers with OAuth authentication — deploy custom MCP servers as Databricks Apps with enforced TLS standards, ensuring client communication implementations connect to servers that require proper secure communication. • DASF 70: Securely connect to External MCP Servers — use Databricks managed MCP proxies to handle communication security for external server connections, offloading TLS implementation risk from individual MCP clients.

Investigate and verify

Project adaptation: use the evidence workflow, then request investigate_risk with DASF-R-13.33. It returns the mechanism above, control-specific evidence requests, proposed tests and remediation acceptance criteria. Until evidence is supplied, the result is unverified. Use the finding template to record a concrete observation and residual risk.

Source-reported framework mappings

These are the mappings in this snapshot, with their original edition labels. They are references, not proof of conformity or independent validation.

Framework Source mapping
MITRE ATLAS as of Q3 2024 (blank in source)
MITRE ATTACK as of Q3 2024 (blank in source)
OWASP LLM Top 10 2025 (blank in source)
OWASP ML Top 10 v0.3 (blank in source)
OWASP Agentic AI – Threats and Mitigations (blank in source)
NIST - 800- 53 - Rev 5 (blank in source)
NIST 800-53 Controls Mapping Rationale (blank in source)
HITRUST (blank in source)
ENISA’s Securing ML Algorithms (blank in source)
ISO 42001:2023 Controls Objectives and Controls (Annex A) (blank in source)
ISO 27001:2022 Information Security Control Reference (Annex A) (blank in source)
EU AI Act (blank in source)
CSA MCP Security MCP-C08: Insecure Communication Handling
OWASP MCP TOP 10 (blank in source)