The summarisation agent could reach the whole record because the connector could

An agent is deployed to write encounter summaries. The scope of the work is small and entirely reasonable: for a given encounter identifier, read the clinical documentation attached to that encounter, produce a structured summary for the care-coordination queue, and stop. A product owner can describe the job in one sentence. A clinician can tell you in ten seconds whether the output is any good. It is the kind of narrow, checkable task that agents should be doing first, and there is nothing wrong with the decision to build it.

Underneath it sits a connector. The connector fronts the organisation's FHIR server, and it authenticates with a backend-services credential — a client the authorization server issued to a piece of software rather than to a person, because the summarisation job runs on a schedule and there is no clinician sitting in front of it to establish a launch context. The credential was provisioned once, by an integration engineer, against a ticket that said what the workflow was for. The scope it received was organisation-wide, because that is how the integration was provisioned and because a narrower scope was not on offer for a system-level client at the time the ticket was worked.

For the duration of a one-encounter task, that agent's reachable set is every record the organisation can read.

Everything in this trace is a constructed illustration: the agent, the connector, the ticket, the integration engineer and the summarisation queue are invented. It is not a client engagement, not a disclosed incident, and not a description of any named provider, vendor or product. I have assembled it out of mechanisms that the relevant standards bodies document in their own specifications, and out of duties that appear verbatim in the Code of Federal Regulations, because the argument needs a concrete trace and I will not manufacture one out of somebody's breach notification.

Now trace what the agent can reach, rather than what it was asked to do. The request it actually issues is narrow — a search for the documents attached to one encounter, filtered to one patient. That request is well-formed, proportionate and exactly what the ticket described. But the credential behind it admits the same search with the patient parameter removed. It admits a search filtered by last-updated timestamp across the whole server. It admits every resource type the server exposes, including the ones added to that server after the credential was issued. And it admits the bulk export operation, which is a single HTTP call that returns, by design, everything within the scope of the client's authorization.

None of that is a misconfiguration. Nobody typed a wildcard by mistake. The integration engineer did what the platform made possible, the reviewer approved a connector that was described accurately, and the resulting grant is the ordinary shape of a system-level clinical integration. The gap is not between what was approved and what was provisioned. The gap is between the size of the task and the size of the grant, and there was never a field anywhere in the process that recorded the difference.

Then look at what the incident responder will have, eighteen months later, when somebody asks what this agent touched. A tool-call log entry: a timestamp, a status code, a service account identifier, and the name of the tool. The name of the tool is the name of the connector. It is a label on a capability, not a description of a resource set. Nothing in that entry distinguishes the encounter the agent was asked about from the ones it could have retrieved, because the entry was never designed to carry that distinction — the object it names has no such distinction in it.

The two objections that have to be answered before anything else

There are two serious responses to what I have just described, and both of them are stronger than the version usually offered on their behalf. I want to state each at full strength before answering it, because a reader who works in this sector will already be holding at least one of them, and an essay that swats at a weak version has not earned the right to continue.

The first: the logging already exists, and it is better than you are implying. Certified electronic health record technology is required to log at a granularity finer than a tool name. The ONC and ASTP certification criterion for auditable events and tamper-resistance at 45 CFR 170.315(d)(2) requires recording actions related to electronic health information — additions, deletions, changes, queries, print and copy — along with changes to user privileges, changes to the status of the audit log itself, and changes to the encryption status of locally stored information. It incorporates a published audit-log standard by reference, and the certifying body's own test-method page describes that standard's audit-entry elements as including user identification, patient identification, date and time, type of action, and the specific category of data content involved, such as demographics, pharmacy data or test results. This is not a sector that has to be told what an audit trail is. It has had a certification programme enforcing one for years.

The second: minimum necessary does not apply where you are pointing it. The HIPAA Privacy Rule's minimum necessary standard carries an express carve-out. At 45 CFR 164.502(b)(2), the standard does not apply to disclosures to, or requests by, a health care provider for treatment. That exemption is not an oversight and it is not a loophole; it is a clinical safety judgement, and it is the reason clinical systems are provisioned broadly in the first place. A clinician who needs a record at three in the morning should not be met with an authorization failure because a scope was drawn tightly around an anticipated workflow. Anyone who has watched an access control get in the way of care knows the cost of the opposite error, and it is not a theoretical cost.

