A read-only MySQL collector can still expose another user’s SQL, overload a production server, and turn sensitive incident evidence into a permanent AI data leak.

Technology and product capabilities in this series are evaluated as of June 30, 2026.

Situation

The previous MySQL investigations used Performance Schema, sys, process state, InnoDB status, logs, plans, CloudWatch, and Aurora topology. These sources can reveal object names, accounts, hosts, query structure, and literals. The security boundary starts at collection, continues through storage, and ends with the recommendation and audit trail.

The LLM needs no database credential or RDS permission. It needs a sanitized evidence pack; a broker translates approved requests into bounded collector operations.

The Problem

“Read only” describes mutation authority, not safety or confidentiality. A diagnostic query can scan an expensive view, consume a scarce connection, or retrieve other accounts’ statements. Logs can contain full SQL; normalized digests preserve object identifiers. Comments, errors, and identifiers are untrusted input, not model instructions.

MySQL privileges also do not map neatly to evidence sensitivity. PROCESS permits visibility into other users’ threads and is required for SHOW ENGINE INNODB STATUS. CONNECTION_ADMIN goes much further: it can kill other accounts’ sessions and bypass important connection and read-only restrictions. Granting both because they are “DBA diagnostics” quietly turns an evidence collector into an operator.

Aurora adds an audit ambiguity. Advanced Auditing records selected database activity; CloudTrail records RDS API calls. Neither records evidence versions, redaction, model requests, or policy decisions.

The core question is: how do we collect enough MySQL evidence to prove a root cause while keeping data exposure, diagnostic load, production authority, and audit deletion outside the LLM’s reach?

Build a MySQL Diagnostic Access Plane

Put deterministic controls between production evidence and model reasoning:

flowchart TD
    A[MySQL on EC2 or Aurora MySQL] --> B[allowlisted diagnostic collectors]
    C[CloudWatch logs metrics and RDS events] --> B
    B --> D[raw evidence vault — restricted]
    B --> E[deterministic classification and redaction]
    E --> F[versioned sanitized evidence pack]
    F --> G[LLM reasoning — no database or AWS credential]
    G --> H[approved request catalog]
    H --> I[policy broker — scope budget and expiry]
    I --> B
    G --> J[observations hypotheses and proposed actions]
    K[independent audit store] --> L[DBA and security review]
    B --> K
    E --> K
    G --> K
    I --> K
    J --> L

Separate baseline collection, elevated diagnostics, cloud retrieval, transformation, and audit identities.

IdentityPermitted purposeExplicitly excluded
Baseline MySQL collectorFixed status, wait, lock, and digest queriesDML, DDL, global settings, arbitrary procedures
Elevated diagnostic roleExpiring cross-session and SHOW ENGINE accessCONNECTION_ADMIN, session killing, parameter changes
AWS telemetry readerNamed metrics, logs, events, and topologyModify, reboot, fail over, resize, reconfigure
Evidence transformerRead raw objects; write sanitized versionsDatabase and production API access
LLM runtimeRead sanitized packs; emit analysisCredentials, arbitrary SQL, object deletion
Audit writerAppend lineage and decisionsProduction changes and record deletion

Do not grant broad EXECUTE merely to make the sys schema convenient. MySQL documents sys as a set of views, procedures, and functions over Performance Schema; some procedures change Performance Schema configuration. Grant only the objects and operations the collector contract actually requires.

Symptoms

Security or operational smellLikely boundary failureImmediate concern
Collector uses an application or administrator accountIdentity separation is absentExcessive, unattributable access
Raw slow or audit logs enter the promptSanitization is bypassedLiterals, personal data, tokens, and query comments can escape
Collector has PROCESS permanentlyElevated visibility became baseline accessOther accounts’ statements and hosts are broadly exposed
Collector has CONNECTION_ADMINDiagnosis and intervention are combinedIt can kill sessions and bypass selected restrictions
General log stays enabled for AI analysisCollection is uncontrolledPlaintext volume and overhead
CloudTrail is called the database audit trailControl plane and SQL are conflatedEngine and model gaps
Model can compose arbitrary SQLPrompt policy became authorizationExpensive, novel, or sensitive queries can execute

First Five Checks

1. Inventory what every evidence source can reveal

Classify fields before collection. Digest normalization replaces literals and removes comments, but preserves object identifiers; Performance Schema can retain a sample statement. Slow, general, and Aurora QUERY audit events can carry SQL text. Plans, process state, and locks expose identifiers, estimates, users, hosts, and statements.

