Lockdown mode for hospitals: how to make every AI agent write wait for a person

The short answer

To lock down AI agent writes in a hospital, make the strict path the only path. Every write waits for a named person, even when your rules would allow it. The riskiest statements never run at all. A write nobody could check stops that agent until a person looks. Each agent reaches one system. And switching all of this off takes two people, not one.

None of that needs a particular product. It’s a set of decisions you can make in any agent setup. Deedglass, the open-source gate we build, ships them as one switch called lockdown mode (from 0.9.0), so the examples below are real commands and real output.

This post is about who approves software writes. It says nothing about whether a write is clinically right. That stays with the people who approve it.

Why rules alone aren’t enough

Most teams start with rules: allow reads, ask for approval on deletes, block DROP TABLE. Rules are good. They also drift. Someone adds an allow rule to unblock a demo. An agent gets a new tool that nobody classified. A timeout on an approval is set to a day because people complained.

In a shop’s order database, a drifted rule costs a refund. In a system that holds patient records, claims or prescriptions, the bar is higher, and the people who answer for the system usually want two things a rule file can’t promise on its own:

1. A person saw every change before it happened. Not most changes. Every one.
2. The strict setup can’t be loosened quietly. Not by one admin, not by one edited file.

A lockdown is a layer that sits on top of your rules and only ever tightens them. The rules decide first. The lockdown then turns an allow into “wait for a person”, and never turns a deny into an allow.

Six parts of a lockdown

These six parts are the pattern. Each one closes a specific gap.

1. Every write waits for a person. If the rules allow a write, the lockdown converts it into an approval request. If the rules already ask for approval, the lockdown keeps that. Approvals should expire fast: an approval that waits a day gets clicked without reading. In Deedglass, every agent write waits for a person even when the active policy allows it, a high-risk write (destructive tools, deletes, database functions, undo, Stripe) needs two different people, and every approval expires within 15 minutes.¹

2. Some statements never run, whatever the rules say. A few database operations have no safe reading in a production record system: dropping or truncating a table, changing the schema or permissions, an UPDATE or DELETE with no WHERE. Don’t ask a tired person to approve them at 2 a.m. Refuse them. In lockdown, DROP, TRUNCATE, schema and permission changes, and UPDATE or DELETE without a WHERE never run through the native Postgres connector, whatever the policy says.¹

3. A result nobody could check stops the agent. Sometimes a write runs and nothing can confirm what it did: no read-back, no change log, a timeout halfway. Most setups log that and move on. A lockdown treats it as a stop sign. In Deedglass, after an agent’s action ends Can’t check, that agent’s writes are refused in every session until a person acknowledges the action with deedglass lockdown ack; reads still run.¹ The hold covers the whole agent, because the agent picks its own session name and could otherwise step around a per-session hold with a new one.

4. One key reaches one system. An agent that can write to the records database and the billing API has a bigger blast radius than either job needs. Scope each agent to one connector. In lockdown, each agent reaches only the connector its connector label names, so every key it holds reaches one connector.¹ An agent with no label is refused.

5. Turning it off takes two people. If one admin can switch the lockdown off, the lockdown is only as strong as that admin’s laptop. In Deedglass, turning lockdown off needs two different owners or admins on the server, and both steps are sealed; there is no API route that turns it off.¹

6. The records get stronger too. A strict mode that keeps weak records is half a lockdown. Records of approvals in a hospital may be read years from now, so they should carry a post-quantum signature beside today’s one, and exports should carry outside timestamps. With lockdown: true, prod refuses a config without an ML-DSA-65 seal key or with timestamps.at_export: false.¹

What it looks like in Deedglass

The switch is one line in deedglass.yaml, or deedglass lockdown on for one organisation on a shared server. The commands, from the 0.9.0 binary:

Code What the screen or file shows, copied as is.

$ deedglass help lockdown
deedglass lockdown · Turn on the strictest setup, or check it

Usage  deedglass lockdown <command> [flags]

  status  Show lockdown and what weakens it
  on      Turn lockdown on for the org
  off     Ask for, or countersign, lockdown off
  ack     Release a Can't check hold on an agent

The config check is where part 6 bites. A dev config with lockdown on and export timestamps off is refused, and the missing post-quantum key is a warning:

Code What the screen or file shows, copied as is.

$ cat deedglass.yaml
lockdown: true
timestamps:
  at_export: false
