The triage agent asked the retrieval agent, and the record shows neither asked anyone

It is 09:14 on a Tuesday and a message has arrived in a clinician's inbox from a patient who is not scheduled to be seen for another six weeks. A triage agent reads it. The workflow is unremarkable by 2026 standards: classify the message, decide whether it needs same-day attention, and if it does, assemble the evidence a clinician would want in front of them before deciding.

The triage agent does not assemble the evidence itself. It calls a second agent for that — a retrieval agent, better at query planning across a record system, worse at everything else. The call is a function call inside the same process. It carries the patient identifier, the classification, and a short instruction about what to look for.

Over the next two seconds the retrieval agent issues five requests against the record system. A patient read. An observation search. A document reference. A condition. A medication request. Every one of them succeeds, is logged, and is logged well — the timestamps are sub-millisecond, the resource identifiers are exact, and the log is held in a store that the certified system will not let anybody edit.

The recommendation goes out. Route to same-day. A clinician acts on it, or does not, and the day continues.

Four months later somebody disputes it. The specifics of the dispute do not matter much for the argument; what matters is the shape of the question, and the shape is always the same. It is not "what did the system do." It is "on whose authority was this patient's chart opened at 09:14 on a Tuesday for a message that had not yet been triaged by a human being."

The organisation can answer a great deal. It can produce the recommendation, with its inputs. It can produce the five reads, in order, to the millisecond. It can produce the classification the triage agent assigned and the instruction it passed. What it cannot produce is the thing being asked for, because the retrieval agent and the triage agent ran as the same service principal, and the moment at which one delegated to the other was a function call.

The workflow above and every timestamp in it are a constructed illustration, assembled from patterns documented in public specifications and in the regulations cited throughout this piece. It is not a report of any incident, deployment, product or client engagement, and no part of this piece describes work done for anyone.

The objection, stated properly

The strongest response to all of this is that it is an outsider's complaint about a discipline that has taken logging more seriously than almost any other, and it deserves to be put at full strength before it is answered.

Healthcare audit logging is not an afterthought bolted onto a product. It is a certification requirement with a mandated content standard behind it. Under 45 CFR 170.210(e)(1)(i), a certified system's audit log "must record the information specified in sections 7.1.1 and 7.1.2 and 7.1.6 through 7.1.9 of the standard specified in § 170.210(h) and changes to user privileges when health IT is in use," and § 170.210(h) names that standard: ASTM E2147-18, incorporated by reference. The corresponding certification criteria at 45 CFR 170.315(d)(2) and (d)(10) require that the actions recorded "must not be capable of being changed, overwritten, or deleted by the technology" and that the technology "be able to detect whether the audit log has been altered."

Sitting above that, the covered entity carries its own duties. 45 CFR 164.312(b) requires it to "[i]mplement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information," and 164.308(a)(1)(ii)(D) requires "procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports." Reviewing the logs is not optional and not aspirational. It is a named implementation specification.

And the service identity is not a shortcut either, in a well-run shop. It has a name. It has an owner. It is covered by a business associate agreement if the software runs outside the entity. Its scopes at the API are narrower than a clinician's. Somebody wrote a document about it and somebody else reviewed the document. The engineer who built it did not cut a corner; they did the thing the rule asks for, which is to assign "a unique name and/or number for identifying and tracking user identity," per 45 CFR 164.312(a)(2)(i).

It is also worth saying plainly that the standard being complied with here is the current one. The Security Rule overhaul that would change the technical safeguards is still a proposal: "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information" was published as a Notice of Proposed Rulemaking on 6 January 2025 with a comment period closing 7 March 2025, and the source citation on 45 CFR 164.312 still reads as amended at 78 FR 5694, 25 January 2013. Nobody building against 164.312 today is building against a stale target. They are building against the operative one.

So the reflexive version of my complaint — you should have logged more — is both condescending and wrong. It is usually said by someone who has not looked, and it is usually followed by a request that somebody else pay for the storage.

