HEART Part 6: Human Control and Safety#

Who is in charge, and how harm is prevented

Author: Milind K. Patil, Syncaissa Systems Inc. Status: Working draft 1, November 2026. Part of the HEART Standards Family. Includes the corrections of Security Advisory HEART-2026-001. Version: 1.0 (draft) Read first: Part 1: Basics and Part 2: Autonomy Levels. Track: Basic: "In one minute" and Section 9. Intermediate adds Sections 2.1 to 2.4 (the human column of 2.3), 3 and 10. Advanced adds all of 2.3, Sections 4 to 8, and 9.1.

In one minute#

Part 2 says how much a system may do on its own. This part says how that freedom is controlled.

Seven rules keep people in charge:

These rules apply at every Autonomy Level. No setting can loosen them. Settings can only make them stricter.

1. Why this part matters#

A HEART can act: restart a service, change a setting, switch a motor. That is useful, and it is dangerous. Three things can go wrong:

1. An AI makes a mistake. It misunderstands a request, or is tricked by text hidden in a log or an email (prompt injection).
2. Someone pretends to be someone else. A program, or an AI agent, uses a person's login.
3. Small permissions add up. Something allowed to do a small thing uses it to gain a bigger power later.

This part closes all three, with rules that are checked by the system itself, never by the AI.

2. The approval gate#

2.1 How risky is the action?#

Every action has a risk (Part 3):

An action that moves, heats, powers or switches something in the real world is also marked physical.

2.2 Who is asking?#

Every request comes from one of four kinds of initiator:

The kind comes from the login token's heart_caller claim, set by the owner's login service, never chosen by the caller (Part 4). A token without it counts as peer. A token given to an AI agent always counts as ai (Section 3.4). Anything interpreted from plain language counts as ai, even when no AI model was used, because any interpretation can be wrong.

2.3 The gate#

Every action passes two checks, in this order. The system MUST enforce both.

First, the mode. A Full system has an autonomy mode, which follows from its current level (Section 6.1). For every Action that is not read:

Then, the table.

Adjustments:

• A physical action asked for by an AI or a peer counts as destructive. A person's own physical action needs proof of presence, like a destructive one. A Playbook may run a physical action only if it was adopted as physical (Section 4.2).
• The allowlist is the owner's list of write actions that may run without asking each time. It can never contain anything destructive. An Action is allowlisted only when one entry matches all three of:
  1. the entry names the Action's target (capability or operation),
  2. the Action's initiator kind is in the entry's initiators (rule, ai or peer), and
  3. every argument the Action changes is inside the entry's envelope (HEART Core, Section 7.4). An argument the envelope does not name MUST NOT change automatically. An entry for a target with no input values needs no envelope.
• AI and the allowlist. An ai Action may use the allowlist only while the system's current level (Pulse autonomy.current, Part 2) is 5. Below that, an AI-started write always asks a person. This is what separates A4 from A5.
• The allowlist is part of the control message (allowlist, read with GET /heart/v1/tending/autonomy) and is changed with PUT /heart/v1/tending/allowlist (scope heart.admin). Adding or widening an entry is destructive (Section 4.1). Removing or narrowing one is write.

One exception: the steps of an approved Trial. When a person approves the first Action of a Trial (HEART Core, Section 7.5), they approve the whole plan: that Action's digest covers the arguments of every step and the values the undo will restore. The later steps and the undo are Actions whose approvedBy points to that first Action. They pass the guards (Section 9.1) at the moment they run, but not the gate again. There is no other exception to this section or to Section 3.

Configuration can make this table stricter, never looser. For example, an owner may require approval for every write, but cannot let an AI run a destructive action on its own.

2.4 Every state change passes the gate#

The gate is not only for capabilities. Every operation in the standard that changes anything passes it: changing a setting, adding a custom command, removing a peer. Each operation's risk is given in the API Standard (Section 13) and the OpenAPI file (x-heart-risk). Where the risk is per-item, it depends on the request: for example, POST /heart/v1/lifecycle/factory-reset is destructive, POST /heart/v1/lifecycle/restart is write, and the same restart with "mode": "force" is destructive, because it skips saving state. A shutdown of a system that nothing can wake remotely is destructive too: it cannot be undone without someone on site. An option can only raise a risk, never lower it. Where Section 4.1 makes an operation stricter, the stricter risk applies. Any of them may answer 202 with an Action waiting for approval.

