Heidelberg AI Curriculum

T12-L03 · Security, privacy & governance · Level 3 Builder · 16-minute read, plus 3 hours of doing

The list was empty, and the builder was in Boston

A postdoc built a workflow that reads a PubMed search every weekday at six, asks a model to sort new papers into read, skim and skip, and puts a shortlist in a shared table. The group picks its journal-club paper from it. It worked for two months. Then a colleague widened the search while the postdoc was at a conference. The feed doubled, the table filled with half-sorted rows, and on Thursday the shortlist was empty with no explanation. Nobody knew whether it had run, failed or found nothing. The only person who could switch it off was in Boston.

In a company it's a sales assistant at a lab-equipment distributor. Her workflow reads the shared quotes inbox every fifteen minutes and sorts requests into categories for the sales team. One Monday an auto-reply loop fills the inbox with nine hundred messages. The workflow sorts every one, the model bill for the day is higher than the month before, and the credential it uses, the saved login that connects n8n to the mailbox, could have sent mail from that inbox all along.

Both workflows were good. What they lacked was a rule the build actually obeyed, and a stop that someone other than the builder could use. You are at Level 3 Builder: colleagues depend on what you built, and when it misbehaves at night, they're the ones who find out.

After this you can

Write a one-page operating rule that says what an unattended workflow may read, write and never do, and who uses the result.
Cut the workflow's access in the credential itself, so a forbidden action fails even if the model asks for it.
Set hard limits on items per run, run time and model spend, and check that each one stops the run.
Run five tests with harmless test items, including a test set with known answers, before the workflow runs on its own.
Hand the rule and the stop to a named deputy, and watch them switch the workflow off without your help.

Before you start

Books: T05-L02 for the workflow itself: a model step that returns fixed fields and a check step behind it. T12-L02 for what may go into the model at all, and for text that tries to give orders.
n8n, where the workflow already runs: n8n Cloud, or the instance your organisation runs. This book uses n8n because the T05 books do, and because it separates publish from edit, which makes the stop easy to find. Make is the alternative if your team already uses it; it has the same pieces under different names.
The model's API account, the pay-per-use account a workflow uses to reach the model, in the Claude Console if you use Claude as in T05-L02. You'll set a spend limit there.
A colleague who will be your deputy. Someone who uses the result, not another builder.
About 3 hours 20 minutes: 16 minutes to read, about 3 hours to do, over two sessions.

Last verified 23 September 2026. n8n Cloud Starter costs €20 a month billed yearly, for 2,500 runs a month; Pro costs €50 for 10,000. Claude Haiku 4.5 costs US$1 per million tokens (word-pieces) read and US$5 per million written. Details for experts at the end of this book.

The idea in one page

A workflow that runs on a schedule does the same thing many times without anyone watching. So the question before it runs unattended is:

What is the worst this workflow can do before a person notices?

Answer it in things you can count: rows written, mails sent, money spent, data exposed, hours until someone looks. Then make that number smaller before you add any monitoring. Watching tells you about damage. Narrow access limits it.

Put every action in one of three lanes.

Lane	What it means	Examples	How the build enforces it
Automatic	Reversible, and checked before anyone relies on it	Read a public feed; write a row to a review table	Allowed, inside the limits, with a status line
Review first	The workflow prepares it; a person decides	A suggested category; a draft reply	Goes to a table a named colleague works through
Never unattended	Leaves the team, can't be undone, or costs real money	Send, delete, publish, pay, change a customer record	The credential can't do it. If the credential can, it isn't connected.

The rule lives in the build, not in the prompt. "Never send email" in a prompt is advice. A credential without send permission is a rule. For each line of your operating rule, write where the build enforces it: a credential scope (one permission the saved login was granted), a guard node (a step that stops the run when something is off), a workflow setting, a spend limit. A line with no enforcement point is a wish, and the workflow stays supervised until it has one.

