Your AI Exported a CSV. Did It Turn Customer Text Into Formulas?

Your agent collects customer feedback, summarizes the themes, and exports a spreadsheet for Monday’s meeting. Every row arrives. The headings look right. Nobody notices that a customer-supplied field is being interpreted as a formula instead of text.

This is a different problem from an AI hallucination. The model can accurately copy the original message and still deliver a file that behaves differently when someone opens it.

Treat customer text as data all the way into the spreadsheet, not just while it passes through the model. A successful CSV export proves that you wrote a file. It does not prove that the receiving application will display every field literally.

The interpretation happens after the export

A CSV is a text format for rows and fields. It does not provide a universal instruction that tells every spreadsheet application which cells must remain text.

Suppose a customer submits the harmless test value =1+1 in a feedback form. Your automation copies it into a notes column. When opened through a spreadsheet import path that recognizes formulas, that value may display as 2 rather than the original characters.

That tiny example demonstrates the boundary: external text became an instruction to another program. More consequential formulas can exist, although their behavior depends on the application, configuration, and user interaction. You do not need a dangerous payload to test whether the boundary is broken.

OWASP describes this class of issue as CSV injection. It applies to ordinary exports as well as AI-assisted workflows. Adding a model does not create the spreadsheet behavior; it adds another place where untrusted text can be copied or reformatted.

CSV quoting is not a text-type guarantee

A proper CSV writer handles commas, quotation marks, and embedded line breaks. Those rules keep a customer message from accidentally spilling into neighboring fields.

They do not, by themselves, tell a spreadsheet to ignore formulas. A quoted CSV field can still be interpreted after the spreadsheet parses the surrounding CSV syntax.

This distinction matters because two separate checks are needed:

Structural correctness: does the export preserve the intended rows and columns?
Literal-text handling: do untrusted text fields remain text in the receiving application?

Passing the first check says nothing conclusive about the second. Likewise, viewing the file in a plain-text editor cannot establish how it behaves when opened in a spreadsheet.

If you already protect customer identifiers during CSV imports, think of this as the outbound companion: preserve meaning when data crosses the next application boundary.

Define the columns before choosing a mitigation

Start with a small export contract. For an illustrative customer-feedback report, it might say:

customer_id is an exact text identifier.
feedback is untrusted literal text, even when it resembles a formula.
category is a validated label from an approved set.
ticket_count is a validated nonnegative integer.
No externally supplied field is allowed to create a spreadsheet formula.

Do not blindly modify every value beginning with a minus sign. A negative amount in a numeric report may be legitimate. The same characters in a customer comment belong to a text field. Column meaning determines the treatment.

The contract should also cover model-generated summaries. A summary is not automatically safe because an assistant wrote it. It can quote customer content, preserve formula-like prefixes, or produce unexpected formatting.

Prefer explicitly typed spreadsheet output

For a report intended for people to open in a spreadsheet, consider a workbook format that supports explicit cell types. Use a library’s literal-string writing method for untrusted fields, and check whether its convenience methods automatically recognize formulas or hyperlinks.

The file extension alone is not a protection. A workbook generator can still write a formula cell if you call the wrong method. The important property is how each field is encoded and how the destination reads it.

Keep trusted calculations separate from imported text. If the report needs totals, generate those formulas from fixed application logic referencing validated numeric cells. Do not construct executable formulas by inserting arbitrary customer messages.

If CSV is mandatory, define a destination-specific export and import procedure. Text-prefix techniques, such as adding an apostrophe, can change the underlying value or behave differently across applications. Do not present one character substitution as a universal fix.

Where you cannot validate safe literal handling, withhold the spreadsheet-ready export and provide a clearly labeled alternative for review. An undocumented assumption is not an export policy.

Keep the raw record separate

Changing text for a display export should not silently rewrite the source record.

Preserve the original customer message in the authoritative system, under its existing access and retention rules. Create any spreadsheet-oriented representation at the export boundary. Record which transformation policy produced it.

This separation prevents a mitigation from becoming a data-quality bug. A prefixed display value should not later overwrite a customer name, alter an identifier, or become the source for a CRM synchronization.

If another system needs machine-readable data, give it a separately documented format and schema. A human-facing spreadsheet and an exact interchange file serve different purposes; forcing one artifact to satisfy both can create surprising conversions.

Test the file the recipient actually opens

Build a small synthetic fixture containing ordinary text, commas, quotation marks, embedded newlines, and harmless formula-like values. Include =1+1 and representative leading characters such as +, -, and @ in text fields. Add leading whitespace and control-character cases relevant to the importer.

Run that fixture through the complete workflow, including the model if it transforms the fields. Then open the result using the actual supported application and import procedure.

Check that:

Every expected row and column survives.
Text fields display their intended literal contents.
Untrusted fields are not stored as formula cells.
Legitimate numeric columns still behave as documented.
Saving and reopening the supported output does not undo the protection.

Inspect cell types or formula indicators rather than relying only on visible values. A cell showing 2 could be a number, text, or an evaluated formula. Appearance is not enough.

Make the export receipt specific

Replace “report generated” with a useful completion record: output format, intended application, policy version, row count, and whether the literal-text checks passed. Do not claim compatibility with spreadsheet tools you have not tested.

The first useful improvement is small. Pick one recurring customer-data export, declare its text columns, and test a harmless formula-shaped value through the recipient’s real opening process.

Your agent’s job is not finished when the file exists. It is finished when the recipient can use that file without customer text unexpectedly becoming spreadsheet logic.