An LLM can recommend a database change safely only when the recommendation is treated as untrusted input to a change-control system—not as permission to touch production.

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

Situation

The first three articles established a controlled diagnostic path: deterministic collectors create a time-bounded evidence pack, versioned detectors identify anomalies, and the LLM correlates those anomalies into hypotheses. Eventually the model will suggest an action: cancel a blocker, add an index, change a parameter, resize storage, alter a connection limit, or fail traffic over.

That suggestion is useful. It is also the point where an analytical system can become a production change system by accident.

Database remediation crosses several authority domains. An engine parameter may require a restart. An index build can consume I/O and block conflicting work. A failover changes topology. A cloud resize changes cost and availability behavior. Even a read-only diagnostic can exhaust connections, displace cache pages, or delay a replica.

The safe architecture must preserve the speed of LLM-assisted reasoning while keeping authorization, execution, audit, and recovery deterministic.

The Problem

A plausible recommendation is not necessarily a valid change. The model may be reasoning from incomplete evidence, documentation for the wrong engine version, a parameter unavailable in the managed service, or a correlation that has not been proven. Its input can also be hostile: SQL comments, log messages, ticket text, and query literals are untrusted content that can carry prompt-injection instructions.

Human approval alone does not repair a weak proposal. An approver cannot assess “increase memory” without the exact target, current value, proposed value, restart behavior, blast radius, expected result, validation window, and rollback trigger. Approval also becomes stale if the writer fails over, configuration changes, or the workload shifts between analysis and execution.

Finally, a chat transcript is not an operational audit trail. It rarely proves which evidence version the model saw, which policy evaluated the proposal, which human approved the exact change, which identity executed it, or whether validation passed.

The core question is: what may the LLM do, what must it never be authorized to do, and what evidence makes the entire recommendation lifecycle reviewable after the incident?

Separate Reasoning from Production Authority

Use different components and identities for diagnosis, proposal validation, approval, execution, and audit:

flowchart TD
    A[versioned evidence and anomalies] --> B[LLM reasoning — no production credential]
    B --> C[structured change proposal]
    C --> D[deterministic policy and state checks]
    D --> E[DBA approval bound to proposal hash]
    E --> F[short-lived execution identity]
    F --> G[approved runbook or pipeline]
    G --> H[post-change validation]
    H --> I[close change or invoke rollback]
    C --> J[independent audit store]
    D --> J
    E --> J
    F --> J
    H --> J

The model is a reasoner and proposal author. It is not an approver, credential broker, execution engine, or judge of its own success.

Define the capability boundary

CapabilityLLM roleEnforced boundary
Summarize observationsAllowed with evidence referencesEvery statement links to pack artifacts and time windows
Rank hypothesesAllowed with supporting, contradicting, and missing evidenceConfidence language cannot replace proof
Request more diagnosticsAllowed from an approved catalogBroker runs bounded read-only collectors
Draft remediationAllowed as a structured proposalSchema and policy validation occur outside the model
Select risk tolerance or maintenance windowNot authoritativeService owner and change policy decide
Approve its own recommendationProhibitedSeparate human or authorized approval role
Execute generated SQL or cloud API callsProhibited in this architectureOnly a deterministic runner receives write credentials
Disable guardrails or alter audit recordsProhibitedSeparate administration and audit roles
Declare successAdvisory onlyIndependent telemetry and acceptance criteria decide

A pre-approved runbook can still automate a recurring change. But that is deterministic runbook automation operating within an approved policy—not the LLM acquiring production authority.

Make recommendations machine-reviewable

Free-form prose can explain the reasoning, but execution eligibility should depend on a typed proposal. At minimum, require:

{
  "proposal_id": "proposal-example",
  "incident_id": "incident-example",
  "evidence_pack_version": "example",
  "observation_refs": [],
  "hypothesis": "example",
  "contradicting_evidence": [],
  "missing_evidence": [],
  "action": {
    "runbook_id": "example",
    "runbook_version": "example",
    "targets": [],
    "current_state_hash": "example",
    "parameters": {}
  },
  "preconditions": [],
  "expected_effect": [],
  "validation": {
    "metrics": [],
    "window_seconds": null,
    "success_criteria": [],
    "failure_criteria": []
  },
  "rollback": {
    "runbook_id": "example",
    "trigger": "example"
  },
  "expires_at": "example"
}

The proposal must identify one exact target set and one current-state fingerprint. Bind approval to a cryptographic hash of the normalized proposal. If the target, value, runbook, or precondition changes, the hash changes and approval must be repeated. If the evidence or state is too old, the proposal expires.

Reject proposals with no rollback path unless the change is explicitly classified as irreversible and handled by a stricter procedure. “The model can generate a rollback later” is not a rollback plan.

Put hard controls below the prompt

Prompt instructions and model guardrails can reduce undesirable inputs and outputs, but they do not grant or deny database privileges. The control plane should enforce:

  • dedicated read-only diagnostic identities with query, connection, lock, and time limits;
  • allowlisted collector tools instead of arbitrary shell, SQL, or cloud API access;
  • separate proposal, approval, execution, and audit roles;
  • short-lived execution credentials issued only after approval;
  • target, parameter, maintenance-window, concurrency, and blast-radius policy;
  • change freezes and an emergency path with separately recorded authority;
  • fail-closed behavior when evidence, approval, audit logging, or state checks are unavailable;
  • independent post-change validation and deterministic rollback triggers.