I want to concede all of that and then be exact about what it does not touch.

The gap is not a missing field. A missing field implies there was a value and nobody wrote it down. Here there is no value. When the retrieval agent reads a chart under a credential that was minted at process start, there is no principal identifier that would be correct to attach to that row other than the service identity — which is the same one attached to every other row, and which therefore distinguishes nothing about this one. Writing it down five times does not produce five facts.

The gap is not a retention problem. Keep everything, forever, at full fidelity, in a store nobody can edit. The dispute four months later is exactly as unanswerable as it was, because the fidelity is fidelity to a sequence of actions, and the question is about a grant.

The distinction is between a record that is incomplete and a record that is complete about a different object. Only the first is an instrumentation problem. The second is an architecture problem that gets mistaken for an instrumentation problem, mostly because the person who first notices it is holding a log viewer at the time.

What the record is actually required to contain

Read the identity provisions closely, because the whole argument turns on how little they ask for, and how deliberately.

The only identity object the Security Rule requires is a single flat one. 45 CFR 164.312(a)(2)(i), Unique user identification, in full: "Assign a unique name and/or number for identifying and tracking user identity." That is the standard. There is no requirement — and, more to the point, no provision — for recording the principal on whose authority that identity acted. The rule contemplates an identity, not a chain of them.

The audit-controls standard is built the same way. 164.312(b) asks for mechanisms "that record and examine activity." Activity is what the system did. Nothing in the standard reaches the grant under which it was done.

The administrative safeguards confirm the model rather than extending it. 164.308(a)(4)(ii)(C), Access establishment and modification, asks for policies and procedures that "establish, document, review, and modify a user's right of access to a workstation, transaction, program, or process." Access is framed throughout as a property of a user. It is not framed as a relation between two principals, one of whom conferred something on the other.

Healthcare's own audit-record standard has the same shape at the data-model layer, which is worth dwelling on because it is where an engineer would go looking first. In HL7 FHIR R5, the AuditEvent resource defines `agent` as "[a]n actor taking an active role in the event or activity that is logged." The `agent.who` element is required, once per agent. The resource permits multiple agents on a single event, and it defines `agent.requestor` as an "[i]ndicator that the user is or is not the requestor, or initiator, for the event being audited" — a boolean flag on each agent, and the nearest thing in the resource to a distinction between the party who wanted something done and the party who did it.

A boolean is not an edge. Two agents on an event, one flagged as requestor, tells you that two parties were involved and that one of them initiated. It does not say that the second acted under a grant from the first, what that grant permitted, or that the grant was narrower than whatever the first held. There is no structured authorizer-to-performer link between agents on the event. The chain is not underpopulated in this model; it is not representable.

One thing the resource does carry is an authorization element expressing the purpose for which the activity was performed — a reason code, of the purpose-of-use family. That is genuinely useful and it is not what is missing. A purpose says why. The open question is who conferred the right to act on that purpose, for this patient, at this moment.

There is a further oddity in this layer that deserves to be said out loud rather than buried in a footnote. The operative field list for every certified electronic health record audit log in the United States — the enumerated data elements at ASTM E2147-18 sections 7.1.1, 7.1.2 and 7.1.6 through 7.1.9 — is incorporated by reference into federal regulation and is sold by a standards body rather than published. I can tell you exactly which sections the CFR mandates, because the CFR names them. I cannot tell you what they require, because reading them costs money. I am not going to paraphrase a standard I have not read, and the fact that this is the honest position for a rule of general applicability is itself part of the picture.

/** Minimal transcription of the AuditEvent elements a clinical read populates. */
export interface AuditAgent {
  /** agent.who — required, 1..1. The actor. */
  readonly who: { readonly reference: string; readonly display?: string };
  /** agent.type — the functional role this actor played in the event. */
  readonly type?: { readonly code: string; readonly display?: string };
  /**
   * agent.requestor — "Indicator that the user is or is not the requestor, or
   * initiator, for the event being audited." A flag on this agent. Not a link to
   * another agent, and not a description of what that other agent permitted.
   */
  readonly requestor?: boolean;
  /** agent.authorization — purpose of use. Says why, never says who conferred it. */
  readonly authorization?: readonly { readonly code: string }[];
}

