Valid CSV is not the same as passive content

An agent exports customer feedback to a spreadsheet for a colleague. The rows parse correctly, counts reconcile and the file opens. None of those checks establishes whether text supplied by a customer has become a spreadsheet formula.

This is an output-boundary problem. It can arise even when the agent follows its instructions and never treats the original feedback as a prompt. The spreadsheet application, or the workbook-writing library, may interpret the exported value differently from the reporting code.

Methodology and intended audience

This documentation-based guide was checked on September 22, 2026. It uses OWASP's CSV Injection page and the official XlsxWriter worksheet and workbook references. We selected them to connect the risk at the receiving application with concrete controls in one writer.

The workflow is intended for teams exporting untrusted descriptions, tickets, survey responses or repository metadata through an agent. It is not a security certification or a claim that XLSX is inherently safe. We did not execute an injection payload or test a specific recipient's spreadsheet software.

Our earlier CSV reconciliation guide addresses ingestion and reporting correctness. This article addresses the different question of what the recipient's software will do with the delivered cells.

Identify the interpretation boundary

OWASP's CSV Injection guidance explains how spreadsheet applications can interpret untrusted exported values as formulas. It warns that separators and quoting matter, that save-and-reopen behavior can undermine common mitigations, and that no single CSV sanitization strategy suits every application and downstream consumer.

Our practical recommendation is to classify columns before export. Customer comments and repository descriptions are literal text. Verified quantities are numeric values. Calculations authored by the reporting workflow belong in a separate, explicitly approved formula category.

Do not let a field cross categories merely because its first character resembles a formula. At the same time, do not strip punctuation indiscriminately: a legitimate negative quantity, identifier or international phone number may have a business meaning that an indiscriminate cleanup would destroy.

The decision belongs in an export contract agreed with the data owner, not in an agent's last-minute attempt to silence spreadsheet warnings.

Choose the artifact for its consumer

For an authorized machine-to-machine transfer, propose a data format and schema that preserve literal source values. Keep that artifact separate from a human-facing workbook. A raw export should be clearly identified as data, not advertised as safe to open in arbitrary spreadsheet applications.

For colleagues who need filtering and review in a spreadsheet, consider generating a typed workbook with deliberate literal-text cells. For recipients who only need a static summary, a reviewed non-editable report may avoid the need to distribute raw rows at all.

These are design choices, not universal security guarantees. Confirm the actual receiving application, whether the recipient will edit the file, and whether someone will later convert it back to CSV. Every conversion creates another interpretation boundary to review.

Make the writer's behavior explicit

The XlsxWriter worksheet reference explains that the generic write method dispatches values to more specific methods. By default, strings beginning with an equals sign can be written as formulas. The explicit write_string method is available for literal text.

The workbook reference documents options to disable automatic string-to-formula and string-to-URL conversion. Treat these as controls for the documented conversion behavior, not a blanket safety mode for every possible workbook operation.

Our proposed implementation uses explicit text-writing calls for untrusted textual columns. It also disables automatic conversions where generic writing is unavoidable. Approved calculations use a separate path that never derives executable formula syntax directly from user-supplied content.

Do not rely on applying a text-looking visual format after writing a formula. The review should examine the stored cell type and the writer operation, not just the way the cell appears on screen. Check return values and length constraints too; silently truncating a comment is a different data-quality failure.

Use harmless fixtures to review the handoff

Build a small synthetic fixture before processing customer data. Include ordinary text, a leading-zero identifier, a comma and quotation mark inside a field, a line break, an international phone number and the harmless formula-shaped string =1+1.

For the textual column, the expected outcome is the literal sequence =1+1, not the calculated number 2. For an explicitly approved calculation column, use a separate known formula and document its intended result. This distinction prevents a test that merely disables every legitimate calculation.

Inspect the generated workbook's cell types with an appropriate reader, then check it in the intended recipient application. If saving, reopening or exporting is part of the real workflow, include those steps in the acceptance exercise. Record the application and version used.

Use no network-calling formulas, command-launching payloads or sensitive production data in this exercise. These are proposed checks; this article does not report executed results.

Preserve evidence without exposing raw records

Ask the agent for a compact export note: artifact purpose, column categories, writer configuration, handling of formula-shaped text, rejected values and checks performed. Keep sensitive samples out of ordinary logs and public issue trackers.

If the receiving workflow is unknown, state that limitation and withhold an unsupported claim of safety. Do not turn off warnings on a colleague's computer to make the file appear trustworthy. A warning-free preview is not a substitute for inspecting the export path.

Limitations and choosing a reporting skill

Typed cells address one interpretation risk; they do not establish privacy, correct calculations or the safety of unrelated workbook features. CSV round trips may discard type information. Other libraries have different defaults, so the XlsxWriter settings here must not be copied as assumptions about another writer.

When evaluating a candidate in the OpenAgentSkill directory, ask how it separates untrusted text from authored calculations. Prefer a workflow that can explain the receiving application and show its cell-type decisions. A polished spreadsheet should arrive with a clear data boundary, not an implicit invitation to trust whatever the file executes.