This vulnerability exposes a pattern security teams need to internalize: AI agent protocols like MCP are fundamentally changing what 'internal' means. The get_server_settings tool in ArcadeDB exposed the cluster token (arcadedb.ha.clusterToken) through an MCP endpoint designed for agent debugging. Combined with unauthenticated header injection via X-ArcadeDB-Cluster-Token and X-ArcadeDB-Forwarded-User, an attacker who can instruct an AI agent can chain these to impersonate root and compromise the cluster.
The critical insight here is that the attack path isn't 'attacker → database directly.' It's 'attacker → AI agent → MCP tool → credentials → header injection.' The agent becomes the attacker's intermediary, and agents have fundamentally different trust models than human-operated interfaces—they process prompts from potentially untrusted sources and programmatically chain operations a human wouldn't bother linking. That's why standard scanners miss this: they're looking for direct exploitation, not adversarial prompt injection into an agent that happens to have privileged tools.
Treat MCP endpoints as external attack surfaces. Don't assume the database's ACL framework applies to tools accessed through agent protocols—the calling context has fundamentally changed. Verify that any headers controlling authentication or impersonation validate the request actually came through the expected authentication path, not just that they're present.
The CVSS 7.5 with EPSS 0.0025 gap likely reflects two things: MCP tooling is obscure enough that scanners haven't learned to probe it, and the threat model of 'AI agent as attack vector' hasn't been priced into detection yet. This isn't a niche problem—every database getting an MCP wrapper today is repeating ArcadeDB's mistake if they haven't audited which tools expose configuration state.