Both concessions are real, and I am not going to soften either of them. The audit infrastructure in this sector is genuinely more mature than in most of the industries where agents are being deployed right now. And the treatment exemption means that a blanket demand for narrow scopes, applied at the bedside, would be both bad practice and bad advice.

The answer to the first objection is that the log answers a different question from the one the rule asks. Two duties sit side by side in the Security Rule and they are not the same duty. At 45 CFR 164.312(b), the audit controls standard requires mechanisms that record and examine activity in information systems containing or using electronic protected health information. At 45 CFR 164.308(a)(1)(ii)(D), the information system activity review specification requires procedures to regularly review records of information system activity, such as audit logs, access reports and security incident tracking reports. Recording is the first verb; examining and reviewing are the others, and they are the ones that fail. An entry that names the tool rather than the rows can be recorded perfectly and reviewed to no effect, because there is no question a reviewer can put to it whose answer changes anything. The infrastructure to record a finer object exists — the certification criterion proves that. What is missing is a grant model that produces a finer object to record.

There is a sharper version of the same point, and it is the one that decides cases. Under 45 CFR 164.402, an impermissible acquisition, access, use or disclosure of protected health information is presumed to be a breach unless the covered entity or business associate demonstrates that there is a low probability that the information has been compromised, based on a risk assessment of at least four factors — among them the nature and extent of the protected health information involved, including the types of identifiers and the likelihood of re-identification, and whether the information was actually acquired or viewed. Note the direction of the burden and note the shape of the first factor. Whether it was actually viewed is a question a log can answer. The nature and extent of the information involved is a question about a set, and if the closure of the grant was never computed, the entity cannot bound that set. The notification obligation then follows from the missing analysis rather than from any proven harm. This is the sector's structural asymmetry: you do not have to be shown to have done something wrong, you have to be able to show what could have happened, and a connector name will not do it.

The answer to the second objection is to accept it and to move the argument to where it holds. The treatment exemption at 164.502(b)(2) is about disclosures to, and requests by, a health care provider for treatment. It is not a general amnesty for anything that touches a clinical system. Health care operations, payment, analytics, quality measurement, population health reporting, research, and vendor tooling are all on the other side of that line, and they are precisely where agents are being deployed, because they are the workflows with volume, repetition and a legible unit of output. The essay's claim is therefore bounded, deliberately: at the bedside, breadth is the design and narrowing it is a hazard. On the non-treatment paths, the minimum necessary duty is live, and the enforcement point cannot be a sentence in a prompt.

Which brings the duty into focus, and it is worth quoting whole rather than in the half that usually gets quoted. At 45 CFR 164.502(b)(1), a covered entity or business associate must, when using or disclosing protected health information or when requesting protected health information from another covered entity or business associate, make reasonable efforts to limit the information to the minimum necessary to accomplish the intended purpose of the use, disclosure or request. Both arms matter, and they land on different facts. An agent querying its own organisation's server is not requesting anything from another entity — it is making a use, and the first arm covers it. An agent calling a partner's endpoint is making a request, and the second arm covers that. Either way the obligation attaches to the shape of the call — not to what the model subsequently chose to read, and not to what a system prompt instructed it to ignore.

A name is not a bound

The physical fact under all of this is small enough to state in a line, and load-bearing enough to spend a section on. A tool grant is written as a name and exercised as a transitive closure.

A tool, at the level a runtime sees it, is a name, a description, a schema for its arguments and a credential that lets the server behind it reach the system it fronts. Read that list looking for the field that constrains which patients, encounters, resource types or rows the tool may reach when invoked. There is not one. The argument schema types the arguments. It does not type the reachable resource set, and the reachable resource set is not a property of the tool at all — it is a property of the credential, which was obtained from an authorization flow that knew nothing about any particular task.

This is not an inference. The standards bodies in this sector document the mechanism in their own words. HL7's SMART App Launch specification, at version 2.2.0 (STU 2.2), defines scopes in the form of a compartment, a resource type and a set of permissions, and says of the wildcard form that when a wildcard is requested for the FHIR resource, the client is asking for all data for all available FHIR resources, both now and in the future. That final clause is the closure growing after the approval was given. A reviewer who approved a scope in March approved, textually, whatever resource types the server gains in September. There is no version of a review process that catches that, because the thing being reviewed is not the thing that will run.

