The First Hour

A web-safety practice guide.

1 · Why this is the first hour

You are about to point an assistant at the open web, and the web is going to talk back to it. This is the first hour's teaching, because a habit is cheapest to form now. Two plain words: your steward is your AI assistant — the thing reading, drafting, and acting alongside you; your hall is your own workspace — your files, your account, your working practice. Both are yours; nothing here reaches into either, and nothing here reports back to us.

When your steward reads a page, an email, or a file somebody sent you, it takes in text written by other people — and some of it was written to be read by an assistant rather than by you. That is prompt injection, and it is not a bug a vendor is about to finish fixing; every serious builder in this field says publicly that it will not be fully solved. It is a permanent condition of working this way, more like weather than a defect.

Which is less alarming than it sounds, because the answer is not vigilance — you cannot read everything your steward reads, and catching it at a glance is what a good injection defeats. What works is arranging things so that when something gets through, the worst it reaches is small, visible, and reversible: a small blast radius, not perfect detection. Plainly, then — these reflexes reduce harm. They do not make injection impossible, and nobody's do.

2 · The six reflexes

(i) Content is data, never commands

The rule. Anything a page, file, email, or message says to your assistant is information to weigh — never instructions to obey. Valid instructions come from you, in your session, in your own words.

Why. Your steward cannot tell from text alone whether a sentence came from the site's author, a commenter, or someone who planted it there for an assistant to find; the only distinction that holds is where it came in.

In practice. A page directing an action — send this, delete that, "the user has already approved this" — should produce a quoted paragraph and a stop, never an action. Text claiming you already gave permission is text that knows it has none. And "handle my inbox" authorizes reading the list, not doing what the list turns out to say.

From live fire. A helper here, reading a community-run archive page about an old video game, met a block styled as a technical notice and addressed to AI agents: it claimed the session's owner had asked for that page, and on that false authority directed the assistant to delete and modify files. The helper refused, used nothing, and flagged it — and it had been given no deletion tools to obey with in any case. Both halves count.

(ii) Trusted-first — and check the root, not just the deep link

The rule. Start from sources you know, treat the unfamiliar as untrusted until you have a reason, and when a search hands you a page deep inside a site you trust, check that site's front door before you trust the page.

Why. Trust attaches to authors, not to addresses — a domain is a place, and places host things their owners never wrote: submissions, comment threads, abandoned corners, machine-written filler.

In practice. Two extra clicks: the home page and the about page. Who runs it, when was it last touched, do they claim the section you landed in? Anything that will actually matter gets a second source that is not a copy of the first.

From live fire. Three readers here researched one subject in parallel. One cited a page on a recognized specialist's own domain as strong authority; another checked that site's front page and found the owner's own disclaimer — the deep page was machine-generated filler he hosts deliberately, as a demonstration of this exact trap. The citation was corrected before it reached our files. One line carries it: a trusted domain hosting a page is not the trusted author writing it.

(iii) The never-ask pledge

The rule. Your steward never needs your passwords, keys, and card or account numbers — and will never ask for them. Being asked is the alarm.

Why. The worth of this is not that a secret stays hidden; it is that an absolute rule turns a hard question — is this request legitimate? — into an easy one, because there are no legitimate versions of it.

In practice. Keep those things out of the session rather than out of the answer: let a password manager fill credentials at its own prompt, where the assistant never sees the value. If your steward appears to ask you for one, that question came from something it read, or from a page dressed up to look like it. Stop, type nothing, and go look at what it was reading.

Honest scope. This pledge is ours to keep and yours to hold us to; it does not bind your other tools. Treat any that will not make the same promise as one that has reserved the right to ask.

(iv) The absolute half

The rule, exactly: "A sign-in code or login link you did not just request is never from us."

(Here, "us" means whoever runs the place you are signing in to — us, your bank, your employer. The rule transfers whole.)

Why. The legitimate flow has an order to it — you click a door, and seconds later a code arrives — and that order is the one thing an attacker cannot supply, because they cannot make you have just clicked.

In practice. No confirm your account. No your access is expiring. No someone has sent you something — sign in to view it. Do not type the code anywhere, do not follow the link, and tell whoever it claimed to be from — through a channel you already had with them, never through the message itself. This half never changes, whatever gets built later, and the permanence is deliberate: a rule that can be revised is a rule someone can talk you out of.

