Letting AI Agents Into a Clinical System Without Letting Them Sign

At 7:00 on a Monday, an agent notices that a physiotherapist is out sick, moves nine appointments, messages the affected patients, and drafts the visit note for the one patient who had already been seen on Friday. Nobody asked it to do any of that in the moment. A policy told it to.

If you run technology at a health system, a clinic network or an integrator, that scene is probably both appealing and slightly alarming. The useful question is not "should agents be allowed near patient operations?" They are already coming, through ERPs, assistants and automation platforms. The useful question is a narrower one, and it is the one every security review ends up asking:

1. What exactly can this agent touch?
2. Who is accountable for what it did?
3. Can we prove it afterwards?

While building Genkō, I wanted those three answers to be properties of the system, not promises in a policy document. This post walks through the model we settled on, the parts that hold up under a security review, and the limits we think you should know about before you adopt it.

Start with the premise: agents are users with no judgment

It helps to treat an AI agent, or any integration, as a user who is fast, tireless, and has no professional judgment. That framing makes the design rules fairly obvious:

• Give it the smallest set of permissions that does the job.
• Make its credentials easy to revoke and hard to misuse.
• Never let it perform the acts that carry legal weight.
• Record everything it does in the same trail as everyone else.

Everything below is an application of those four rules.

Rule one: separate surfaces, separate keys

Genkō exposes two machine-to-machine surfaces: a REST API under /api/v1 and a Model Context Protocol (MCP) server for AI agents. Each key belongs to exactly one of them. The REST API refuses MCP keys and the MCP server refuses REST keys, so a credential pasted into the wrong place fails closed instead of quietly working.

Keys are shown once, at creation. After that Genkō stores only a SHA-256 hash, so a database leak does not leak usable credentials. Keys can expire, can be revoked at any time, and carry a prefix (genko_mcp_… or genko_…) so that a key found in a log or a chat message can be identified on sight.

Rule two: scopes, not roles

"Read" and "write" are too coarse for a clinical system. REST keys use granular scopes such as scheduling:read, patients:write, clinical:read and clinical:write, and a key carries only the ones it needs. A scheduling sync gets the scheduling and patient scopes and nothing clinical. A scribe integration gets clinical:write and nothing about billing or patient deletion.

Three details matter more than they look:

• Plan limits are checked on every request, not only when the key is created. If an organization downgrades, a key's powerful scopes stop working immediately.
• IP allowlists fail closed. A key can be restricted to CIDR ranges; an address that cannot be parsed matches nothing.
• Each key has its own rate limit, so a runaway agent loop exhausts its own budget rather than the practice's.

MCP keys are simpler on purpose: read, write or admin, with the plan deciding which are available. Group practices get a read-only key, Practice adds write, and Network adds admin keys.

Rule three: agents draft, people sign

This is the rule I care about most, and the one that tends to settle the room in a security review.

In Genkō an agent can prepare clinical work. It can create a draft visit note, fill in vitals, attach a specialty template, or draft an addendum to a signed note. What it cannot do is finish the job. A note only becomes part of the legal record when a clinician who is signed in to Genkō confirms an attestation that the entry is accurate, complete and their own.

This is enforced rather than hoped for. A request that asks a key to publish a note is refused with a 403 and the error code NOTE_SIGN_REQUIRES_CLINICIAN. Once signed, the note is locked at the database level, for everyone, including owners and Genkō's own server code. A signed or entered-in-error note answers 409 NOTE_LOCKED. To correct the record, the integration can draft an addendum, which is itself only a draft until a clinician signs it.

The practical effect is that an agent can remove nearly all of the typing from documentation without changing who is accountable for it. The clinician's job becomes review and sign, which is what it should have been all along. If you want the longer story of how signing and locking work, I covered it in the EMR release notes.

Rule four: one audit trail for people and machines

Every action an API key or MCP key takes is written to the same audit log as actions by staff: when, which key, which action, on which record. Reads of sensitive records are logged as well, not only writes, because "who looked at this chart?" is as common an audit question as "who changed it?"

For an incident review this is the difference between "an integration did something" and "key c71d created a draft at 10:12, and Dr. Moreno signed it at 10:42." The audit log retention depends on the plan, up to 365 days on Network.

Events out, not just requests in

Agents and ERPs rarely want to poll. Genkō sends signed webhooks for appointment and patient events: appointment.created, .updated, .cancelled, .completed, and patient.created, .updated, .archived, .restored, and so on. Signing secrets are encrypted at rest and rotatable, and delivery targets are validated, so a webhook cannot be pointed at an internal address. Your ERP learns what happened in Genkō the moment it happens, and the agent in the loop does not need standing read access to find out.

When the organization needs more than a plan: dedicated deployments

Some customers need isolation that no plan setting provides. For hospital systems and large groups, Genkō runs a dedicated deployment: its own application and its own database on the customer's subdomain, with sign-in limited to the customer's email domains and owner accounts created by us rather than through public signup.

A dedicated deployment also removes everything that is not the product. The marketing site, public sign-up, llms.txt and the agent-discovery files all answer 404, and robots.txt disallows everything. What stays reachable is what the customer needs: login, the patient portal, the REST API, the MCP server, and the documentation. A deployment that exists for one organization should not advertise itself to the internet.

A rollout that earns trust

If you are introducing agents into a clinical environment, this is the sequence I would follow:

1. Start with a read-only key and a narrow IP range. Let the agent observe for a couple of weeks.
2. Read the audit log together with the people who own the process. Is the agent asking for what you expected?
3. Add write scopes one at a time, scheduling first, with a rate limit well below what you think it needs.
4. Introduce clinical drafts last, and measure how long clinicians spend reviewing them, not how long the agent spent writing them.
5. Rotate keys on a calendar, not after an incident. Expiry dates make that the default.

What this does not do

Honesty belongs in an enterprise post. Genkō has not been through any government certification program. It is built for HIPAA-covered practices and a BAA is available on request, but it does not exchange records with hospital systems: you can export coded lists and vitals as FHIR and download a patient's full record, and that is where interoperability stops for now. There is no e-prescribing and no insurance billing. An agent cannot make those gaps disappear, so if any of them are central to your workflow, factor that in first.

The principle underneath

The model above is not specific to Genkō. Whatever system you choose, ask it the same three questions: what can the agent touch, who is accountable, can we prove it. If the answers are properties of the software, enforced by the database and recorded in the audit log, agents become a safe way to remove administrative load. If the answers live in a policy PDF, they are going to fail the first time something goes wrong at 7:00 on a Monday.

If you are evaluating this for a network or an enterprise deployment, the documentation covers the REST API and MCP server end to end, and the plans page shows which scopes each plan unlocks. For a dedicated deployment, get in touch and we will walk through your security requirements.

This site is built to be read by agents too: every post is available as Markdown, and the blog has its own small MCP server for searching and reading posts.