export interface AuditEventRecord {
  readonly id: string;
  readonly recordedIso: string;
  /** The action performed: C, R, U, D, E. */
  readonly action: "C" | "R" | "U" | "D" | "E";
  /** One or more agents. Multiplicity is allowed; a relation between them is not. */
  readonly agent: readonly AuditAgent[];
  /** What was touched — this is the part the sector's questions can already answer. */
  readonly entity: readonly { readonly whatReference: string }[];
}

Why this is structural and not an oversight

It would be comfortable to conclude that somebody will patch this — a new column in the audit table, a new element in a future FHIR release, done by the next ballot cycle. I do not think that is right, and the reason is more interesting than the observation.

Go back to the moment the triage agent handed work to the retrieval agent, and ask what would have had to happen for an authority edge to exist there. The retrieval agent would need to hold a credential distinct from the triage agent's, naming the triage agent as its parent, bounded more tightly than its parent's — because a grant identical to its parent is not a grant, it is the same grant seen twice. None of that happened. What happened is one of three things, and all three are non-events.

1. A shared session. The workflow runs inside one authenticated context established at the outer boundary. Each agent reads from it. Nothing is passed, because the session is simply in scope. There is no instant at which the triage agent gives the retrieval agent anything, so there is no instant at which an edge could have been recorded.
2. An inherited credential. A token or key was obtained when the process started and lives in a client object every agent shares. The retrieval agent did not acquire it. It has been in possession of it since before this patient's message arrived.
3. Context carried forward. The instruction, the patient identifier, the classification and the accumulated state cross the boundary. The receiving agent's capability changes, because it now knows things it did not know. Its authority does not change, because authority was never the thing being handed over.

The third case is where the confusion is most productive, and it is worth being precise about it. Multi-agent frameworks give a developer fine-grained control over what the receiving agent knows — what history it sees, what instructions it inherits, what gets filtered out of the handoff. Look down that same surface for a parameter that narrows what the receiving agent may do, and in the patterns I have read there is not one. The thing the design lets you shape is knowledge. The thing it does not model as travelling at all is permission.

That asymmetry is the physical fact underneath everything else in this piece. To attenuate authority, you need authority to be a thing. A session in scope is not a thing that was handed over; it is a condition that obtains. A client constructed at startup is not something the retrieval agent received; it is furniture. There is no handover moment at which a narrower version could have been produced, because there is no handover.

That is what makes it structural rather than negligent. It is not that an engineer forgot to narrow the credential at the boundary. There is no boundary at which narrowing is an available operation.

The authorization standard the sector actually uses makes the same point from the other direction. The version adopted at 45 CFR 170.215(c), and so the one the certified standardized API criterion at 45 CFR 170.315(g)(10) is tested against, is SMART App Launch Release 2.0.0; the passages quoted here read identically in the current STU 2.2. It defines scopes of the form `[patient|user|system]/ResourceType.[cruds]`, and it is explicit about the credential class that matters here: "[s]ystem-level scopes describe data that a client system is directly authorized to access; these scopes are useful in cases where there is no user in the loop, such as a data monitoring or reporting service."

Two things follow. The specification provides no mechanism for one client to delegate a subset of its granted scopes to another client. And it records no field naming which principal authorized a given token. The grammar is rich about what may be touched and silent about who conferred the right to touch it. A headless credential class is not a defect — a monitoring service genuinely has no user behind it, and the standard is right to say so. But a multi-agent clinical workflow is not a monitoring service. It is a chain of actors, each acting for the one before it, running on a credential designed for a case where there is nobody to act for.