The same specification supplies the narrower alternative, which matters for the argument's honesty: constraints can be applied by adding a query-string suffix to existing scopes, beginning with a question mark and followed by parameter and value pairs, so that a scope can be pinned to, say, laboratory-category observations rather than to observations in general. The specification also warns that the scopes ultimately granted by the authorization server may differ from the scopes requested by the client. So the mechanism for narrowing exists and the standard tells you the granted set is not the requested set. What is missing is not the vocabulary. What is missing is anything that ties either one to the task in front of the agent.

The bulk case is starker still, because there the default is the closure. In HL7's FHIR Bulk Data Access implementation guide at version 2.0.0 (STU 2), the system-level export operation is defined to export data from a FHIR server whether or not it is associated with a patient; the patient-level export obtains resources pertaining to all patients; and when the client omits the type parameter, the server will return all supported resources within the scope of the client authorization. Read that last clause slowly. The specification's own stated default, when a caller does not narrow the request, is the scope of the credential. Not the intent of the task. One omitted parameter is the difference between an export and a whole-population read, and the difference is a property of a request the model composes at run time, from a schema that permits both.

And grants compose, which is where the arithmetic stops being additive. A connector that reads clinical data and a connector that makes an outbound request are each unremarkable. A terminology lookup, a referral hand-off, a document push to a partner's intake endpoint: each is a normal thing for a clinical workflow to need, each was approved on its own merits, and each is fine on its own. Held together in one process, they are a path — read, then send — and there was no review step anywhere in the pipeline whose input was the pair. The authority that results is a property of the set, and the set is assembled by whoever configures the agent, typically through a checkbox interface, typically weeks after both approvals.

This sector has a particularly clean instance of the composition problem, and it is worth naming because it shows a grant crossing a boundary that is invisible to connectivity. Substance use disorder records governed by 42 CFR Part 2 sit in the same databases and frequently the same tables as everything else. Under 42 CFR 2.33(b)(1), a covered entity or business associate that receives Part 2 records with consent for treatment, payment or health care operations may redisclose them in accordance with the HIPAA regulations, except for uses and disclosures in civil, criminal, administrative and legislative proceedings against the patient; other lawful holders may redisclose only as may be necessary for contractors to carry out the payment or health care operations specified in the consent, and third-party agents may redisclose only back to the contractor or lawful holder from which the information originated. The permitted downstream uses of those rows are narrower than the rest of the table. The distinction is carried by consent metadata, not by connectivity — so a credential that reaches every row reaches these rows too, and every mechanism the regulation relies on to keep them separate lives somewhere the connector cannot see.

The rule already asks for the object nobody produces

The temptation, at this point in an argument like this one, is to say that the regulations were written for a world of humans at workstations and need updating for agents. That would be a comfortable conclusion and it happens to be false. The texts are written at a granularity the tooling has never delivered, and agents are simply the first deployment where the gap has teeth.

Start with the minimum necessary implementation specification. At 45 CFR 164.514(d)(2)(i), a covered entity must identify those persons or classes of persons in its workforce who need access to protected health information to carry out their duties, and, for each such person or class, the category or categories of protected health information to which access is needed and any conditions appropriate to such access. Three elements: a principal, a resource category, and conditions. Not a system name. A grant recorded as the EHR connector answers the first element at a stretch and fails the second on its face, because the second asks which categories and under what conditions, and a connector name contains neither.

The Security Rule is, if anything, more explicit about non-human principals and finer units. The access control standard at 45 CFR 164.312(a)(1) requires technical policies and procedures to allow access only to those persons or software programs that have been granted access rights. Software programs, in the text, since the rule was written. The corresponding administrative safeguards reach a finer unit: 45 CFR 164.308(a)(4)(ii)(B) calls for policies for granting access to electronic protected health information, "for example, through access to a workstation, transaction, program, process, or other mechanism", and 164.308(a)(4)(ii)(C) calls for policies that establish, document, review and modify a user's right of access to a workstation, transaction, program or process. Two qualifications belong on that citation and I would rather put them there myself than have them supplied by a reader. The list in (B) is introduced as an example rather than as a closed enumeration; and both specifications are addressable rather than required, which means an entity may document why an alternative is reasonable and appropriate in its circumstances.

