Convenience, not necessity, drives over-sharing

Most over-sharing is not a design decision; it is what happens when a developer already has a full object in hand (a customer row, a support ticket, a claim) and passes it to a prompt because extracting the three fields the step actually uses takes extra code.

That shortcut is invisible until someone asks what the model saw. A classification step that only needs a subject line and a category list does not need the customer's address, billing history, or free-text notes from an unrelated department.

  • List the fields a step reads versus the fields present in the source object.
  • Treat any gap between those two lists as unreviewed exposure.

Scope the input schema the same way you scope the output schema

Production workflows increasingly validate model outputs against a schema before writing them back. The same discipline should apply going in: define the smallest input shape a step needs, build that object explicitly, and send that object instead of the source record.

This also makes a step provider-agnostic and easier to test. A function that accepts {subject, category_options} is simpler to mock, replay, and move to a different model than one that accepts an entire upstream payload.

Minimization is a control, not a compliance checkbox

Regulatory language around data minimization exists because broader exposure increases the blast radius of any failure: a logging bug, a provider breach, a misconfigured retention setting, or a prompt that gets echoed back in an error message.

OWASP's guidance on sensitive information disclosure in LLM applications treats this as a first-class risk category, not an edge case, precisely because input scope is one of the few controls a team fully owns regardless of which model sits behind the API.

Where this breaks down in practice

Minimization fails quietly when a step's requirements grow over time and nobody revisits the input builder. A summarization step that started with just a ticket body can end up receiving customer PII months later because someone added a field for an unrelated reason and reused the same payload.

Treat the input schema as something to review on the same cadence as the output schema: whenever the workflow changes, confirm the step still only receives what the current logic reads, not what the last version happened to need.