Here is where the healthcare case becomes sharper than the general one. The sector has not merely thought about attenuated delegation; it has mandated it, in law, and only in law.

45 CFR 164.502(e)(1)(ii) provides that a business associate may allow a subcontractor to create, receive, maintain or transmit protected health information on its behalf only "if the business associate obtains satisfactory assurances that the subcontractor will appropriately safeguard the information" — the same obligation a covered entity owes under (e)(1)(i). That is a chain, and it is monotone: every hop must carry a named grant that is no weaker in its obligations than the one above it. Cross an organisational boundary with patient data and someone signs for it, and the signature says what the next party may do with it.

The substance-use-disorder rules go further and make the grant travel physically with the data. 42 CFR 2.32 requires that each disclosure made with the patient’s written consent be accompanied by a notice stating that "[t]his record which has been disclosed to you is protected by Federal confidentiality rules (42 CFR part 2)," restricting the recipient's onward use, and warning that "[a] general authorization for the release of medical or other information is NOT sufficient"; paragraph (b) requires the recipient to receive a copy of the consent or a clear explanation of its scope. The section was revised at 89 FR 12626 on 16 February 2024. That is a carried, attenuating, self-describing grant — implemented in paper and PDF because it had to be implemented in something.

So there are three layers, and a patch at any one of them does not produce the object. The credential layer offers a scope grammar with no parent. The runtime layer has nothing to attenuate, because authority never became an object. The record layer defines a slot for who acted and no slot for who authorised the actor. Adding a column to the audit table tomorrow would give you a field populated, at every hop, with the same service principal — which is what the log already tells you, spelled differently.

What fails at the point of use

Start with the duty that is most often described as a policy matter and is in fact a runtime constraint.

The minimum necessary requirement attaches per class of person and per category of data. 45 CFR 164.514(d)(2)(i) requires a covered entity to identify "those persons or classes of persons, as appropriate, in its workforce who need access to protected health information to carry out their duties" and, "[f]or each such person or class of persons, the category or categories of protected health information to which access is needed"; (d)(2)(ii) then requires reasonable efforts to limit access consistent with those categories. The standard sits at 164.502(b).

Note the structure. A class of person, mapped to a category of data. An agent that inherits a session credential is, by construction, not limited to any identified category — it holds whatever the credential holds, which was scoped for the union of everything the deployment might need rather than for what this agent needs for this patient at this moment. You can approximate the duty at the API by narrowing the service account's scopes, and a good deployment does. What you cannot do is derive, afterwards, which category the second agent was operating within on a given call, because the credential did not carry a category and the delegation did not assert one.

FDA's electronic-records rule names the control this defeats more exactly than anything in the Security Rule. 21 CFR 11.10(g) requires "[u]se of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand."

"The operation at hand." That is a check at the point of use, not a check at session entry. A session-entry check answers whether this principal may use the system. An operation-at-hand check answers whether this principal may do this, now. The multi-agent pattern collapses the second into the first: everything the second agent does is authorised in exactly the sense that the process was authorised at startup, which is to say authorised for a set of operations rather than for the operation at hand.

The same part is unambiguous about the model of identity it assumes. 21 CFR 11.300(a) requires controls ensuring "no two individuals have the same combination of identification code and password," and 11.10(j) requires written policies "that hold individuals accountable and responsible for actions initiated under their electronic signatures." Individuals. Held accountable. An inherited credential shared by four agents is not a violation of those provisions in itself — the credential belongs to a system, not to a person — but it is a structure in which the accountability model those provisions assume has nothing to attach to.

And then the Medicare Conditions of Participation, which are the plainest statement of what this sector means by responsibility. 42 CFR 482.24(c)(1) requires that "[a]ll patient medical record entries must be legible, complete, dated, timed, and authenticated in written or electronic form by the person responsible for providing or evaluating the service provided," and (c)(2) requires all orders, including verbal orders, to be "dated, timed, and authenticated promptly by the ordering practitioner or by another practitioner who is responsible for the care of the patient."

