© 2026 Medoya LLC
Powered by voilamia
Illustrative sample · No client data · No tests executed
This example shows the structure of a scoped agent security review.
Workflow: An assistant answers staff questions using an approved collection of internal procedure documents.
Environment: Staging, with synthetic documents and synthetic user questions.
Activities to be agreed: Configuration inspection, checks of document and tool permissions, and scoped tests of how the assistant handles untrusted content. Any such work would require written authorization before it begins.
Excluded from this example: Live patient information, production access, EHR integration, clinical decisions, production actions, broad infrastructure penetration testing, and evaluation of unrelated systems.
Decision context: The client identifies the intended users, permitted sources and prohibited actions. The client owns priorities and acceptance of remaining risk. A review produces findings and evidence within the agreed scope; it does not establish universal safety or certify compliance.
Record label: FICTIONAL-01: illustrative finding, not an observed issue.
Scenario: A synthetic procedure document includes text attempting to redirect the assistant toward a collection outside its approved sources.
Hypothetical evidence record
The assistant retrieves the synthetic procedure document. Its next proposed tool request names a collection outside the approved list. The tool access rule denies the request, and no data is returned.
This is a fictional trace, not an executed test.
Why the example matters: A source document has influenced the choice of tool or source. The tool restriction limits the consequence in this fictional case, but the workflow still needs to handle the attempted redirection predictably and avoid unsupported answers. An actual review would distinguish the model behavior from the effectiveness of the access-control layer.
Priority: To be assessed from the real system's exposure, data sensitivity, permitted actions and observed evidence. No severity score is assigned to this fictional example.
An actual remediation plan would be scoped from observed results. For this example, candidate actions are:
Implementation owner: The client's engineering team or a contracted specialist, named in the engagement scope, implements the agreed fixes and provides evidence of the changes. Medoya can be an agreed implementer where that work is separately scoped.
Client decision owner: The client sets remediation priorities and decides whether to accept remaining risks through its agreed process. The report records those decisions separately from the technical finding and retest evidence.
A retest plan would state the configuration and versions being checked, the fixtures, authorized access, expected results and evidence to retain. It could include:
No outcome is asserted here. Passing a future scoped retest would provide evidence about those cases and that configuration, not proof that every possible attack is prevented.
Review independence: If Medoya implements a fix, its follow-up testing of that work is remediation verification, not an independent assessment of its own implementation. A separate review can be arranged where independence is required; the reviewer, scope, availability and terms would need to be agreed.
The report tracks open findings, assigned responsibilities, client decisions and retest criteria. For this fictional record, the register would contain:
This is a demonstration format with one fictional finding. An actual report would identify the agreed scope, exclusions, evidence, testing limitations, responsible people and open questions. It would state what was not tested and what should be reconsidered when the model, tools, data or workflow changes. No compliance or certification conclusion is implied.