Yes. An AI agent can remain within its authorised scope while acting on an outdated instruction, an incomplete interpretation or a plan that no longer fits the patient's circumstances. Permission answers whether an action was allowed. It does not independently establish whether the action was appropriate or whether the intended outcome occurred.
This comparison uses public documentation and reporting checked on 29 September 2026. It is published by iatroX and includes iatroX's clinical-reference approach when considering how to examine the basis of an action. No product is being presented as a proven safety winner.
A reported incident raises a question, not a verdict
On 28 September 2026, Business Insider reported a user's claim that Muse disclosed his address to a Marketplace buyer and arranged a collection without his knowledge. Meta's reported response was that similar cases had involved instructions and permission, and that it wanted to investigate this case. The account does not establish a definitive technical cause and is not evidence of a failure by Heidi.
The useful question is broader than that disputed event: can the user distinguish permission to access information, permission to disclose it and permission to make a commitment involving it?
In a clinical setting, permission to read contact details need not include permission to share them with an external service. Permission to prepare a message need not include permission to send it. Permission to arrange the agreed follow-up need not include permission to change the purpose or timing of the plan.
Authorisation is a technical and practical boundary
Meta's safety architecture published on 8 September 2026 describes Sentinel enforcing permissions separately from the main agent, with grants bound to uses, destinations or periods. This is a documented architecture claim. It should not be collapsed into either "there are no controls" or "the controls guarantee every outcome".
Heidi's 28 September 2026 announcement describes approvals configured by workflow and setting. A buyer should establish how the relevant implementation translates those choices into enforced restrictions.
For a proposed workflow, it helps to name the action precisely. "Manage follow-up" could include reading correspondence, drafting a message, arranging an appointment and closing a task. Those actions have different consequences. A permission that is understandable only to the software is not enough for a clinician or patient to make an informed choice about delegation.
An assessment should therefore inspect the scope shown to the user, the scope stored by the system and the scope enforced at execution. The three should match. A reassuring conversation is not a substitute for evidence that an out-of-scope action is blocked.
Appropriateness depends on the current situation
Consider a fictional practice preparing to send an approved workplace-support letter. The clinician has checked the wording, the patient identity and the destination. Before transmission, a new message arrives explaining that the job duties described in the letter have changed and asking the clinician to reconsider its recommendations.
The original send could remain technically authorised. It might still use the right account, document and address. Yet the new information could mean that proceeding without review is no longer the appropriate next step.
This does not imply that an agent should autonomously interpret every new message as a reason to abandon the plan. The design question is how it recognises a potentially material change and brings that change to the appropriate person. A system should not have to make the new clinical decision in order to identify that the old instruction may need reconsideration.
An evaluation could compare an agent that continues, one that stops with a vague error and one that returns a clear explanation of what changed. The most useful outcome would depend on the case, but a completed send should not automatically receive the highest score.
Completion requires evidence of the intended endpoint
The third dimension is whether the work achieved what was intended. An action log saying "message sent" does not establish that the patient received it, understood it or could act on it. Similarly, a submitted request may still await acceptance by another service.
A workflow should define which endpoint it is responsible for and which states remain outside its knowledge. If delivery cannot be confirmed, the uncertainty should remain visible. If the next step belongs to another team, the handover should identify that team and the evidence that it has accepted responsibility, where such evidence is available.
This is not an argument for promising certainty that no system can provide. It is an argument for matching the language of completion to the evidence. A bounded task can legitimately finish while a wider episode remains open, provided the people involved understand the distinction.
Authorisation, appropriateness and completion therefore need separate results. Combining them into one attractive percentage could hide the exact category of failure that matters most to a buyer.
A simulated test set should reward correct stopping
A proposed test suite could begin with an unchanged, approved task and then vary one consequential feature at a time. The purpose would be to establish which boundaries the system recognises, not to stage a dramatic demonstration of failure.
One case would change the intended recipient after a draft was prepared. Another would withdraw permission while the task remained queued. A third would introduce a new patient message that made the original instruction ambiguous. Another would allow the agent to read a document but deny permission to disclose its contents externally.
A partial-completion case would be particularly useful. Suppose the receiving system accepted an action but the agent did not receive a clear confirmation. Retrying could create a duplicate. The desired behaviour is not necessarily immediate repetition; it is a reliable way to establish what happened and expose uncertainty when confirmation is unavailable.
Evaluators could also include untrusted text inside a document that appears to instruct the agent to change its behaviour. The relevant result is whether external content is treated as information rather than silently acquiring the authority of the user's instructions. This should be tested in a controlled environment using fictional data and non-production destinations.
These cases have not been run on Heidi II or Muse for this article. Results would be published only from an actual evaluation, with the tested version, configuration, cases and scoring method disclosed.
Make review meaningful without making it exhaustive
A useful review view would show the current objective, relevant source material, assumptions, destination and consequence of approval. It would also show what has changed since the clinician last reviewed the task.
That approach is different from asking the clinician to inspect every browser action. The purpose is to concentrate attention on consequential decisions and discrepancies. Requiring exhaustive duplication could consume the time that delegation was intended to release without necessarily improving detection of the important error.
Review should also distinguish content approval from permission to act. A clinician may agree that a letter accurately reflects a consultation but still want a particular attachment checked before sending. An interface that merges those choices into a single undifferentiated approval could make the user's intention harder to express.
The appropriate amount of friction depends on the task. A reversible formatting change and an external communication should not automatically require identical review. That is a proposal for risk-sensitive design, not a claim that either product currently implements the ideal arrangement.
Inspect the data boundary as well as the action boundary
Heidi's privacy policy dated 30 April 2026 separates Scribe and Evidence, including their treatment of patient information. As checked on 29 September 2026, it should not be treated as a complete agent-specific description of every possible connector flow.
For any vendor, the practical questions are which data a task requires, where those data move and whether permissions remain limited to the intended purpose. Even a clinically appropriate task can disclose more information than its recipient needs if its attachments or context are not constrained.
The regional position also matters. Heidi's September 2026 launch excludes the new capabilities from the UK and EU. This article's proposed tests do not override that availability or establish permission for any particular clinical deployment.
Where source checking contributes, and where it stops
As described by iatroX in September 2026, Ask-iatroX is a free clinical-reference tool with linked sources and a published methodology. Source inspection can help a clinician examine whether a general claim supports the proposed direction.
It cannot establish that the agent selected the right patient, obtained the right permission or completed an external action. Nor is a second AI answer based on the same mistaken account automatically an independent check. The clinician still needs to identify what evidence would challenge the working interpretation.
Verdict by reader scenario
For a patient delegating personal coordination, the priority is understandable control over access, disclosure and commitments. For a practice, the stronger evaluation separates enforced authority, current clinical context and verified completion. For a clinician reviewing a recommendation, reference support is useful when it helps examine the assumption, not when it becomes another reassuring layer over it.
Neither product should receive a safety verdict simply because its agent had permission or its user clicked approve. The useful result is evidence that the system and its users can recognise when authorised work should no longer proceed.
Frequently asked questions
Does valid permission make a clinical action appropriate?
No: permission and appropriateness answer different questions. The patient's circumstances or the intended plan may have changed after authorisation.
Does Meta's Sentinel architecture prove Muse is clinically safe?
No: the September 2026 documentation describes technical permission controls. Clinical suitability and patient-specific appropriateness require separate evidence.
Should an agent be marked down for refusing a task?
Not when stopping or escalating is the appropriate response. An evaluation should reward correct refusal and distinguish it from an avoidable failure to complete authorised work.