The person responsible. An agent-written entry has to resolve to one of those named practitioners or the condition is not met. This is not a technicality; it is the sector's core convention, and it predates every piece of software in the building. Clinical accountability is personal and named. A system that cannot attribute an action past a shared service principal is not merely under-instrumented against a logging standard — it is incompatible with how the sector assigns responsibility at all.

What fails afterwards, which is where the sector actually lives

The point-of-use failures are real, and they are not the expensive ones. The expensive ones happen later, because in this sector the interesting questions are always asked later.

Take the breach analysis first, because it is the clearest example of an evidentiary rule that treats missing information as an adverse finding rather than a neutral one. 45 CFR 164.402 provides that an impermissible acquisition, access, use or disclosure "is presumed to be a breach unless the covered entity or business associate, as applicable, demonstrates that there is a low probability that the protected health information has been compromised based on a risk assessment" — and the enumerated factors include "(ii) The unauthorized person who used the protected health information or to whom the disclosure was made" and "(iii) Whether the protected health information was actually acquired or viewed."

Factor (iii) is answerable from the record: the reads are logged, so you know what was viewed. Factor (ii) is an authority-graph question. Identifying the unauthorized person requires first being able to say which accesses were authorised and which were not, and that separation is exactly what a shared principal destroys. Every access looks identical. The presumption is not rebutted by a log showing that the service account did what the service account always does.

45 CFR 164.414(b) then places the burden where it hurts: "In the event of a use or disclosure in violation of subpart E, the covered entity or business associate, as applicable, shall have the burden of demonstrating that all notifications were made as required by this subpart or that the use or disclosure did not constitute a breach, as defined at § 164.402."

The notification duties compound this on a clock. 45 CFR 164.410(b) requires a business associate to notify "without unreasonable delay and in no case later than 60 calendar days after discovery of a breach," and 164.410(c)(1) requires the notification to include "identification of each individual whose unsecured protected health information has been, or is reasonably believed by the business associate to have been, accessed, acquired, used, or disclosed during the breach."

It is worth being precise about what does and does not fail here, because the sloppy version of this argument overstates it. A well-kept log does record which patient resources were touched, so the raw list of individuals is derivable. What is not derivable is the boundary between the authorised accesses and the unauthorised ones inside that list — and the notification is supposed to identify the individuals affected by the breach, not every individual the service account has ever read. Without an authority chain, the organisation is choosing between an over-broad list that notifies people who were never affected and a narrower list it cannot substantiate. Neither is a good position, and the sixty days run either way.

Then there is the duty that is closest in shape to what the disputing clinician was actually asking. 45 CFR 164.528(a)(1) gives an individual "a right to receive an accounting of disclosures of protected health information made by a covered entity in the six years prior to the date on which the accounting is requested," and (b)(2) requires each entry to state the date, "the name of the entity or person who received the protected health information," a description of the information, and "a brief statement of the purpose of the disclosure that reasonably informs the individual of the basis for the disclosure."

The name of the entity or person who received it. A brief statement of the basis. Both of those are queries against the authority graph, asked by the patient, with a six-year reach. A call graph answers neither: it says a service principal read a chart, which is a fact about a machine and not an answer to a person asking who saw their record and why.

And the horizons stack. HIPAA documentation must be retained "for 6 years from the date of its creation or the date when it last was in effect, whichever is later," per 45 CFR 164.316(b)(2)(i). Medicare-participating hospitals must retain medical records "in their original or legally reproduced form for a period of at least 5 years," per 42 CFR 482.24(b)(1). And a clinical investigator must retain records "for a period of 2 years following the date a marketing application is approved for the drug for the indication for which it is being investigated; or, if no application is to be filed or if the application is not approved for such indication, until 2 years after the investigation is discontinued and FDA is notified," per 21 CFR 312.62(c) — a clock that can run for a decade or more, because it is tied to an approval rather than to the calendar.