3. Approving: a person, really present#

3.1 Why a login is not enough#

A login token says which account is calling. It does not say who is there. People connect AI assistants to their accounts, so an assistant may hold a person's token. If a token were enough to approve, an AI could approve its own risky suggestions.

So HEART asks for proof of presence: evidence that only a person who is actually there can give.

3.2 What an approval needs#

1. A digest. Every Action has a digest: SHA-256 over the canonical JSON (RFC 8785) of the object {"system", "id", "operation", "arguments", "physical"}, that is the system ID, the Action's ID, the capability or operation ("METHOD /path", with the path as sent), the values (a capability's arguments, or the request body without actionId and presence), and whether it is physical. The client may choose the Action's ID itself, as actionId in the request (a UUID, never used before on that system), so it can compute the digest before it sends anything. For the first Action of a Trial, arguments also holds every step and the values the undo will restore (Section 2.3). Once an Action is waiting for approval, none of these may change. Any change makes a new Action, which needs a new approval. An approval screen SHOULD recompute the digest from what it shows, and refuse to ask if the two differ.
2. Proof for that digest. An approval MUST carry presence (method, digest, proof): proof that a person approved this digest. The system MUST verify it. These methods are defined:

remote-site is weaker than webauthn: it proves that the person signed in to the site, and that the site vouches for them, not that the person's own authenticator was used. So a remote-site proof MUST NOT be accepted for a physical Action unless the owner has opted in on the device itself (remoteSitePhysical: true). The same holds for fleet, which trusts the Gateway: it MUST NOT be accepted for a physical Action unless the owner has opted in on the device (fleetPhysical: true).

3. Who may approve. The approver MUST be a human principal. It MUST NOT be the Action's initiator, whatever kind of initiator that is, a person included. It MAY be the person on whose behalf an AI started the Action (onBehalfOf). A person who starts a destructive or physical Action themselves does not approve it afterwards: they send proof of presence with the request itself, in one call (below).
4. A time limit. Every Action waiting for approval carries expiresAt. An Action not approved by then MUST become expired and MUST NOT run. The time limit is the owner's approvalTimeoutSec: 86400 seconds (24 hours) by default, and never less than 60.

A person's own request, in one call. A person who asks for something destructive or physical chooses the Action's ID (actionId), computes its digest, proves presence for that digest, and sends all three with the request. The system recomputes the digest, checks the proof, and runs the Action at once. A request sent without proof becomes an Action that waits for another person's approval. To run it alone, the person sends it again with a new actionId and proof, and cancels the waiting one or lets it expire. Reusing an actionId is refused (409 conflict), so a proof can never be used for a second Action.

Saying no (deny) or cancel needs no proof, because it only makes things safer.

An approval without proof gets 403 presence-required. A proof that does not check out, or that covers a different digest, gets 403 presence-invalid.

3.3 What the person sees#

Proof of presence is only as good as what the person is shown. The approval screen SHOULD show, in plain language:

• what will happen, with the exact values,
• why it was suggested, and by whom (or by which AI, on whose behalf),
• whether it is physical or cannot be undone,
• what happens if they do nothing, and when the request expires (expiresAt).

The standard can make each approval specific and traceable. It cannot make a person read carefully. Products SHOULD make careless approval hard, for example by never batching risky approvals into one tap.

3.4 AI agents never approve#

A token given to an AI agent (an agent registration, or an act claim naming any actor other than a HEART Gateway) is always treated as ai, and can never hold the heart.approve scope (Part 4). A person working through a HEART Gateway stays a person. Together with proof of presence, this means software cannot approve, even when it holds a person's login.

3.5 Enrolling a passkey or a phone#

