Unit 12.00: What your logs are actually collecting

Look at what a normal log line actually contains before deciding what to do about it.

The prompt field is the problem

A realistic log line with its fields classified.

The code identifies the sensitive ones.

log_line = {
    "request_id": "r-8841",
    "user_id": "user-a",
    "prompt": "POLICY: ...\n\nQ: my account ACC-1187 was charged twice, "
              "card ending 1111",
    "response": "I can see two charges...",
    "model": "some-model-2026-06",
    "latency_ms": 780,
}
sensitive = [k for k in log_line
             if k in {"prompt", "response", "user_id"}]
print("fields in a typical log line:", sorted(log_line))
print(f"fields carrying personal data: {sensitive}")

print("""
The prompt field contains whatever the user typed AND whatever you retrieved
and put in front of it. That makes the log store a second copy of both -- in a
system built for debugging, usually with broader access than the primary one.
""")

The prompt field contains whatever the user typed *and* whatever you retrieved and put in front of it. That makes the log store a second copy of both - in a system built for debugging, usually with broader access than the primary one.

The user id is the field that links everything else to a person, which is what turns a collection of strings into personal data.

The mistake this prevents

The mistake is auditing the database and not the logs. The database has an owner, a schema and an access policy; the log store was set up quickly, is readable by everyone on the team, and contains the same content.

Takeaway

Log lines contain user input and retrieved documents, and the user id links them to a person. Audit the log store with the same care as the database.

Mark complete