Under Part 11 the audit trail inherits the record's period explicitly. 21 CFR 11.10(e) requires "secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records," states that "[r]ecord changes shall not obscure previously recorded information," and provides that "[s]uch audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying."

One more piece of the evidentiary picture makes the retention horizon consequential rather than merely long. Since 1 December 2017, machine-generated records can be admitted in federal litigation on a certificate rather than a live witness. Federal Rule of Evidence 902(13) makes self-authenticating "[a] record generated by an electronic process or system that produces an accurate result, as shown by a certification of a qualified person that complies with the certification requirements of Rule 902(11) or (12)," and 902(14) does the same for "[d]ata copied from an electronic device, storage medium, or file, if authenticated by a process of digital identification."

Read that alongside the retention periods and the shape of the problem becomes clear. The log is not evidence supporting somebody's testimony about what happened. The log is the testimony. It has to answer, years later, without the engineer who built it, without the clinician who was on shift, without anyone who remembers why the service account existed. If the answer it gives to "who authorised this" is the name of a process, then that is the answer of record.

What the field already knows near this

It would be wrong to present this as an unsolved research question. Almost every ingredient is published, dated and reachable; what is missing is an owner for the assembly.

• The sector already implements monotone attenuation, in law. 45 CFR 164.502(e)(1)(i) and (ii) build a chain in which each hop must obtain assurances covering the obligations it owes. That is precisely the shape a runtime delegation primitive would need. It exists between organisations and nowhere inside a process.
• The sector already implements a carried, self-describing grant. For disclosures made with the patient’s written consent, 42 CFR 2.32 makes the authorisation travel with the data and constrain the recipient's onward use, with the recipient receiving the consent itself or a clear explanation of its scope. Again: implemented, mandated, dated — and living entirely outside the credential.
• The record layer has the slot for the actor. FHIR R5's AuditEvent requires `agent.who` and permits several agents per event, with `agent.requestor` distinguishing initiator from performer. The distinction the sector needs is gestured at. It is not structured as a link.
• The authorization layer is explicit that it serves headless clients. SMART App Launch names the no-user-in-the-loop case directly, in Release 2.0.0 and in STU 2.2 alike, in the specification text, and supplies no delegation primitive alongside it. That is a coherent design for the case it describes and an under-specified one for the case the field is now building.
• The integrity layer is already strong. 45 CFR 170.315(d)(2) and (d)(10) require that recorded actions cannot be changed, overwritten or deleted by the technology, and that alteration be detectable. Whatever object gets added, the machinery for making it trustworthy once written is in place and certified.

There is an absence here too, and it should be stated the way absences ought to be stated: as an absence rather than a prohibition. Across 45 CFR 164.312, 164.308, 170.210(e), 170.315(d)(2) and (d)(10), 21 CFR 11.10, FHIR R5's AuditEvent and SMART App Launch (Release 2.0.0 and STU 2.2), I could not locate a requirement that an authority chain, a delegation record, or an on-behalf-of relationship be captured. No provision requires it. Nothing forbids it either, and that distinction matters for what follows.

A word on the proposed Security Rule, because it will come up. The overhaul is a Notice of Proposed Rulemaking, published 6 January 2025 with comments closing 7 March 2025, and as of this writing the operative text at 45 CFR 164.312 remains the January 2013 version. I am not going to argue from proposed regulatory text I have not read in full, and I would treat any argument that leans on the proposals as premature. The current rule is the rule.

The limits of this argument

Several things would weaken or defeat what I have written, and it is worth naming them precisely rather than gesturing at humility.