Default to aggregates and digests. Admit full SQL only through an explicit incident exception.

2. Split baseline evidence from elevated evidence

Start with connection-safe status and allowlisted summary tables. Grant object-level SELECT only where practical. Activate a separately audited role for cross-session evidence only when the incident requires it, and expire that access automatically.

With PROCESS, an account can see all threads; without it, a nonanonymous account normally sees its own. SHOW ENGINE also requires PROCESS. Keep CONNECTION_ADMIN, SYSTEM_VARIABLES_ADMIN, account and role administration, DML, DDL, and GRANT OPTION out of both tiers.

For Aurora, IAM authentication can replace a stored password. Its token is valid for 15 minutes, but expiration does not end an established session. The broker must still bound session and role lifetime.

3. Put resource limits in the broker

The model selects a collector ID; it does not write SQL. Each entry fixes the statement, target, rows, bytes, timeout, concurrency, window, and topology role. Reject unknown or out-of-range parameters.

Reuse a small bounded pool. AWS documents a 200-connections-per-second throttle for new IAM-authenticated connections and recommends pooling. Set the collector cap far lower. A reader can protect the writer for suitable evidence, but remains sensitive and disruptable.

4. Redact deterministically and preserve correlation

Parse known fields before inference. Drop unused columns and replace sensitive literals, accounts, hosts, comments, and identifiers. Use keyed pseudonyms where correlation matters. Record the policy version and artifact hashes.

Digests are not automatically public-safe. Put logs, comments, identifiers, and errors in typed untrusted fields, never tool instructions. If classification is uncertain, quarantine the statement for review.

5. Reconcile four audit planes

Link four streams with one incident ID:

  • MySQL or Aurora audit evidence for collector connections and selected statements;
  • CloudWatch log access and retention controls for exported database logs;
  • CloudTrail events for RDS API calls such as parameter-group or cluster changes;
  • pipeline lineage for collector, target, window, hashes, redaction, model, tool request, policy result, output, and human decision.

No stream is complete. Separate audit administration, test denied-request recording, and expire sensitive evidence deliberately.

Decision Tree

flowchart TD
    A[diagnostic question] --> B{aggregate or digest sufficient}
    B -->|yes| C[run baseline collector]
    B -->|no| D{raw text necessary and approved}
    D -->|no| E[request safer evidence or stop]
    D -->|yes| F[activate time-limited elevated role]
    F --> G[collect bounded raw artifact]
    C --> H[apply field allowlist and redaction]
    G --> H
    H --> I{classification confidence acceptable}
    I -->|no| J[quarantine for human review]
    I -->|yes| K[seal sanitized evidence pack]
    K --> L[LLM correlates evidence]
    L --> M{request matches approved catalog}
    M -->|no| N[deny and audit]
    M -->|yes| O[broker checks scope budget and expiry]
    O --> C

What the LLM Can and Cannot Do

LLM mayLLM may not
Summarize sanitized metrics, waits, digests, plans, and logsReceive raw logs or sampled SQL by default
Link observations to artifact IDs and windowsHold database or AWS credentials
Rank hypotheses and state contradicting evidenceConnect to MySQL or call RDS APIs directly
Request a named collector with bounded parametersGenerate arbitrary SQL for automatic execution
Draft remediation and validationKill sessions, set variables, alter objects, or change accounts
Flag missing audit coverage or uncertain redactionEnable or disable logging, auditing, failover, or deletion controls
Recommend escalation to a DBA or security reviewerApprove its own request, erase evidence, or declare success unilaterally

In Practice

PROCESS controls cross-account thread visibility, and SHOW ENGINE INNODB STATUS requires it. It is an evidence-expansion switch, not a harmless default. MySQL documents CONNECTION_ADMIN separately: it can kill other accounts’ threads and bypass selected connection, offline-mode, and read-only restrictions.

Performance Schema digest documentation says literals become markers and comments disappear, but object identifiers remain; a representative statement can also be sampled. “Normalized” is not “non-sensitive.”

Aurora Advanced Auditing supports CONNECT, QUERY, QUERY_DCL, QUERY_DDL, QUERY_DML, and TABLE. QUERY records all queries in plain text, including failures, and includes Aurora monitoring traffic. Select event classes and identities deliberately.

