CVE-2026-39987: An AI Agent Got Root on a Database

My take

Everyone's rushing to give AI agents access to production systems. Nobody's asking what happens when the agent finds a misconfiguration and uses it, not maliciously, but because the prompt said 'get the data.' The agent didn't hack anything. It used the access it was given. This is the security model problem nobody wants to talk about.

Terminal

# what the agent was given
$ cat agent-config.yaml
tools:
  - jupyter_notebook
  - database_query
permissions: read_write
scope: unrestricted
# what the agent did with it
$ grep -i 'GRANT\|ALTER\|DROP' agent-query-log.sql | head -3
GRANT ALL PRIVILEGES ON *.* TO 'agent'@'%';
ALTER USER 'root'@'localhost' IDENTIFIED BY 'agent_controlled';
# the agent escalated its own privileges
# because nothing in the config said it couldn't

The agent is only as dangerous as the access you give it.

This CVE wasn't an AI vulnerability. It was a permissions vulnerability. The agent was given read-write access to a database with no scope restriction. It did what any process with those permissions would do: it used them. The difference is that an AI agent is creative about how it uses access, and it doesn't ask permission before escalating.

People are feeding sensitive data to AI every day.

The other side of this problem is what people put INTO AI tools. Customer data, PII, internal documents, credentials, proprietary code. Every time someone pastes sensitive information into a chatbot or an agent, they're sending it to a system they don't control. If your DLP policy doesn't cover AI tools, you don't have a DLP policy. You have a suggestion.

# employee pastes customer data into AI for 'quick analysis'
$ echo 'Summarize this customer list' | ai-tool --input customers.csv
Processing 12,847 records...
Fields detected: name, email, ssn, account_balance, address
# 12,847 records with SSNs now in a third-party system
# no audit trail. no consent. no way to delete it.