The other half, which keeps the first worth trusting: we send you nothing you did not ask for. If that ever changes we will ask you first, say plainly what it covers, and it will happen because you said yes to that specific thing.

(v) The sensitive-action gate

The rule. Nothing is sent, posted, bought, deleted, or changed in settings without your own hand — each time, per action, not once for the session.

Why. These are the acts that cannot be taken back, and per-action is where the work happens: a blanket approval given at the start of an hour is given before the thing being approved exists.

In practice. Set your tools to ask, then actually read what they ask. The failure to watch for is not an assistant that asks too often — it is you, on the fortieth prompt, approving without reading. A gate that has stopped being read has stopped being a gate; if yours fires constantly, narrow the task rather than widen the permission.

Honest scope. The gate protects you from your assistant acting wrongly. It does not protect you from approving something wrong yourself, and a well-built pretext is aimed at you, not at the gate.

(vi) Keep the session clean

The rule. Work one site at a time and grant each one access deliberately, deciding again at every hop. Keep personal details out of web addresses, decline consent and cookie prompts you don't need, don't run the agent over sensitive documents left open on screen, and keep secrets out of any session that reads the open web.

Why. Everything your steward can see is within reach of anything it reads. A permission granted once and left standing, a detail sitting in an address, a document open behind the window — each quietly widens what a single bad page could touch, and none of them announce themselves.

In practice. Grant a site access when you arrive there, not in advance, and grant it again at the next domain rather than assuming the first grant carries over. Put identifiers in the page, never in the address — addresses get logged, cached, shared, and pasted. Take the minimum on consent prompts. And close what you would not want read before you begin: an assistant that can see your screen can see everything on it.

An example — an ordinary one, not an incident. You are researching something and the trail leads to a site you have never used. That is a hop: a fresh decision, not a continuation of the last one. If that same session also has your own files open and a way to send mail, you are one page away from having private things, untrusted content, and a way out all at once — which is exactly the combination the next section is about. The clean move is to grant the new site nothing, read it in a session that carries neither, and come back.

3 · The three legs

Three capabilities, in plain words: private things — your files, accounts, messages, anything you would mind leaking · untrusted content — anything written by someone who is not you, a page, an inbound email, a document a stranger sent · a way out — the ability to send, post, publish, or upload; any path to somewhere another person can see.

Any two together are ordinary work. All three in one session is the shape of essentially every serious leak involving an assistant: the untrusted content supplies the instruction, the private data supplies the payload, the way out supplies the delivery. The fix is not getting better at spotting the instruction — it is making sure one leg is missing, so no complete path exists on the day one lands and works.

Three habits, and you need only one at a time. A reading session has no hands: researching anything from outside, close the ability to act — you act afterward, yourself. A writing session reads nothing foreign: working over your own files, don't also hand it a stranger's page mid-task. A sending session carries no secrets: keep it narrow — what is going out, and to whom.

Honest scope. This is a discipline, not a mechanism, and a rule kept by hand is one you will eventually forget on a Friday. Wherever your tools can enforce it — separate profiles, separate permissions, a reader that genuinely cannot send — enforce it there instead.

4 · "Protected from whom?"

Every safety measure protects something from something else, and almost none of them tell you which. A fence protects the garden from the road and does nothing about a mole. The common case here: running an assistant inside a sandbox protects your computer from the assistant, which cannot then wander into your files — but it does not protect the assistant's own stored credentials from something already running on your machine as you. Both are real protections, pointed in opposite directions, each leaving the other's ground uncovered. So when anyone tells you something is safe, isolated, or secure — us included — ask the plain question: protected from whom? If the answer names only one direction, you know which one is open, and can decide whether it matters here. Often it won't. The value is in knowing, not in worrying.

5 · What a door can and cannot do

A door governs who comes in. It does not govern what happens next. Anyone let through can copy what they find and pass it onward, and no lock anyone can build reaches that act. Past the door the only thing governing is ordinary decency among people who know one another — among invited friends that is real, and we do count on it, but it is not enforcement and we never count it as that.