$ deedglass config print
○ DEEDGLASS_SEAL_PQ_KEY_FILE isn't set: lockdown seals with Ed25519 only. Run deedglass keys rotate --alg ML-DSA-65 (prod refuses this).
○ deedglass.yaml is readable by every user on this machine. Run chmod 640 deedglass.yaml.
✕ timestamps.at_export is false, and lockdown keeps export timestamps on. Remove timestamps.at_export: false, or turn lockdown off.

In prod, the missing key stops the server from starting:

Code What the screen or file shows, copied as is.

$ cat deedglass.yaml
env: prod
lockdown: true
$ deedglass config print
✕ DEEDGLASS_SEAL_PQ_KEY_FILE isn't set, and lockdown needs the dual seal (Ed25519 and ML-DSA-65). Run deedglass keys rotate --alg ML-DSA-65, then point DEEDGLASS_SEAL_PQ_KEY_FILE at the file it writes.

The off switch is two commands by two people, the second within 30 minutes of the first. The person who asked can’t countersign.

Code What the screen or file shows, copied as is.

deedglass lockdown off --as priya@acme.test --reason "Pilot over"
deedglass lockdown off --countersign --as sam@acme.test

Each refusal in lockdown is sealed as a deny that names the rule that refused it, such as lockdown.no-drop-truncate or lockdown.write-needs-person, so the record shows why an agent was stopped and not only that it was. The hospitals page and the security page summarise the same rules.

What lockdown costs

Be honest about this with whoever asked for it. Lockdown is slow on purpose.

• Every write waits. An agent that made forty small writes an hour now makes forty approval requests an hour. If nobody answers within 15 minutes, the answer is no.¹ Plan who is on call to approve, or the agent stops being useful.
• High-risk writes need two people. A team with one admin can’t approve a delete at all. The lockdown docs say an organisation with fewer than two owners or admins gets those writes refused.
• One unchecked result blocks an agent. After a Can’t check, that agent does nothing but read until a person runs ack.¹ For a flaky connector, that will happen often.
• Approval fatigue is real. A person approving forty writes an hour will start skimming. Lockdown makes sure a person decides. It can’t make them read carefully. Keep agents in lockdown to the jobs where every write matters, and keep those jobs small.

What lockdown doesn’t do

From the published limitations:

• The server’s command line can’t tell who is typing. lockdown on, off and ack run on the server, and the names given with --as are recorded as given. Anyone with a shell on the server and its database URL can name two people, or change the database directly. The two-person rule stops one admin key or one Console session. It doesn’t stop someone who controls the server.
• The SQL refusals cover the native Postgres connector only. SQL sent through another tool, such as an MCP server’s own execute_sql, isn’t classified. The person approving sees it, but nothing refuses it automatically.
• Removing lockdown: true from the config file isn’t a sealed record. Only the per-organisation setting’s changes are.
• One person can release a Can’t check hold, not two.
• High risk is a fixed list. A write outside it needs one person. Your own rules can ask for two on anything else.
• It doesn’t judge a write. Whether a change to a record is right is a human and clinical question. Lockdown makes sure a person answers it, and records who did.

A checklist

Whatever tool you use, a lockdown for a high-stakes system should answer yes to each of these:

1. Does every agent write wait for a named person, even when a rule allows it?
2. Do approvals expire in minutes, not hours, with timeout meaning no?
3. Do deletes and other irreversible writes need two different people?
4. Are DROP, TRUNCATE, schema changes and unbounded UPDATE or DELETE refused outright?
5. Does a write that couldn’t be checked stop that agent until a person looks?
6. Does each agent’s key reach exactly one system?
7. Does turning the lockdown off need two people, and is each step recorded?
8. Are the records signed so they can still be checked in twenty years, with outside timestamps on exports?
9. Have you written down what the lockdown doesn’t cover, starting with anyone who has a shell on the server?

For the wider question of what a hospital’s records of AI activity should hold, see the audit trail for AI in healthcare and AI agents writing to patient records. For approvals on a single tool rather than a whole system, see requiring approval for MCP tool calls.

Try it. A new local stack can start in lockdown with deedglass init --lockdown. It adds the post-quantum seal key, labels the quickstart agent with one connector, and makes the first smoke write wait for a person. The lockdown docs list every rule and every limit. To see a held write first, open the playground; npx deedglass scan --postgres-dsn-env DATABASE_URL grades what an agent can reach (explained here).

Written with AI assistance and checked against our claims register.