Inbox Triage: The Headers-Only Pattern
OpenClaw Academy · Part 3, Issue 23
Inbox triage is the most requested personal agent workflow and the most dangerous one to implement carelessly. The danger is not the triage itself — it is what the agent reads while triaging.
An email is data. That data may come from untrusted senders. An untrusted sender who knows your agent reads their emails can craft a message that contains instructions, not just content. The agent, trained to process instructions in text, may follow those instructions — and then take actions on your behalf.
This is not theoretical. It has been demonstrated in published research against production email agents. The defence is architectural.
The headers-only pattern
The correct inbox triage architecture loads email metadata only — subject, sender, date, and a short preview snippet. It never loads full email bodies into the agent’s context.
A full email body provides the instruction surface that makes injection possible. A subject line and sender address provides almost no injection surface — there is too little space to embed a meaningful instruction, and the agent is not processing the content as instructions in the same way.
What you lose: the ability to summarise email content. What you gain: the ability to triage email safely at scale without prompt injection risk.
For the majority of inbox triage use cases, what you actually need from triage is not content summary — it is prioritisation. Which emails need action today? Which can wait? Which are noise? These questions are answerable from subject lines and sender addresses alone.
The three categories
A production inbox triage skill categorises each email as one of three things:
Urgent — a direct question addressed to you, a deadline, your name mentioned, or a reply explicitly requested. These surface to the top of the briefing.
Review — a newsletter, a report, a document to read, something that might be valuable but requires no immediate action. These are counted and dismissed unless you ask to see them.
Noise — promotional email, automated notifications, anything without a human sender behind it. These are counted and discarded.
Three categories. No summaries. No content loading. Categorisation from metadata alone.
When you genuinely need content
Some workflows require reading email content — a contract in an attachment, a code review comment, a technical question where the details matter.
For these: a separate, explicitly scoped skill that reads one specific email at a time, on explicit user request, with allowed-tools restricted to read-only email tools and nothing else. Not bundled into the triage skill. A dedicated, limited capability with a clear scope.
The rule: triage from headers. Read content only on explicit request. Never combine both in one skill.
Three things to carry forward:
1. Full email bodies are a prompt injection surface. Never load them in a triage skill.
2. Triage only needs metadata — subject, sender, date — to answer the real question: what needs action?
3. When you need content: a separate, scoped, single-email reader on explicit user request only.
Issue 24 drops Thursday — the complete personal operations agent: all 9 skills assembled, one openclaw.json config, step-by-step integration guide from every vault asset in Part 3.