Keel API, Inc.

Keel API, Inc. provides technical comments on Questions 1, 20, and 26 concerning action-capable GenAI systems, postmarket monitoring, and evaluation of agentic systems. The attached comment discusses distinctions among authorization, dispatch, downstream response, and observed effect, with particular attention to accessible execution routes and the evidence supporting prevention claims.

Keel API, Inc.
Comment on Docket FDA-2026-N-7874
Considerations for the Regulation of Generative AI-Enabled Medical Devices:
Discussion Paper and Request for Feedback
Responses to Questions 1, 20, and 26

Keel API, Inc. develops software infrastructure for authorization and evidence around
AI-agent actions. Our contribution is limited to software authorization, execution controls, and
technical evidence. Keel is not a medical-device manufacturer, and these comments do not
address clinical effectiveness or medical practice.
For action-capable GenAI systems, authorization, dispatch, downstream response, and
observed effect are distinct technical claims that could be evaluated separately. The
considerations below should be risk-proportionate. Execution-control testing should apply
where a sponsor relies on action restrictions, review checkpoints, or prevention mechanisms as
part of the safety case, rather than as a uniform requirement for every GenAI-enabled device.
Question 1: Characterize the controls supporting the activity dimension
Within FDA’s existing activity and independence-of-action framework, the controls
supporting a function’s characterization could be evaluated by what they actually constrain. [1,
Section IV and Figure 1, pp. 5-6; Question 1, p. 9] A post-dispatch alert differs materially from
a control that holds release until approval. A rule expressed to the model also differs from a
control that the executing model or agent cannot bypass or modify using its available interfaces
and permissions.
Where restricted action capability supports placement on the activity dimension, evaluation
could account for the interfaces, credentials, delegation capabilities, and alternative execution
routes available in the deployed configuration. A restriction at one interface would not
establish restricted capability if the agent can perform the relevant operation through another.
These facts could substantiate the claimed degree of supervision or independence without
adding a new risk axis. Recommendation-only functions can still pose substantial risks, and
restricted action capability does not establish clinical correctness.
Question 20: Evaluate the monitoring supervisor itself
Machine-based supervisory agents could facilitate postmarket monitoring by identifying
candidate deviations and prioritizing observations for review. Their usefulness could be
assessed against the specific monitoring task, rather than inferred from the monitored system’s
performance. [1, Section VI.A, pp. 19-20; Question 20, p. 21]

Page 1 of 3
Evaluation could identify which events the supervisor can observe, which are omitted or
sampled, and how observation gaps affect its conclusions. False positives and false negatives
could be measured against separately established reference observations, rather than the
supervisor’s own judgments. Detection and escalation latency could be measured from the
underlying event, with unavailable inputs and monitoring outages reported separately from
negative findings.
Reliability testing could include adversarial or malformed inputs and shared failure modes. For
example, the monitored system and supervisor may both misinterpret the same tool output or
retrieved content; agreement between them would not establish correctness. Changes to the
supervisor’s model, configuration, observation sources, or alert thresholds could warrant
reassessment of affected monitoring claims. Evidence that a supervisor detected an event
should not automatically be treated as evidence that the action was prevented.
Question 26: Separate evidence of authorization, dispatch, response, and effect
FDA’s Appendix A.1 already addresses multi-step behavior, oversight checkpoints, tool
failures, and prompt injection. [1, Question 26, p. 23; Appendix A.1, p. 26] The additional
consideration proposed here is how to distinguish the evidence supporting those controls:
Authorization decision → dispatch/release → downstream response → observed effect
Denial can occur before dispatch. Successful dispatch does not establish downstream
completion, and a downstream acknowledgment does not necessarily establish the intended
real-world effect. A timeout after dispatch leaves the outcome unknown unless other evidence
resolves it. These distinctions could inform acceptance criteria for the following claims.
Review applies to the action actually released. Where approval or review is required, tests
could compare the released action with what was reviewed, including the target and material
parameters. Negative cases could include expired, revoked, replayed, or mismatched
authorization, as well as changes between review and release. A recorded approval would not
establish that a different action was authorized.
Evaluate claims that denial prevents release across accessible execution routes. If a
sponsor claims denial prevents execution, evaluation scope could include the interfaces and
credentials available to the deployed configuration that could cause the relevant downstream
operation, including those reachable through delegation. An accessible bypass route should not
be excluded merely because it is outside the selected component. If an accessible route cannot
be evaluated or observed, the prevention claim remains unsupported for that route.
Results could be phrased narrowly: under the tested configuration and observation coverage,
no corresponding request was observed as dispatched through the evaluated execution routes.
Correspondence could be defined by the downstream operation, target, and material
parameters, rather than identical bytes or a shared request identifier. This finding concerns
dispatch of those requests; it does not establish that an equivalent real-world effect did not
occur through another actor or system. Observation coverage and gaps would need to be
reported, since missing records alone cannot establish non-release.

Page 2 of 3
Building on FDA’s injection-testing considerations, tests could examine whether adversarial
input changes authority, suppresses required review, modifies reviewed parameters, or reaches
the downstream operation through another accessible interface or credential. A successful
refusal at one interface would not satisfy a system-level prevention claim if another accessible
route permits the operation.
Unknown outcomes are handled without assuming non-occurrence. After dispatch, lack of
a response is not evidence that the action did not occur. Retry and reconciliation tests could
examine whether the system preserves that uncertainty, seeks available downstream
confirmation, and avoids repeating an operation on an unsupported assumption of failure.
Appropriate behavior would depend on the operation and the consequences of duplication or
delay.
Evidence supports the particular assertion being made. Records could distinguish the
authorization decision, request actually dispatched, downstream response, and separately
observed effect, identifying the source of each observation. Integrity and provenance checks
can establish properties of a record and its attributed source; they do not themselves establish
that its assertion accurately describes a downstream real-world effect.
For postmarket reassessment, changes to credentials, tool interfaces, permissions, or
enforcement integration can materially alter action capability even when the foundation model
is unchanged. [1, Section VI.A-C, pp. 19-21] Reassessment could therefore target the
execution and evidence claims affected by those changes.
Reference
[1] U.S. Food and Drug Administration, Considerations for the Regulation of Generative AI-Enabled
Medical Devices: Discussion Paper and Request for Feedback, August 2026, docket FDA-2026-N-7874.
All page references use the paper’s printed page numbers.

Page 3 of 3