Draft first: a safer way to let AI act on your behalf

By the Cresec team · Published 22 September 2026 · Updated 17 October 2026

Most of the value of an AI helper comes from the work it does before anything is sent: reading, sorting, summarising, writing a first version. The risky part is the last click — sending the email, updating the record, posting the message.

A “draft first” approach keeps the value and holds back the risk.

How draft first works

1. Start with preparation. Preparing text inside a tool differs from creating a draft in a mailbox: the latter is an upstream write requiring appropriate scopes and permission. Decide the exact allowed actions.
2. People check the drafts. The person reviews what the tool wrote and sends it themselves. They learn quickly where the tool is good and where it needs help.
3. Sending is granted, not assumed. Once someone trusts the tool for a task, a manager or admin allows sending — for that person, for that tool.
4. It can be taken back. If something goes wrong, sending is switched off for that person without affecting anyone else.

Why it helps everyone

For the person using the tool, a review step provides a chance to correct the output before sending. Granting a tool permission is not the same as reviewing every message.

For the person who built it, a preparation-only scope can make the first evaluation smaller. Identity, data access and consent may still require approval.

For IT and security, explicit action limits make the proposed permission and its review easier to assess.

Drafts and prompt injection

Drafts matter most when a tool reads text strangers write. A hidden instruction in a ticket can fool the model into writing the wrong words, and the person who reads the draft is the last check on those words. Drafts can’t stop an injected instruction from choosing a different action or recipient; only a design where code decides those can. See how the attack works.

Use an existing approval step when it fits

n8n’s human-in-the-loop guide describes approval before selected AI tool calls. A 2021 engineering article from n8n on Medium also describes retaining a human release gate inside automation. That historical example illustrates the handoff, not a current installation recipe. Decide whether your platform already provides the review you need.

What if the service is down?

Cresec refuses all live governed calls, including reads, when its gateway or control plane cannot be reached. A user interface may display previously authorized cached data only under an explicit isolation, expiry and invalidation policy, visibly marked stale. That is not live read access.

Cresec’s gateway requires a fresh control-plane decision for each governed call. When the control plane cannot be reached, every governed call, reads included, is refused with an explicit, retryable error; nothing falls back to a stored credential or a cached decision. Deployment review covers error reporting, expiry and revocation of cached display data, and recovery. Resolve a timed-out write’s outcome before retrying it. See the FAQ.