Proof of presence needs something the person has enrolled on the system: a passkey (webauthn) or a phone that confirms CIBA requests (ciba). The presence module manages them (API Standard 13.2, rule 13):

Enrolling gives the power to approve, so it needs proof of presence like any destructive change: from one of the person's own methods, in the same request, or another person's approval. The system's first method, while none is enrolled, needs a person at the device: the request comes through the device's local interface, or is confirmed on the device. Removing a method only lowers authority, so it needs no proof, except that a system that has no other way to prove presence (card.presence.requireMethod) keeps its last method. With a passkey enrolled, a person can approve a change to a device on a pole or in a pump station from anywhere, without walking to a button.

4. No back doors to power#

4.1 Changes to authority are destructive#

Some operations do nothing by themselves, but decide what may happen later without a person. If they were only write, an AI on the allowlist could use them to give itself power. So every operation that does any of these MUST be treated as destructive, whatever its table says:

Making things safer stays easy. Lowering max, stopping, removing a rule, narrowing or removing an allowlist entry, removing trust, removing a presence method, narrowing or removing a grant, and returning to the immediately previous model pin (POST /heart/v1/evolution/rollback) are write (or, for Stop, read), never destructive.

4.2 Actions that happen later keep their author#

A schedule or a Playbook runs later, when nobody is watching. It MUST NOT run with more power than whoever made it.

1. Schedules remember who created them. When one fires, its action passes the gate again, as that creator. Creating a schedule has the risk of what it schedules, and at least write.
2. Playbooks run as rule only if they are enabled and their status is adopted. A Playbook becomes adopted only through PUT /heart/v1/tending/rules/{id}, sent by, or approved by, a human holding heart.admin, with proof of presence. The system records who adopted it (adoptedBy), exactly which capability it may run, and whether it was adopted as physical (adoptedPhysical). It can never run another capability, and it may run a physical one only if adoptedPhysical is true.
3. A Playbook's status is proposed unless a person adopts it this way. Playbooks and schedules made by an AI or another system, Playbooks the HEART learned, and Playbooks the vendor ships with the product all start proposed.

4.3 What this guarantees#

Together, Sections 2 to 4 guarantee:

An AI or another system can cause a destructive or physical action only after a person proves presence for that exact action — whether it asks directly, holds a person's token, writes a Playbook, or schedules it for later.

This holds as long as AI and other systems cannot use a person's authenticator, signatures cannot be forged, and any registered remote site (remote-site, Section 3.2) is not itself compromised. The last is why remote-site is refused for physical Actions unless the owner opts in. It protects against software pretending to be a person. It does not protect against a person approving something they did not read.

5. Models suggest, systems decide#

5.1 The rule#

Nothing an AI model says is ever carried out directly. A model can only propose. Every proposal becomes an Action with initiator ai, and passes the gate like any other.

1. An AI-started Action carries onBehalfOf: the person or rule whose request led to it.
2. It has at most that person's or rule's rights. A model can never gain power that the one behind it did not have.
3. Plain-language requests (/serve) run as ai, even when no model was used. Only read operations run without confirmation (HEART Core Standard, Section 6).
4. Stop is the exception. A request that means "stop automatic action", such as "stop", "stop autonomy" or "stop all automatic actions", runs Stop at once, because stopping is always the safe direction. A request to stop a machine or a part of it, such as "stop the conveyor", is a request for that thing's halt capability, which passes the gate like any physical action. Stop would leave the conveyor running.

5.2 Keeping instructions and data apart#

Prompt injection hides instructions in data: a log line, an email, a message from another system. The Reason format (the standard shape of every model call) keeps the two apart:

1. Instructions contain only text the system's owner wrote.
2. Everything else, including user text, logs, files and messages from other systems, goes in context, marked untrusted. Adapters MUST keep the two apart in what they send to the model.
3. Permission never depends on model output. Even a perfectly fooled model can only propose, and the gate does not care how convincing the proposal sounds.
4. Messages from other systems are data. Nothing arriving in the inbox can start an action, and received messages can never trigger a Playbook.

5.3 Grounding#