Aurora can publish error, general, slow-query, and audit logs to CloudWatch Logs. Disabling export does not delete existing log groups or streams. CloudTrail records RDS API actions, not database SQL or model lineage.

Remediation Options

Existing riskSafer remediationVerification
Shared application credentialDedicated collector identityGrants, logs, and secret inventory agree
Permanent broad PROCESSTime-limited elevated role for named incidentsAccess expires and a denied post-expiry test is logged
Free-form model SQLVersioned collector catalog behind a policy brokerUnknown query IDs and parameters fail closed
Raw SQL in promptsAggregate-first collection plus deterministic redactionSeeded secrets and identifiers never reach the sanitized pack
General logging left onTime-bounded capture with an ownerStart, stop, volume, and retention are recorded
Broad AWS operator roleResource-scoped telemetry readerModify, reboot, failover, and parameter-change tests are denied
One ambiguous audit streamReconciled engine, cloud, pipeline, and approval recordsOne incident ID traces the complete decision chain

Rollback Plan

If collection causes load or exposure, stop schedules and the connection pool. Revoke the diagnostic role and confirm new connections and elevated queries fail. Restore incident-specific logging or parameter changes; disabling Aurora CloudWatch export leaves existing records in place.

Quarantine affected artifacts, remove them from retrieval, revoke storage and key access, and rotate exposed credentials. Handle CloudWatch and object-storage retention independently. Preserve hashes and the security-event record, and audit authorization, revocation, and residual copies.

Where It Breaks

Failure modeWhy it survives a superficial guardrailRequired response
Collector has only SELECTReads can still be expensive and sensitiveEnforce catalog, budgets, timeouts, rows, bytes, and concurrency
Digest text is called anonymousSchema and table names remainClassify identifiers and redact by policy
Aurora audit uses QUERY everywherePlaintext volume and internal traffic obscure signalSelect event classes and users intentionally
Prompt injection filter is enabledDetection is probabilistic, not authorizationTreat evidence as data and enforce tools outside the model
IAM token expires quicklyExisting sessions continue after authenticationBound session lifetime, role duration, and connection pool behavior
Logs are centralizedCentralization does not ensure least privilege or expiryTest access, retention, and deletion
CloudTrail is enabledIt captures RDS APIs, not the entire SQL and LLM chainReconcile cloud, engine, pipeline, and human records
Redaction removes every identifierPrivacy improves but causal correlation disappearsUse approved keyed pseudonyms and preserve restricted raw evidence

What the LLM Cannot Do

Explicit operational boundaries govern the LLM:

  • No Raw Customer Data: The LLM must not receive raw rows, bind values, or unnormalized statement text from the slow query log, events_statements_history, or SHOW PROCESSLIST. Send digest text, digest hashes, timings, and row-examined counts — never literals.
  • No Autonomous Production Execution: The LLM cannot run ALTER TABLE, SET GLOBAL, KILL, index DDL, replication commands, or instance modifications. It proposes; a human authorizes, applies, validates, and holds the rollback condition.
  • No Causal Conclusion Without Contradicting Evidence: Every hypothesis must cite both the telemetry that supports it and the telemetry that would falsify it. A ranked hypothesis with no disconfirming test attached is an assertion, not a diagnosis.
  • No Silent Gap-Filling: Where the evidence pack lacks a required signal, the LLM must name it explicitly under missing evidence rather than inferring a plausible value. “Not collected” and “collected and normal” are different findings and must never be merged.
  • No Change Without a Human Gate: Production changes require human authorization, a stated validation signal, and a defined rollback condition agreed before the change is applied.

What to Do Next

  • Problem: Read-only MySQL diagnostics can expose workload content and affect production; engine and cloud logs leave model-accountability gaps.
  • Solution: Give the LLM no credentials, split baseline and elevated evidence identities, constrain collection through a deterministic broker, sanitize before inference, and reconcile four independent audit planes.
  • Proof: Seed a literal, identifier, SQL comment, forbidden request, expired role, and prohibited RDS action. Sensitive content must disappear or be pseudonymized; prohibited actions must fail; decisions must remain traceable.
  • Action: Inventory current collector grants and evidence fields, then implement denial and leakage tests before enabling another source or giving an LLM access to production-derived evidence.

The next article starts the PostgreSQL track on EC2: classifying sessions, wait events, operating-system pressure, and I/O before the investigation moves into SQL plans.

Sources