Neither qualification touches the point. A rule that offers a transaction or a process as its worked example of a unit of grant was written by people with a finer unit in mind than a connector, and it is finer by exactly the amount this essay is about. The text contemplates granting the right to perform an operation; the tooling offers the right to hold a credential. Nobody needs to amend anything for the argument to hold — the argument is that an industry practice drifted above the granularity its own governing text illustrates, and then automated the drift.

Citation discipline: every provision quoted or paraphrased above is taken from the annual Code of Federal Regulations edition published by the Government Publishing Office for 2025. That is the official codification, but an annual edition can lag amendments made after its revision date, and the continuously updated electronic CFR should be checked by hand against any provision before it is relied on in an assessment. Where a rule has a live rulemaking attached to it, I say so rather than treating a proposal as the standard.

The record you cannot produce

The sector's concrete instance of provable afterwards is not an abstraction about audit culture. It is a document a patient can compel, with named fields, on a horizon measured in years — and the first thing to say about it is where it does not reach.

Under 45 CFR 164.528(a)(1), an individual has 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. That right is bounded in two ways the argument has to carry rather than skip. It runs to disclosures and not to internal uses, so an agent reading its own organisation's server is outside it. And the same paragraph carves out, among others, disclosures to carry out treatment, payment and health care operations, disclosures to the individual, incidental disclosures, disclosures made pursuant to an authorisation, and disclosures of a limited data set. Those carve-outs remove most of the workloads named earlier in this piece: a coding agent or a quality-measure agent sits on a health care operations path, and what it discloses is not accountable under this section. Where the right does bite — research disclosures, public health reporting, disclosures required by law, disclosures to law enforcement, and onward transmission outside the permitted set — 164.528(b)(2) requires each entry to carry the date of the disclosure; the name and, if known, the address of the entity or person who received the protected health information; a brief description of the protected health information disclosed; and a brief statement of the purpose of the disclosure that reasonably informs the individual of the basis for the disclosure.

Set those four fields against a tool-call log entry and count what survives. The date survives. The recipient does not — the log holds a service account identifier, which names the caller and not the party the information reached. The description of the information disclosed does not — the log holds a tool name, which names the connector and not the rows. The purpose does not — the purpose lived in the prompt, and the prompt is not part of the grant.

The three missing fields are a resource set, a recipient and a purpose. That is the shape of a capability: what may be done, to which resources, under what conditions and for what stated reason. The narrowness of the accounting right is not a reason to discount the shape. This is the one place in this body of rules where the required fields of a per-access record are enumerated by a regulator, and the three it names are the three the log does not hold. An agent estate is where a system inventory stops standing in for that record, because the number of distinct resource sets touched per unit of human intent rises with every task the estate automates — I have no measurement of by how much, and neither does anybody else — while the connector name stays exactly as informative as it was.

Now the horizons, which are the part that surprises people who have not had to defend a configuration. Under 45 CFR 164.316(b)(2)(i), an entity must retain the documentation required by 164.316(b)(1) — the policies and procedures implemented to comply with the Security Rule, and a written or electronic record of any action, activity or assessment the rule requires to be documented — for six years from the date of its creation or the date when it last was in effect, whichever is later. The clock on a capability configuration starts when the grant is retired, not when it was made. A grant that stays in effect for three years must be defensible for nine.

Hospitals participating in Medicare carry a separate floor. Under 42 CFR 482.24(b)(1), medical records must be retained in their original or legally reproduced form for a period of at least five years, and 482.24(c) requires all entries to be legible, complete, dated, timed and authenticated in written or electronic form by the person responsible for providing or evaluating the service provided. That authentication duty is per entry and it names a responsible person. An agent-drafted entry has to meet it on the same terms as a human one, which is a question worth sitting with: for a summary an agent composed from records it selected under a grant nobody bounded, who is the person responsible for evaluating the service?