1. Prevalence is unmeasured, and I am not going to invent a figure for it. The argument assumes a deployment pattern in which several agents share a service principal. I have no primary measurement of how common that is against the alternative — a per-clinician token minted per session and threaded through every hop. If the second pattern dominates in clinical deployments, the practical reach of this piece shrinks considerably, and the honest position is that I do not know the split. Any percentage you see quoted for this should be treated as unsourced until somebody publishes the method.
2. The degradation is unmeasured too. I could locate no published measurement of how attribution accuracy falls as a function of agent-to-agent handoff count — no benchmark, no regulator study, no vendor telemetry publication. That is an open question, and it should be reported as open. A figure attached to it would make this piece more persuasive and less true.
3. Absence of a provision is not prohibition. Nothing in the cited text stops an implementer from recording an authority chain today. A team that builds one is fully compliant and materially better off. The claim here is about what the standards compel and what the prevailing primitives make available, not about what is possible for a determined engineer.
4. A single counter-example in the right place would falsify the structural claim. If a mainstream agent framework ships a handoff that mints a child credential naming its parent and bounded more tightly, or if a future SMART revision adds a delegation primitive with a recorded grantor, then the object exists and the argument becomes a description of a transitional period rather than of a structure.
5. This is a reading of regulatory text, not of enforcement practice. I have quoted the rules and dated them. I have deliberately not built any part of the argument on enforcement actions or settlements, because I could not retrieve the primary documents for them in the course of writing this, and a secondary account of an enforcement outcome is exactly the kind of load-bearing second-hand claim that discredits an argument like this one.
6. The illustration is constructed. The triage workflow, the timestamps and the five reads are assembled from documented patterns to make the mechanism legible. If a real deployment differs in a way that matters — a per-request token, a delegation record kept out of band, a human confirmation before any retrieval — then this piece does not describe that deployment, and it should not be read as claiming to.

One jurisdictional note. I have stated the duties from United States federal text because that is the corpus I retrieved and dated, and because the argument is stronger when the reader can check every quotation against a public source. The structural claim about the runtime does not depend on the jurisdiction: a delegation that leaves no object behind leaves no object behind anywhere. But a reader operating under India's or the Gulf's health-data regimes should re-derive the specific duty from their own primary text rather than importing mine. The mechanism travels; the citation does not.

What an answer would have to be

This is a teardown and it stops here deliberately. But the foregoing constrains the shape of an answer tightly enough to state it without building it, which is the fairest way to end an argument of this kind.

Four properties, and they have to hold together, because any three without the fourth reproduce something that already exists and already fails.

1. The child names its parent, and the naming is checkable by the party doing the checking. An assertion that the retrieval agent was acting for the triage agent, which was acting for a named clinician, is worth very little if the record system has to take it on trust. It has to be verifiable at the point where the call lands.
2. The child is weaker than its parent by construction rather than by policy. Monotone attenuation has to be a property of the credential itself, so that a holder of the narrow thing cannot reconstitute the broad thing. HIPAA already requires this shape between organisations; the question is what it looks like as a runtime object rather than as a contract clause.
3. The constraint is evaluated at the point of use. 21 CFR 11.10(g) already says the check is on “the operation at hand.” A check performed only at token issuance is a check performed before any of the interesting decisions were made.
4. The resulting object reaches the record, and survives there for the retention period. An authority edge that exists in the runtime and never lands in the audit trail solves a security problem and leaves the accounting of disclosures, the breach analysis and the disputing clinician exactly where they started. The record layer already knows how to make a written fact tamper-evident. It needs to be given the fact.

How to build that — what the primitive is, where it sits relative to the orchestration loop, how it maps onto a scope grammar that has no field for it, what it costs per hop, and how it degrades when the record system on the other end knows nothing about it — is a separate and longer piece. It is forthcoming as “Attributable delegation for clinical multi-agent workflows.”

What I would leave a clinical engineering team with is smaller and more immediate. The next time somebody asks who authorised a deep-hop read, notice that your answer is a reconstruction rather than a retrieval. Notice which primitives you are reconstructing it from. And notice that in four months, or six years, the reconstruction will have to be performed by somebody who was not there, out of a record that was designed to answer a different question — one that was, in fairness, the only question anybody wrote a rule about.