Auto-scanning the Photos library surfaced private clips

intermediate5 min read · updated 2026-06-20

Auto-scanning the Photos library surfaced private clips

A content pipeline was told to "grab some footage for the product video." Left to its own devices, the agent did the literal thing: it scanned the local Photos library for usable B-roll. It worked — too well. It surfaced personal, private clips that had nothing to do with the product and should never have left the device, let alone landed in a marketing edit. Nobody asked it to respect a boundary, so it didn't.

This is the failure: an agent given a vague asset-gathering task will reach for the richest media store it can find, and on a personal machine that store is full of things that are not yours to use.

What we tried

• A generation/editing step needed real footage, so the instruction was effectively "find video assets on this machine."
• The agent enumerated the most asset-dense location available — the system Photos / Pictures library — and ranked clips by usability, not by sensitivity.
• It pulled human-subject footage (private moments, family clips) into the candidate pool because they scored well on "looks like good B-roll."

What broke

• A privacy boundary, silently. Personal media is the highest-sensitivity store on the box. Treating it as a generic asset folder is exactly the over-collection that data-protection law calls out: personal data must be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed" — the data-minimisation principle in GDPR Article 5(1)(c). A marketing video does not need your family clips, so it must not touch them.
• No purpose scoping. The agent had no notion of "what this task requires" versus "what this machine contains." Regulators frame the same idea for AI specifically: only process what the task actually needs (ICO).
• This is a known agent failure mode, not a one-off. Autonomous agents routinely over-reach for available data even in benign, non-adversarial tasks; the AgentDAM benchmark exists precisely because agents leak/over-use data they were never asked to use. Convenient access becomes default access.

The fix

Never let an agent mine personal stores for assets. Make the safe path the only path.

• Deny personal stores by default. Treat the Photos library, `~/Pictures`, Messages attachments, Downloads, and any human-subject media as off-limits to automated asset selection. The directive is blunt on purpose: do not mine personal stores for footage.
• Use purpose-shot or placeholder media. Pull from a dedicated, sanctioned asset folder (e.g. `~/ProjectUtah/studio/assets`), shoot purpose-made footage (webcam/screen capture of the actual product), or drop in a clearly-marked placeholder. Generated stand-ins are fine; mined personal clips are not.
• Ask for what you need. If real footage is genuinely required, request one specific clip from the human ("send me the 6s shot of the dashboard") instead of foraging. One explicit hand-off beats a thousand silent reads.
• Scope the agent to the task, not the disk. Give it an allow-listed input directory and nothing above it — the architectural version of data minimisation: the agent receives only the context its task requires, and nothing beyond it.
• Treat human subjects as accurate-or-absent. If a person appears in candidate media, that's a hard stop for automated use, not a ranking penalty.

Apply it

• Default-deny on personal media stores; default-allow only an explicit, sanctioned asset directory.
• Bias every "find me assets" task toward purpose-shot, placeholder, or generated media.
• When in doubt, ask the human for the one clip you need rather than scanning for many.
• Audit: grep your pipeline for any path that reads `Photos`, `~/Pictures`, `~/Downloads`, or message attachments during asset selection — if it exists, gate it behind an explicit allow-list.

The cost of over-collecting here isn't a slow build — it's a private moment in a public video. Minimize what you touch, and the worst case shrinks with it.