And the outer horizon in US healthcare is set by fraud law rather than privacy law. Under 31 U.S.C. 3731(b), a False Claims Act civil action may not be brought more than six years after the violation, or more than three years after the date when facts material to the right of action are known or reasonably should have been known by the responsible federal official, but in no event more than ten years after the violation, whichever occurs last. Because these cases are commonly brought by private relators against providers, the party reading an agent's access record years later is frequently not a regulator at all. And the tolling turns on when material facts were knowable, which is itself a question about what the records show.

Two rules of procedure finish the picture. Federal Rule of Civil Procedure 37(e), as amended in 2015, provides that where electronically stored information that should have been preserved in the anticipation or conduct of litigation is lost because a party failed to take reasonable steps to preserve it, and it cannot be restored or replaced through additional discovery, a court may on a finding of prejudice order measures no greater than necessary to cure the prejudice — and only on finding that the party acted with the intent to deprive another party of the information's use in the litigation may it presume the lost information was unfavorable, so instruct the jury, or dismiss the action or enter a default judgment. Federal Rule of Evidence 902(13), added in 2017, 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. The practical translation is unglamorous and worth stating: a defensible access record gets in on a certification, and an indefensible one requires a witness who can testify to the design of a system that was configured years earlier by somebody who has since left.

Life sciences states it at the granularity of the operation

Where HIPAA implies the unit, the FDA's electronic records regulation names it, and it does so in a phrase worth memorising.

At 21 CFR 11.10(g), controls for closed systems require use 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 is the regulation's own name for per-task intent. A check performed once, at connector-binding time, and never performed again does not meet it — not because someone has read the text creatively, but because a check bound to a credential is a check on the system, and the text distinguishes using the system from performing the operation at hand and requires an authority check for both.

The audit trail requirement sits immediately above it. 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; it provides that record changes shall not obscure previously recorded information; and it requires that audit trail documentation be retained for a period at least as long as that required for the subject electronic records, and be available for agency review and copying.

Pin that retention clause to a clinical investigation and the horizon stops being knowable. Under 21 CFR 312.62(c), an investigator must retain records for two years after a marketing application is approved for the drug under investigation, or — where no application is filed, or the application is not approved — for two years after the investigation is discontinued and the FDA is notified. The audit trail inherits that period. So the retention period for the access record of an agent touching trial data is a function of an approval that may be years away and may never happen, and cannot be calculated at the moment the access occurs. There is no operational answer to that other than to record enough, per operation, that any later horizon is survivable.

/** Compartments defined by SMART App Launch v2.2.0. "system" is the
 *  backend-services case: no user, no launch context, no patient in scope. */
export type Compartment = "patient" | "user" | "system";

/** c=create, r=read, u=update, d=delete, s=search. */
export type Permission = "c" | "r" | "u" | "d" | "s";

export interface ParsedScope {
  readonly raw: string;
  readonly compartment: Compartment;
  /** "*" means every resource type the server supports, now and later. */
  readonly resourceType: string;
  readonly permissions: ReadonlySet<Permission>;
  /** Query-string constraints, per the "?param=value&..." suffix form. */
  readonly constraints: ReadonlyMap<string, string>;
}

const SCOPE_PATTERN =
  /^(patient|user|system)\/([A-Za-z]+|\*)\.([cruds]+)(?:\?(.*))?$/;

export function parseScope(raw: string): ParsedScope | null {
  const match = SCOPE_PATTERN.exec(raw.trim());
  if (match === null) return null;
  const [, compartment, resourceType, permissions, query] = match;

  const constraints = new Map<string, string>();
  if (query !== undefined && query.length > 0) {
    for (const [key, value] of new URLSearchParams(query)) {
      constraints.set(key, value);
    }
  }

  return {
    raw,
    compartment: compartment as Compartment,
    resourceType,
    permissions: new Set(permissions.split("") as Permission[]),
    constraints,
  };
}

export interface GrantShape {
  /** True when any granted scope names "*" as its resource type. */
  readonly admitsFutureResourceTypes: boolean;
  /** True when any read/search scope carries no query-string constraint. */
  readonly admitsUnconstrainedReads: boolean;
  /** True when nothing binds the grant to a single patient compartment. */
  readonly admitsCrossPatientReads: boolean;
  readonly unparseable: readonly string[];
  readonly findings: readonly string[];
}

