# The minimum useful prompt: remove fields before you redact them

> Reduce an AI request to the fields required for its task, then redact supported sensitive values in those fields. A detector cannot leak a field your application never includes.

Published 2026-11-04T09:00:00+01:00, updated 2026-11-04T09:00:00+01:00 by Godfrey Lebo.

## TL;DR

- Build model inputs from explicit fields rather than entire database records.
- Select detector coverage for the useful text that remains.
- Test task quality and disclosure in the exact outgoing request separately.

A support database can contain twenty columns even when the model needs three. Sending the entire record and hoping a redactor catches everything makes the detector responsible for a decision the application could have made earlier.

Consider a fictional request: explain why a parcel is delayed. The useful inputs might be the promised delivery window, the latest tracking event and the approved escalation policy. A billing address, internal customer identifier and payment reference do not automatically help explain the delay. Start by asking what would change in the answer if each field disappeared.

## Build the request from an allowlist

Construct a fresh object from explicitly selected fields. Do not spread a database row into a prompt and then delete the fields someone remembered were sensitive. An allowlist makes additions to the source schema inert until a person decides they belong in the model request.

For the delivery example, the projection might contain a status such as `awaiting depot scan`, a date range and a policy excerpt. The example is an application design, not a Sether API. Your service owns this projection. Sether operates on the text you actually pass to it.

Treat attachments, tool results and conversation history as separate inputs. A careful initial prompt accomplishes little if a retrieval tool later appends a full customer record. Make the same field decision wherever external information enters the model context.

## Redact the remaining text

Useful text can still contain an email address in a customer message. The documented TypeScript synchronous API accepts a detector list and a vault:

```ts
import { basicDetectors, MemoryVault, redactSync } from '@raeven-co/sether';

const vault = new MemoryVault();
const redacted = redactSync(
  'Send the delivery update to alice@example.com',
  { detectors: basicDetectors, vault },
);
```

This replaces values matched by the selected detectors. It does not determine which business fields your task needs. The basic pack includes structured patterns such as email addresses and international-format phone numbers. Labelled identity fields and secrets require their corresponding detector packs; free-text names need additional recognition. Review the [Sether detector documentation](https://github.com/raeven-co/sether#choose-specific-detectors) before choosing coverage.

Keep the vault in the application boundary that is allowed to restore those values. If the model only drafts an explanation, it may never need to see the customer address at all. The authorised application can add a recipient after a person approves the draft.

## Check usefulness and disclosure separately

Test two properties with fictional records. First, does the projected request still let the model complete the task? Second, what sensitive content remains in the exact outgoing request? A successful answer does not prove privacy, and a request containing only placeholders does not prove the task still works.

Include counterexamples. A unique account nickname, an unusually specific incident description or a combination of dates can identify someone without matching a basic email or phone detector. A prompt containing fewer fields can still carry meaningful personal information. The [OWASP sensitive information disclosure guidance](https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/) is a useful starting point for treating disclosure as an application risk.

## Give every field an owner

Record why a field is sent, who approved it and which regression example proves its necessity. Keep this close to the request builder. When the product changes from drafting an update to authorising a refund, reconsider the projection; the new task may need different information and a separate permission check.

This is a small maintenance habit with a practical payoff. A new database column should not silently become a new model input. A new integration should not inherit every detail from the system it connects to. The [Sether README](https://github.com/raeven-co/sether#honest-limitations) documents detection limits; a deliberate request boundary reduces how much depends on those limits in the first place.

## Frequently asked questions

### Does field selection replace redaction?

No. It limits the fields sent, while selected detectors can replace supported sensitive values that remain in useful text.

### Does a shorter prompt prove anonymity?

No. Rare events and combinations of details can still identify a person, even after direct identifiers are removed.


Canonical: https://sether.ai/blog/minimum-useful-prompt