[neil_naveen]

Isn't the MCP endpoint that allows AI agents to run custom SQL queries, essentially letting your monitoring database be manipulated by a potentially malicious AI agent? Like, if the AI agent has full reign over the DB and it can't find a solution to, let's say, a perf bug, it may just rewrite that data and say it has "solved" the bug. And this is literally the least concerning example I could come up with.

[jimmypk]

@neil_naveen The read-only mode wongarsu mentions closes the direct modification vector, but there's a subtler one not addressed: prompt injection via the telemetry itself. If the MCP server traces arbitrary workloads, a malicious process can craft CUDA kernel names, string arguments, or function identifiers that produce adversarial text in the trace DB. The LLM reads those verbatim as part of its context and may follow embedded instructions.

This is indirect prompt injection through the observation channel rather than through user input. Read-only access and invocation logging both assume the threat arrives from outside the pipeline. When the observed data itself is the attack surface, you need output sanitization or context sandboxing before telemetry reaches the model. Multi-tenant or production environments where the MCP server traces workloads from multiple teams would be particularly exposed.

[wongarsu]

Maybe they have limited the MCP endpoint to reject any query that modifies the db. With sqlite that's probably easily achieved by opening the db in read-only mode (as opposed to the role-based approach you'd take with most other dbs)