export function describeGrant(scopes: readonly string[]): GrantShape {
  const parsed: ParsedScope[] = [];
  const unparseable: string[] = [];
  for (const scope of scopes) {
    const result = parseScope(scope);
    if (result === null) unparseable.push(scope);
    else parsed.push(result);
  }

  const readish = parsed.filter(
    (s) => s.permissions.has("r") || s.permissions.has("s"),
  );

  const admitsFutureResourceTypes = readish.some((s) => s.resourceType === "*");
  const admitsUnconstrainedReads = readish.some((s) => s.constraints.size === 0);
  const admitsCrossPatientReads = readish.some((s) => s.compartment !== "patient");

  const findings: string[] = [];
  if (admitsFutureResourceTypes) {
    findings.push(
      "A wildcard resource type admits every type the server supports, " +
        "including types added after this grant was approved.",
    );
  }
  if (admitsUnconstrainedReads) {
    findings.push(
      "At least one read or search scope carries no query-string constraint, " +
        "so the reachable set is whatever the server holds for that type.",
    );
  }
  if (admitsCrossPatientReads) {
    findings.push(
      "At least one read or search scope sits outside a patient compartment, " +
        "so nothing in the grant binds it to the subject of the task.",
    );
  }
  if (unparseable.length > 0) {
    findings.push(
      "Scopes that do not parse were NOT treated as narrow: " +
        unparseable.join(", "),
    );
  }
  return {
    admitsFutureResourceTypes,
    admitsUnconstrainedReads,
    admitsCrossPatientReads,
    unparseable,
    findings,
  };
}

What the field already knows, and where it stops

It would be a poor teardown that presented a well-documented mechanism as a discovery. Almost every component of this argument is published, by the bodies that own the relevant specifications, in language more precise than mine.

The identity and authorization community has already worked out that a scope string is the wrong shape for fine-grained authority, and has published the replacement. RFC 9396, OAuth 2.0 Rich Authorization Requests, on the standards track since May 2023, says plainly that the scope parameter is sufficient to implement static scenarios and coarse-grained authorization requests, but is not sufficient to specify fine-grained authorization requirements — and it gives as its own examples a request to transfer a specific amount to a specific merchant, and a request for read access to one directory and write access to one file. It defines an authorization details request parameter carrying JSON objects whose fields include a required type, locations for the resource or resource server, actions for the kinds of actions to be taken at the resource, datatypes for the kinds of data being requested, an identifier for a specific resource, and privileges. Actions, locations and datatypes are a verb, a resource set and a constraint, in a published standard, with a registered parameter name. The prescription this sector needs is implementable rather than aspirational, and it has been for three years.

The Department has also said, in its own rulemaking, that the analysis this essay asks for is a present obligation rather than a proposed one. In the preamble to the HIPAA Security Rule notice of proposed rulemaking published at 90 FR 898 on 6 January 2025, HHS states that regulated entities are already required to conduct an accurate and thorough risk analysis, and that such analysis requires a regulated entity to perform an inventory of its technology assets and determine how electronic protected health information moves through its information systems. Determining how the information moves through the systems is a reachability computation, described as a duty that already exists. I take no position here on the status of that rulemaking — the proposal is a proposal, the binding text today is the codified rule, and anyone citing it should check its current posture rather than repeating a characterisation, including mine.

It is worth noting what happened the last time a supervisor addressed model risk in a sector adjacent to this one, because it tells you what not to wait for. On 17 April 2026 the federal banking agencies issued revised interagency model risk management guidance — OCC Bulletin 2026-13, with the parallel Federal Reserve issuance SR 26-2 — superseding SR 11-7 and SR 21-8. The OCC's bulletin states that generative and agentic AI models are novel and rapidly evolving and are therefore not within the scope of that guidance, with separate AI guidance promised; that wording is the OCC's own and should not be read as a joint statement of the other agencies. The bulletin also states that it does not set forth enforceable standards or prescriptive requirements. Read as a deferral rather than an exemption, the lesson generalises: every obligation attached to the underlying action survives untouched, and what was withdrawn is the framework that would have specified the controls. Nobody is going to hand a health system a control specification for clinical agents either. Whatever is eventually written will be written against what the field has already built.

Where this argument stops, and what would falsify it

The honest limits are as follows, and I would rather state them than have them found.