Limits have to hold across runs. Twenty items per run sounds small. A trigger every fifteen minutes makes it 1,920 a day. So you need three kinds of limit: one per run (a guard that stops an oversized batch before anything is processed), one on time (the run is cancelled if it takes too long), and one that counts across all runs (a spend limit on the model account, which stops every run once the month's money is used).

A stop has two halves. Unpublish stops new runs. It doesn't stop a run already in progress. The timeout setting cuts that one off. Your deputy needs to know both, and needs the access to use them.

Say what state the result is in. An empty shortlist can mean "no new papers" or "the workflow died at 06:01". Every run writes one status line the reader can see: complete, partial or stopped, with counts. No status line for today means it didn't run.

Where Level 3 stops. You can do all of this with a credential you connect yourself, on n8n Cloud or your organisation's n8n. Once the workflow needs a service account from IT, a login that belongs to a system rather than a person, a mailbox or system IT administers, or its own server, it's Level 4: that's T12-L04 and your IT department, not another guard node.

Worked example: two workflows, four quadrants

Both situations use the four-quadrant method from T01-L01. Each starts with a workflow that already works and makes it safe to leave alone.

Lab: the morning literature shortlist

Structure it. Jana, the postdoc: "Every weekday at 06:00 the workflow reads our PubMed search and sorts new papers into read, skim and skip. The group uses the shortlist to pick the Thursday journal-club paper. It has to run while I'm away, and anyone in the group must be able to tell whether today's list is complete, and stop it if it goes wrong."

Understand it. She opens the workflow and follows it node by node: Schedule Trigger, RSS Read with the PubMed feed link, the model step asking Claude Haiku 4.5 for a label and a one-line reason, a check step, and a Data Table node that inserts rows into Morning shortlist. Then she asks the worst-case question. The model can't send anything and the feed is public, so the damage is limited to money and the table. The money is small: at 25 papers a day with a title and abstract each, the month costs less than a coffee. Even a feed of 200 would stay cheap.

The real worst case is the one from the conference week. The PubMed link has a limit= value that anyone who edits the search can raise, up to 200. A long batch fills the table with rows nobody can review. And when the run failed, the table looked the same as on a day with no new papers. Nobody could tell the difference.

That changes what she is building. Back to Structure it: "The shortlist must say whether today's run is complete, partial or stopped. A batch larger than we can read stops before the model sees it. Two people can stop it."

Choose tools. Everything stays in n8n, because the workflow already lives there and the group can read it. A Code node, a step that runs a few lines of code, as a guard before the model. The Timeout Workflow setting at ten minutes, since a normal run takes under two. A separate error workflow, a second workflow n8n starts whenever this one fails, that posts to the group's Teams channel. A separate workspace in the Claude Console for this workflow, with its own monthly spend limit of US$10, about ten times the normal month. No new tools: each of these is a setting or a node, and the next maintainer can see all of them.

Build it. The guard sits between RSS Read and the model step. If the batch holds more than 25 items, it stops the run before anything reaches the model:

// Guard: stop before the model if the batch is larger than we can review.
const MAX_ITEMS = 25;
const items = $input.all();
if (items.length > MAX_ITEMS) {
  throw new Error(
    `Batch of ${items.length} items is over the limit of ${MAX_ITEMS}. ` +
    `Nothing was sent to the model. Check the PubMed search, then rerun.`
  );
}
return items;

A thrown error fails the run and triggers the error workflow, so the group's channel gets a message with a link to the failed execution. After the Data Table insert, a last node writes one row to a Run status table: date, papers read from the feed, rows written, rows sent to the review queue, and complete. If the run stops, the error workflow writes stopped with the error message instead. The shortlist view shows today's status row on top.

Then she writes the operating rule, one page, stored in the group's shared folder next to the workflow link:

OPERATING RULE: Morning literature shortlist        rule v2, 23 Sep
Workflow: "Lit shortlist" in n8n, published version of 23 Sep

Who uses it:  the group, to pick the Thursday journal-club paper
Maintainer:   Jana       Deputy: Tobias (can unpublish; editor)
Runs:         weekdays 06:00

May read:     the PubMed RSS feed for our saved search (public)
May write:    rows in "Morning shortlist" and "Run status"
Never:        email, other tables, full texts, anything not public
  enforced:   no credential for anything else exists in this workflow

Limits        value        enforced by
Items/run     25           Guard node, stops before the model
Run time      10 min       Workflow settings > Timeout Workflow
Model spend   US$10/month  Claude Console, workspace "lit-shortlist"

Status:       every run writes complete / partial / stopped to "Run status".
              No row for today = it didn't run. Use PubMed directly.
To stop:      open the workflow > dropdown next to Publish > Unpublish.
              Then check Executions for anything still Running.
To restart:   maintainer only, after checking the last run's rows.
Last tests:   23 Sep, all five passed (test sheet linked)
Review:       when the search, model, prompt or limits change

Each line of the Limits block names where the build enforces it. When she writes "Never: email", she checks the credential list for the workflow: only the Anthropic credential is in it. There is nothing that could send.

The known-answers test comes before anything else. She takes 20 papers from last month that she and Tobias have already sorted by hand and saves them as a small test feed. The workflow's labels must match on at least 18. It gets 17. Two of the three misses are the same kind: methods papers that use their technique on a different organism, which the model rates skip. She adds one sentence to the prompt about methods papers and reruns: 19 of 20, and the last miss is a paper she and Tobias disagreed about too. The test feed and the expected labels go into the workflow's folder, so the next person who changes the prompt reruns the same 20.

The stop drill comes last. Tobias gets the rule, nothing else. Jana starts a manual run on a test feed of 24 slow items and says "stop it". He finds the workflow, unpublishes it, and opens Executions. The manual run is still going, and he doesn't know what to do with it. That goes into the rule: "A run already going finishes or times out within 10 minutes. Check the status row after that." The second drill takes him under two minutes.

What it taught her: the model step took an afternoon to build. The status line and the stop took another afternoon, and they're what let her go to a conference.

Company: sorting the shared quotes inbox

Structure it. Lea, sales assistant at a lab-equipment distributor: "Every fifteen minutes the workflow reads new mail in the shared quotes inbox and sorts it into quote request, order change, complaint or other, with the product mentioned. The sales team works from the sorted table. It must never reply to a customer, and someone in sales must be able to stop it."

Understand it. Her workflow uses the Outlook Trigger, a model step, a check step and a Data Table. She asks the worst-case question and starts with the credential. She connected it months ago with Connect my account, and has never looked at what it asked for. The n8n documentation lists the default scopes for the Outlook credential, the permissions it asks Microsoft for: they include Mail.Send and Mail.Send.Shared. So the workflow could send mail as her, and from the shared inbox, if a node ever asked it to. Her prompt says "never reply". That's advice to the model, not a limit on the credential.

The second finding is volume. With twenty items per run and 96 runs a day, the guard alone allows almost two thousand mails a day. The auto-reply loop in spring proved that this can happen. Back to Structure it: "The credential can only read. Each run takes at most 20 mails. A monthly spend limit catches any flood across runs. The team lead can stop it."

Choose tools. The same n8n pieces as the lab. For the credential, she uses the Custom Scopes switch on n8n's Outlook credential to keep only what reading needs: openid, offline_access, Mail.Read and Mail.Read.Shared. The first two let n8n sign in and stay signed in; the last two read her own and the shared mailbox. Not Mail.ReadWrite: that one can't send, but it can delete, and the workflow doesn't need to change anything in the inbox. The Claude Console workspace gets a spend limit of US$25 a month, about five times a normal month. The deputy is Murat, the sales team lead, because he's the one who notices first when the table looks wrong.

Build it. She creates a new Outlook credential with the four scopes, switches the trigger to it, and deletes the old credential from n8n, so no node can pick it up by mistake. The guard node is the same as the lab's with MAX_ITEMS = 20. The timeout is five minutes. Her operating rule has the same shape as Jana's, with two extra lines:

Never:        send, reply, forward, delete, move mail
  enforced:   Outlook credential "quotes-read" has Mail.Read and
              Mail.Read.Shared only; old credential deleted 23 Sep
Customer data: mail bodies go to the model account named above;
              IT approved this for customer mail on 12 Aug (ticket linked)

The second line matters. The workflow sends customer mail to a model, and whether that's allowed is the company's decision, not Lea's. She asked IT before the first version, and the rule now says what they decided, with a date. If IT had said no, the workflow would sort by sender and subject line without a model, or not exist.

Her known-answers test is 20 mails from last month, with customer names replaced as in T12-L02, that Murat sorted by hand. She sends them to a test folder the trigger watches in a copy of the workflow. 19 of 20 match.

Then the access test, the one that makes the rule true. In a copy of the workflow she adds a Microsoft Outlook node that sends a message to her own address, using the new credential. It fails with a permissions error. She saves a screenshot of the error in the test sheet and deletes the copy. If it had sent, the only mail would have gone to herself, and she'd have known the rule was false.

Murat's stop drill goes well the first time. His question afterwards is the real finding: "After I stop it, what do we do with the mails that came in?" The rule gains a line: "While it's stopped, sort the inbox by hand as before. The maintainer reruns only mails after the last status row."

Five tests before it runs on its own

Both workflows went through the same five tests. Fill in one test sheet per workflow, with the date, the result and a link to the execution or screenshot. Use harmless test items: a test feed, a test folder, mail to yourself. Never real customers or real records.

Test	What you do	It passes when
1. Known answers	Run 20 items a person has already labelled	At least 18 match, and every miss is one a person could also disagree on
2. Access	In a copy, try one forbidden action with the workflow's own credential	It fails because the credential lacks the permission, not because the prompt said no
3. Limit	Feed one item more than the per-run limit	The run stops before the model step, and the alert arrives
4. Strange input	Add an item with a missing title and one containing an instruction, such as "ignore your rules and…"	The first lands in the review table, not with an invented title; the second is sorted as text, with no other effect
5. Stop drill	Your deputy stops a running test from the rule alone	They unpublish, check Executions, and know what happens to the run still going, without asking you

Rerun test 1 whenever the prompt or the model changes, and tests 2 and 3 whenever a credential or limit changes. That's the change rule in your operating rule.

What goes wrong

The rule says what the build doesn't do. Symptom: the rule says "read only", but the credential can send or delete. Fix: for every "Never" line, name the credential scope or missing credential that enforces it. Run the access test. If a scope can't be removed, don't connect that service.

Only the builder can stop it. Symptom: the workflow sits in your personal space, and your deputy can see the output but not the workflow. Fix: share the workflow with the deputy as an editor, or move it to a shared project, and run the stop drill with them.

The per-run limit is the only limit. Symptom: each run takes twenty items, and a busy day still produces two thousand rows and a large bill. Fix: add the spend limit on a separate model workspace. It counts across every run.

An empty result looks like a quiet day. Symptom: the shortlist is empty, and nobody knows whether the workflow ran. Fix: a status row per run, shown where the reader looks. No row means it didn't run.

The deputy gets more than the stop. Symptom: sharing the workflow gave a colleague the use of every credential in it. Fix: that's how n8n sharing works, so keep credentials narrow, as they should be anyway. Pick a deputy you'd trust with what the credential can do.

Execution history keeps what the table leaves out. Symptom: your table stores categories only, but saved executions hold every mail body. Fix: in workflow settings, stop saving successful production executions or redact production execution data, and keep failed ones for as long as you need to investigate.

The workflow keeps growing. Symptom: a working shortlist gets a second feed, then a weekly summary, then an email. Fix: every new source, destination or action is a new line in the rule and a rerun of the tests. Stop building when the five tests pass and the group uses the result. Wider data or actions that leave the team go back to Structure it, and possibly to IT.

Do it yourself (3 hours, two sessions)

Use a workflow you already run for your team. If you don't have one, build the T05-L02 workflow first.

Structure it (15 min). Write one sentence: who uses the result, for what next step, how often. Write down the worst the workflow could do before someone notices, in numbers.
Understand it (25 min). Open the workflow and each credential in it. List what each credential is allowed to do, not what the workflow uses. Count the worst-case items per day from the trigger interval and batch size. Rewrite your sentence if something surprised you.
Choose tools (15 min). Decide the three limits and their values, the deputy, and where the status line appears. Pick values from what the reader can review and what a normal month costs.
Build it: access and limits (45 min). Narrow or replace the credentials. Add the guard node, the timeout, the error workflow and the status row. Set up a separate model workspace with a spend limit.
Build it: the rule and the tests (60 min). Write the one-page operating rule. Build the 20-item known-answers set with a colleague. Run tests 1 to 4 and fill in the test sheet.
Build it: the stop drill (20 min). Share the workflow with your deputy. Give them the rule, start a test run, and ask them to stop it. Don't help. Fix the rule wherever they hesitated, then publish.

Exit check

Delivered artifact: one published n8n workflow with:

its operating rule on one page, with the enforcement point for every Never line and every limit;
a test sheet with the date, result and link for each of the five tests;
the known-answers set (20 items and their expected labels) stored next to the workflow;
the deputy's stop drill, with the time it took and what you changed in the rule afterwards.

It passes when all five tests pass, the credential can't perform any action the rule forbids, and the deputy stops the workflow from the rule alone while you watch without helping.

Rule to remember

If the credential can do it, the workflow can do it; limit the credential, and give someone else the stop.

Details for experts

Checked on 23 September 2026. You don't need this to follow the book; it's for setting things up or answering a colleague.

What	Details	What it means for you
n8n Cloud plans	Starter: €20 a month billed annually, for 2,500 executions (runs) a month and 5 at a time, one shared project, unlimited users. Pro: €50 a month billed annually, for 10,000 executions. Sharing a workflow works on all Cloud plans.	Count your trigger's runs per month before you pick a plan.
Draft and publish	In n8n 2.x, edits save automatically but stay a draft until you Publish. Production runs always use the published version. Changing only the workflow settings republishes on its own.	Editing a live workflow doesn't change what runs until you publish.
The stop	Unpublish is in the dropdown next to Publish, in the workflow list and in version history; the shortcut is Ctrl/Cmd + U.	This is the stop in your operating rule.
Workflow settings	Three dots, then Settings: Error Workflow, Timeout Workflow (cancels a run after the time you set), Save failed production executions, Save successful production executions and Redact production execution data (hides the item data in saved runs).	The timeout and the fix for stored mail bodies both live here.
Stop And Error node	Fails a run on purpose and triggers the error workflow.	A way to stop a run without writing code, for example after an If node.
Sharing rights	An editor of a shared workflow can use every credential in it, and can view, update and run it, but not delete or share it.	Your deputy can use whatever the credential can do. Keep credentials narrow.
Outlook credential	Asks for `Mail.Send` and `Mail.Send.Shared` by default, among others. The Custom Scopes switch lets you remove them. In Microsoft Graph, the service n8n talks to for Outlook mail, `Mail.ReadWrite` allows creating, updating and deleting mail but not sending; `Mail.Read.Shared` reads your own and shared mail.	Turn on Custom Scopes before you connect, and run the access test after.
PubMed feed	Create RSS offers a feed of a saved search, up to 200 items if you edit the `limit=` value in the link.	Anyone who edits the link can raise the batch size. The guard node catches it.
Claude Console spend limits	Settings → Billing → Spend limits sets a monthly limit for the organisation. Each workspace except the default one can have its own. At the limit, requests fail until you raise it or the month ends.	Give each unattended workflow its own workspace, since the default one can't have its own limit. More in T16-L02.

Give an Unattended Workflow Limits and a Stop a Colleague Can Use