Evidence Fields to Log for Every Agent-Issued SQL Query on a Data MCP Server

Why database logs alone do not satisfy an examiner

A database can record query history. A MySQL general query log, for example, holds statement text. That is useful, but when an agent sends the query through a Data MCP server, the database sees a service account. It does not see which agent acted, for which person, under which tool call, or what a policy did with the request and the result.

An examiner asks five questions: who or what made the request, which policy applied, what the query touched, what came back, and what the enforcement decision was. Statement text and a service account answer only the third, and only in part. The remaining questions have to be answered from records created outside the database.

The OWASP MCP Top 10 names the same weakness. Under MCP08, Lack of Audit and Telemetry, it notes that limited telemetry from MCP servers and agents impedes investigation and incident response, and it recommends detailed logs of tool invocations, context changes and user-agent interactions with immutable audit trails. NIST workshop material on AI incident management (NIST IR 8621) goes further and lists tool calls, authorization decisions, identities and API keys used, and data stores accessed as minimum investigation evidence. Those are workshop recommendations, not binding requirements, but they give examiners a reasonable reference point.

Where each field is captured in the tool-call path

Most of these fields do not exist in the database. They exist at the MCP tool-call boundary, where the server receives the request, evaluates it, runs the query and returns a result. Capturing evidence at that point is a design choice, but it follows from where the decision is made. A record assembled later from separate systems depends on matching timestamps and guesswork.

A shared correlation identifier ties the pieces together. It should be generated or accepted when the tool call arrives, written into the evidence record, and passed to the database session where the platform allows, for example as a session tag or query comment. An examiner can then move from the evidence record to the database log and see that both describe the same event. The identifier format matters less than its being present in both places.

The exact query text should be recorded as issued. An agent may build SQL from untrusted input, so the user's request is not a substitute for the statement. The schema should also make no assumption about why a harmful query was produced. SQL injection is a conventional application weakness and not automatically a prompt-injection outcome, so the record should show what ran, not a guessed cause.

The minimum evidence schema, by category

Each category below states the fields to record, what they prove, and what is lost without them. The set follows the discipline in NIST SP 800-53r5: define the event types logged, document why they support after-the-fact investigation, and review the list periodically.

• 1. Requester and agent identity: Fields: end requester identity, agent identifier and version, model provider, identifier of the credential or API key used (never the secret), and the database service account. Proves who and what acted, and on whose behalf. Without it, every query collapses to one service account and cannot be attributed.
• 2. Tool call and query content: Fields: correlation identifier, tool name, timestamp, exact SQL as issued, query parameters, and data stores or tables targeted. Parameters matter most on datasets with personal information, where SP 800-53r5 treats auditing query parameters as a way to track access, usage and sharing. Without them, scope of access cannot be shown.
• 3. Policy and enforcement decision: Fields: decision (allow, redact, block or escalate), policy identifier and version, rule matched, reason and decision time. Proves that a control operated, and which one. Without it, the record shows a query happened but not whether anything was allowed to stop it.
• 4. Data returned or redacted: Fields: row count, columns returned, columns or values redacted, redaction action taken, and result size. Record the fact and extent of redaction, not the redacted values. Without it, an examiner cannot tell what the agent actually received.
• 5. Human approval: Fields: approval requested time, approver identity, outcome, and the correlation identifier of the tool call approved. Proves that escalation reached a person and that the person's decision governed that specific query. Without the link, approvals are a separate ledger that cannot be tied to events.
• 6. Integrity and retention: Fields: record sequence or hash value, write-once storage reference, synchronized timestamp, schema version, retention class and storage location. Proves the record is complete, unaltered and held as policy requires. Without it, the other five categories carry little weight.

Integrity, retention and sensitive data inside the logs

Evidence is only useful if it can be trusted. Prefer append-only or immutable storage, as OWASP recommends for MCP audit trails. A common way to make tampering detectable is to chain records so that each one includes a hash of the previous record, with periodic checkpoints held separately. Synchronized clocks across the MCP server, the policy component and the database allow records to be placed in order. Where clocks drift, sequence numbers in the record preserve ordering.

Retention and storage location should be set deliberately and recorded in the schema, so an examiner can see how long each record is kept and where it resides. The retention period itself is a decision for the enterprise and its regulators.

There is a real tension in the data-returned category. OWASP advises redacting sensitive data before it enters logs, yet an examiner needs proof of what was redacted. The workable answer is to log metadata about the redaction (which columns, how many values, which rule) and not the underlying values. Where raw values must be retained for investigation, store them separately under stricter access control and reference them from the evidence record.

Where logs come from a component the enterprise did not build, expect the examiner to weigh the provenance of that evidence. Record which component produced each field.

Evidence as a by-product of enforcement in the execution path

Fields such as policy decision, redaction and approval cannot be reconstructed reliably after the fact, because they describe actions that happened at runtime. The dependable approach is to enforce policy where the tool call is evaluated and to write the evidence record from the same step, so the decision and its record cannot diverge.

Trussed works this way. It enforces policy in the execution path on individual tool calls to MCP servers (allow, redact, block, rate limit or escalate for human approval) and generates audit-ready evidence from that enforcement, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It can be self-managed in the customer cloud, with configurable retention and data residency. Its scope is the individual interaction and tool call, not end-to-end tracing of agentic workflows.

Scope should be assessed per use case. The EU AI Act sets logging requirements for high-risk AI systems, and whether an agent on a Data MCP server falls within that definition depends on how it is used. As of November 2026, the consolidated text has been amended since its original publication, so confirm current obligations before mapping fields to them.