The size of the gap is unmeasured, and I am not going to guess at it. I could find no regulator, standards body or vendor publishing any measurement of the ratio between the resource set a tool grant was intended to cover and the resource set it actually reaches. HL7 documents the mechanism — a wildcard means all data for all available resources, now and in the future; a bulk export with the type parameter omitted returns everything within the scope of the client authorization — but publishes no quantification of the consequence. Any circulating multiplier, in either direction, should be treated as unsourced until somebody performs the measurement. The claim I am making is narrower and, I think, harder to dismiss: the closure is not merely large, it is uncomputed. That is the finding.

Narrow scopes exist, and I cannot tell you how widely they are implemented. The constrained-scope form is in the SMART specification, and any server that implements it well undercuts part of my argument for that server's clients. I have not surveyed server implementations and will not assert a figure about them. If it turned out that constrained scopes were both broadly implemented and routinely used for non-treatment agent workloads, this essay would be describing a solved problem in a sector that had solved it quietly, and I would want to know that.

The treatment exemption is a real boundary, not a technicality to route around. At the bedside, the minimum necessary standard does not apply to requests by a provider for treatment, and a piece of advice that ignored that would cause harm. Everything above is addressed to the non-treatment paths. A reader who takes this argument into a clinical access-control review and starts narrowing scopes for treating clinicians has misread it.

A narrower service account per workflow is a real mitigation, and it is not the same thing. An organisation can provision one credential per workflow rather than one per integration, and that meaningfully reduces the closure. It is worth doing and it is not what this essay is asking for. It binds scope to the workflow, which is a class of tasks, rather than to the task instance. The encounter identifier still does not appear anywhere in the grant, so the accounting-of-disclosures fields still cannot be reconstructed from it, and the reviewer still cannot say which of the workflow's permitted rows this particular run was entitled to.

Nothing here shows that harm occurred. I have not described an incident, because I do not have one and would not use one if it were somebody's. The argument is about a record that cannot be produced, not about damage that was done. Those are different claims, and in this sector the second is not the one that decides the outcome: the breach presumption at 164.402 runs against an entity that cannot bound the nature and extent of the information involved, whether or not anything was ever read.

What would falsify the argument, then, is a demonstration that the required record can be reconstructed after the fact from artefacts that already exist — that from a tool name, a service account and a timestamp, an organisation can produce a per-disclosure statement of resource set, recipient and purpose that would satisfy 164.528(b)(2), without having recorded any of the three at the time. I do not think that reconstruction is possible, because the information was never present in the objects being logged. But it is a checkable claim and somebody should check it against their own estate rather than taking my word for it.

The shape of what is missing

Everything above converges on a single absence, and it is worth stating it as an absence rather than as a solution, because the solution is a different piece of work.

The grant that an agent exercises is bound to an integration. The task it performs is bound to an encounter. Between those two things there is no object. There is no record that says: this run, on this date, for this stated purpose, was entitled to read these resources of these types for this patient, and nothing else, and here is the identifier that ties the entitlement to the output it produced. That object is not exotic. Its fields are already enumerated in the accounting of disclosures. Its granularity is already named in the Security Rule's access management specifications and in the FDA's phrase about the operation at hand. Its encoding already exists on the OAuth standards track. Every part of it has been published by somebody. It simply is not minted, because the moment at which it would be minted — the start of a task — is not currently a moment at which any authority decision is made.

How that object gets minted, how it is made narrow enough to be useful and cheap enough to be issued thousands of times a day, how it expires, how it is attenuated when one agent hands work to another, and how it is written into a record that survives a nine-year documentation horizon — that is a construction, and it is the subject of the companion to this piece, "Per-encounter capability minting for clinical agents", published alongside it. This essay deliberately stops here. The teardown and the construction are worth more apart than together, and an argument that rushes to a remedy tends to smuggle in the assumption that the remedy is easy.

What is worth carrying out of the teardown on its own is the sentence the whole thing reduces to. Minimum necessary is meaningless when the enforcement point is a prompt. This sector has the vocabulary, has the expectation, and has had the certification programme for years. What it does not have is a mechanism that binds scope to the task rather than to the integration — and until it does, every agent deployed on a non-treatment path is holding an organisation-shaped credential to do an encounter-shaped job, and the log will not be able to tell anyone the difference.