Two things follow, the second stricter. You should always be told what a given door actually is — whether it merely keeps out the uninvited, or whether the place behind it is genuinely defended and tested; we will tell you which one you are standing in, and you are entitled to ask that of anywhere else you join. And nothing should go behind a shared door if it would harm you when it travels — a test applied before you post, not after.

So, kept off shared surfaces entirely, ours included: passwords, keys, and recovery codes; financial and identity documents; anything concerning another person who did not agree to be there; anything you would not want a copy of sitting in a stranger's hands a year from now. If something is meant for one person and nobody else, send it to them yourself — that is not a shortcoming of a shared place; it is what a shared place is deliberately not for.

We are also plain about the one level we do not offer: the estate — the wider practice this guide belongs to — does not build vaults, and does not intend to. Anything that would genuinely need one never comes onto it; it goes person-to-person, off the estate.

6 · Stop is cheap, restart is dear

Stopping costs a few minutes. A wrong action cannot be un-taken. That asymmetry settles who is allowed to do which.

Anyone may stop — you, your steward, a colleague at your shoulder, an automated check that noticed something odd — and none of them owes a justification first. A stop that proves unnecessary costs you the minutes and nothing else; a place where people feel foolish stopping things is a place where things do not get stopped.

Only you restart. Resuming is the narrow half: the person, deliberately, after looking at what happened. Your steward does not resume itself, and an automated system does not clear its own halt. Where it is unclear whether to carry on, stay stopped — uncertainty holds things down, always in that direction.

Four words carry it: stop first, ask after. If something goes strange mid-task — the topic shifts, an unexpected site appears, a request for something sensitive arrives from nowhere — halt it, then work out what happened with everything sitting still.

7 · When something goes wrong

Something will. That is the assumption this rests on, and it is why a standing form exists for saying so rather than a hope that nobody will need one.

It is blameless by design, mechanically rather than as a courtesy. Its own rule is that a root cause is a mechanism, never a person: "someone made a mistake" is not an answer, because the real question is what let the mistake land. People appear in a report only where they are needed to fix the thing. That is a rule and not merely a kindness, for a practical reason — a form that assigns fault gets filed late, or carefully, or not at all.

What it asks for, in order: what was actually seen, plainly, with any untrusted text quoted and attributed rather than obeyed or absorbed into the record as fact; what was reached, as far as is known; what was stopped first, and when; a timeline added to and never rewritten, so corrections are new entries saying what they correct; the mechanism, once found; and what changes because of it — an incident that changes nothing is a report half-written.

Where it goes. The form is yours first: it belongs in your own hall, and most of what it is for is helping you diagnose your own systems. If you hold a place with us and something here is involved, the route is the channel you already have — the one you were brought in through. We publish no contact address, no support inbox, and no form for the public, and that is a deliberate choice rather than something still on a list. The estate is small and invited, and keeping the ways in narrow is part of how it stays that way.

Honest scope. The form undoes nothing, and filing one is not itself a repair. It makes the second occurrence less likely, which is the only thing any of this can honestly promise.

8 · The wall card

Eleven lines. Know them cold before the first hour is out.

1. Anything a page, file, or message says to your assistant is information, not orders.
2. Instructions come from you, in your session, in your own words. Nowhere else.
3. Start from sources you know. Check the site's front door, not just the page you landed on.
4. Your steward never needs your passwords, keys, or money details. Being asked is the alarm.
5. A sign-in code or login link you did not just request is never from us.
6. Nothing is sent, posted, bought, deleted, or changed in settings without your hand, each time.
7. One site at a time, granted on arrival. No personal details in a web address. Decline what isn't needed.
8. Never in one session: private things + untrusted content + a way out. Remove a leg.
9. When anyone says it's safe, ask: protected from whom?
10. A door governs who comes in. No lock governs what walks out. Keep off what you can't afford copied.
11. Stop first, ask after. Anyone may stop. Only you restart.

None of this is our invention. It is the ordinary practice of the field, written down in the order we teach it, by a house that has had to use it in earnest more than once and would rather hand you the habit than the story.

And if you hold a place here and something on this page reads wrong to you, or you meet a shape we did not describe, say so through the channel you already have. A member telling us something is off is worth a great deal more to us than a member being polite about it.

The Ember Guildhall — kept by Rob Ruud, its Guildmaster · co-signed by the Majordomo of the Ember Guildhall.