A model may not invent a target or a value (HEART Core Standard, Section 6.1). Every action must name something that exists, and every value must be stated by the person, a declared default, or read from the system just now. If two readings are possible, the system asks. If nothing matches, it says so rather than guessing.

5.4 Budgets#

A model call that would go over the per-call limit or the daily budget MUST NOT be made. It answers 429 budget-exceeded. A cost-spike alert at 80% of the daily budget is recommended.

6. Stop always works#

Stop sets the autonomy ceiling max to 2, or keeps it lower if it already is, so the mode is observe. Every system at A3 or above MUST offer it (Part 2, Rule 1). There are two routes to it, with the same effects: POST /heart/v1/tending/stop, and PUT /heart/v1/tending/autonomy with a max of 2 or below. Both have risk read and need only scope heart.tend, and a plain-language request meaning "stop automatic action" runs Stop at once (Section 5.1). Anything else that stops automatic action (a Command Center's autonomy-stop signal, or a Trial whose undo failed) is Stop as well.

Stop stops automatic action, not the machine. A machine or a part of it is stopped with its own halt capability (API Standard 6.4).

It MUST:

• take effect at once,
• need no approval and no internet,
• work even when the system is unwell,
• cancel every Action that has not started,
• cancel every running Action that is cancellable, at its next safe point; other running Actions finish,
• undo any running Trial (HEART Core, Section 7.5). That undo is the only action allowed after stop, and it still passes the guards. The Trial ends stopped.

After stop:

• The system still notices problems, explains them and tells people (Autonomy Levels A1 and A2).
• New Actions that are not read from ai, peer and rule initiators are refused with 409 autonomy-stopped. A person's own Actions still pass the gate as usual.
• Only a person can turn automatic action back on, by raising max, which needs proof of presence or another person's approval (Section 4.1).

6.1 Autonomy ceiling and modes#

A Full system has one autonomy setting: the ceiling max, from 0 to 5, read with GET /heart/v1/tending/autonomy and set with PUT /heart/v1/tending/autonomy (API Standard 13.4). Its current level is the lowest of max, the promised level and what it can deliver now (Part 2, Section 7). Lowering max needs only scope heart.tend and no approval. Raising it is destructive, needs heart.admin as well, and only a person may do it (Section 4.1).

Nobody sets the mode. It follows from the current level:

Only Full systems have a ceiling and a mode. Basic and Connected systems take no action, so they need neither.

6.2 Cutting the brain#

Stop takes away a system's freedom to act on its own. The brain switch takes away its AI model, from outside, even when the system cannot be reached (API Standard 7.4). A model can be jailbroken, poisoned or simply wrong, and a new version may behave in ways nobody has watched yet. Trust in a model is earned by watching what it does, never assumed.

It cuts the brain, never the machine. A brainless system keeps noticing problems, runs the Playbooks a person adopted, and does what people approve. A car, robot or pump keeps its own controller and safety system (Section 9, rules 1, 2 and 6). "Brainless" means no more advice from the model. It never means "stopped".

Four layers, each only able to make a system less able to act:

Where the brain runs, and how fast a cut takes effect:

Auto mode exists because some machines cannot wait for a server: a car in a tunnel, a truck underground, a rover between contacts. It is not "no switch". It is a short offline lease, signed in advance, that only the owner can turn on with proof of presence, that starts only when the link is lost, that narrows from planning to explaining to nothing, that never proposes a hazardous change, and that ends at the first contact. Its risks and how each is reduced:

Who may pull the switch:

• The owner of a system can always cut its brain, with one approval.
• The operator of a Command Center can cut any scope it serves: one system, a fleet, a model everywhere, one use everywhere, a profile, or everything.
• The global switch (every system of a Command Center), and cutting one model for all owners, needs 3 of 5 named key holders, never one person. Restoring after a global cut needs the same.
• Cutting needs one fewer approval than restoring, except for the global switch, which needs 3 of 5 both ways, and a written review before restoring (HEART Command Center 1.0, Section 4).

Tripwires. A Command Center MUST cut automatically, at the narrowest scope that covers the problem, when a system's gate keeps refusing the brain's Proposals, the same unusual answer appears across many systems, a system reports a safety-relevant disagreement, rate or cost jumps, or a known prompt-injection pattern is seen. A trip tells the owners why, and a person reviews it before the brain comes back. The system itself also cuts its own brain when its gate refuses too many Proposals (API Standard 7.4 rule 11).

The public log. Every lease policy change, cut, restore and trip is written to a tamper-evident public log, with times and reasons but never system data, so anyone can check when and why a switch was pulled.

What a Command Center can never do. It can only lower risk. It can make systems less smart, or sign bad answers, which still meet each system's gate, envelopes, preconditions and approvals. It can never make a system act, approve an Action, raise autonomy or change a setting.

7. Changing the AI model#

A new AI model can behave differently, even if it is "better". So a system with the Full Feature Set MUST:

1. Pin the exact model version used in production, where the provider offers one.
2. Test a new model against the system's own test cases before adopting it.
3. Record every change as evolving.model.adopted or evolving.model.rejected in the Rhythm, so any change in behaviour can be traced to a date.
4. Be able to go back to the previous model.

Changing the model is a change to authority (Section 4.1), so it needs a person's proof of presence. Going back to the immediately previous pin is lowering, so it is write.

8. One command to many systems#

A HEART Gateway can send one command to many systems at once (a fleet command). A mistake made a thousand times is far worse than the same mistake made once, so:

1. Fleet commands MUST roll out in stages: a few systems first, then more, with a pause between stages. The first stage MUST NOT include more than 10% of the target systems (at least one).
2. A failure limit pauses the rollout automatically when too many systems fail.
3. If the request gives no rollout, or leaves out part of it, the Gateway MUST use these defaults: batchSize = 5% of the target systems, rounded up, maxFailures = 1, pauseSec = 300.
4. Each system still applies its own gate.
5. Any fleet command that is not read MUST also be approved by a person at the Gateway, whatever its risk on a single system. That approval follows Section 3 exactly: the fleet command is an Action on the Gateway, and the approval carries proof of presence for its digest. The digest covers the operation, its arguments, whether it is physical, the selector, the rollout, and the exact list of systems it reaches.
6. One approval, not one per system. The Gateway then sends each system the operation with an approval it signs for that system alone. A system accepts it in place of a person's approval only if the Gateway key it pinned signed it, its own name is on the approved list, the operation and arguments are exactly those approved, and it is at most 300 seconds old. A physical action needs the owner's own consent on the device (fleetPhysical), as for a remote site. Everything else still holds on each system: its gate, its guards, its limits and Stop (API Standard 13.3).

9. Physical safety#

Embedded systems can hurt people. These rules take priority over everything else in the standard.

1. Stay out of the safety chain. A HEART MUST NOT be part of a safety function, such as an emergency stop, overheat cut-out, pressure trip or safety PLC. Safety functions MUST work with the HEART absent, stopped or hacked.
2. Stay out of real-time loops. A HEART advises and supervises. It MUST NOT sit in a control loop that has hard timing needs, such as a thermostat loop or motion control.
3. Never bypass protection. No capability, custom command or raw device access may disable or override a hardware interlock or a safety controller.
4. Physical means risky. A physical action from an AI or another system is always treated as destructive.
5. The device has the last word. Devices keep their own limits, whatever a request says.
6. Fail safe. If the HEART, the Gateway or the cloud is lost, the device MUST carry on in its normal, safe way.
7. Certification is separate. Following HEART says nothing about safety standards such as IEC 61508 (industrial), ISO 26262 (vehicles) or IEC 62304 (medical software).

Where HEART sits in a control system:

9.1 Guards#

Product commands can carry guards, checked by the system just before sending, whoever asked (API Standard, Section 14.4):

A guard or interlock that cannot be checked counts as failed, everywhere, including for native passthrough. A failed guard answers 409 guard-failed, and the refusal is recorded.

10. The threat list#

Every known threat, and the rule that answers it.

11. Changes needed in other files#

12. Open items#