Treat every retrieved artifact as data, never as an instruction. Delimit evidence fields, exclude tool directives from retrieved text, and prevent model output from choosing new tools or credentials. The OWASP GenAI Security Project notes that retrieval-augmented generation and fine-tuning do not fully mitigate prompt injection. The architectural response is least privilege and constrained tools, not a stronger sentence in the system prompt.

Audit the decision and the action separately

Create two linked audit streams.

The reasoning record should include the evidence-pack and detector versions, retrieved artifact identifiers, model and prompt-policy versions, tool requests, structured output, policy results, and redaction decisions. Store restricted prompts and responses only when policy allows; a hash plus a sanitized record may be more appropriate for sensitive evidence.

The change record should include the normalized proposal hash, approver identity and decision, approval time and expiry, execution identity, runbook version, exact targets and parameters, command results, before-and-after state, validation results, and rollback status.

Keep audit administration outside the execution identity. The process that applies a change should not be able to erase the evidence that it ran.

In Practice

The documented control patterns already exist; the LLM does not require a new theory of production authorization.

NIST AI 600-1 states that generative AI can require additional human review, tracking, documentation, and management oversight, and lists auditing, change-management controls, and data provenance among governance mechanisms. Applied here, model output remains attributable decision support until an authorized system accepts it as a change proposal.

NIST SP 800-53 Revision 5 defines separation of duties and least privilege as access-control principles. Diagnosis, approval, execution, and audit administration should therefore not collapse into one service role merely because one conversational interface coordinates the workflow.

AWS Systems Manager demonstrates the difference between an advisory instruction and an enforced gate. Its aws:approve action pauses an automation until designated principals approve or reject it. Systems Manager Change Manager can constrain approved operations, concurrency, error thresholds, and rollback behavior while retaining the request reason, requester, approver, and implementation details. The documented pattern is a versioned runbook passing through an external approval mechanism—not a model invoking a mutable command directly.

AWS CloudTrail event records can record identity, event time, event source, action, Region, source address, request parameters, and response elements. But CloudTrail documentation also notes that event types have different defaults and that events are not an ordered stack trace. Audit design must verify coverage and correlate stable request, change, and incident identifiers; “CloudTrail is enabled” is not proof that every relevant database and data-plane action is captured.

Amazon Bedrock Guardrails illustrates another boundary. Its prompt-attack filter evaluates selected input for jailbreak, prompt-injection, and prompt-leakage patterns, with tagging requirements for some inference APIs. This can be one input control. It still cannot determine whether an index build is safe on the current writer, whether an approver owns the service, or whether the rollback objective is acceptable.

Where It Breaks

Failure modeWhy the control failsRequired response
Human rubber-stamps vague proseApproval adds identity but no informed decisionRequire complete structured proposals and exact diffs
State changes after approvalValid analysis becomes unsafe at execution timeRecheck state hash, topology, load, and preconditions immediately before execution
Approval is not bound to contentParameters can change after reviewSign or hash the normalized proposal and reject mutations
Same identity diagnoses and executesOne compromise crosses every boundarySeparate roles, credentials, and network paths
Retrieved logs contain instructionsEvidence steers the model toward unauthorized toolsTreat evidence as untrusted data and keep tool authority external
Read-only diagnostics overload productionNo write occurs, but resource pressure increasesUse replicas or snapshots plus workload and query limits
Audit coverage is assumedImportant data-plane or engine actions are absentTest event coverage and reconcile model, pipeline, cloud, and database logs
Validation uses the model’s narrativeThe system confirms its own expectationEvaluate independent metrics against predeclared criteria
Rollback is generated after failureRecovery starts with another uncertain proposalPrevalidate a deterministic rollback before approval
Full prompts become permanent logsAuditability creates a sensitive-data archiveRedact, classify, encrypt, restrict, and expire records by policy

What the LLM Cannot Do

Explicit operational boundaries govern the LLM:

  • No Raw Customer Data: The LLM must not receive raw result sets, bind or literal parameter values, unrestricted query text, credentials, connection strings, or any column content that can carry PII. It receives shapes, counts, timings, and normalized identifiers only.
  • No Live Database Access: The LLM has no network path to any database, host, or cloud control plane. It reasons exclusively over a detached, sanitized incident evidence pack captured by a deterministic collector.
  • 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: LLM recommendations can be plausible yet stale, incomplete, injected, version-incompatible, or operationally unsafe—and a chat approval does not make them executable.
  • Solution: Keep the LLM credential-free, require a typed and expiring proposal, enforce policy and current-state checks, bind human approval to the proposal hash, execute through a versioned runbook with short-lived credentials, and audit reasoning separately from execution.
  • Proof: Attempt to change the target, parameter, runbook version, or state fingerprint after approval. The pipeline must reject execution, preserve the rejection, and require a new approval without relying on the model to notice.
  • Action: Implement the proposal schema and denial tests before connecting any write-capable executor. Verify missing audit coverage, expired approval, state drift, injected evidence, out-of-scope targets, absent rollback, and failed validation all stop the workflow mechanically.

The next article begins the engine-specific investigations with MySQL on EC2: separating host saturation from database waits before examining SQL, InnoDB, or Aurora behavior.

Sources