An organization operates in a regulated industry (healthcare, HIPAA scope). They are planning an agent that performs database schema migrations. Their compliance team requires that any schema change affecting tables that store PHI (Protected Health Information) must receive explicit human approval before execution. Which architecture planning decision correctly implements this requirement?
Select an answer to reveal the explanation.
Short Explanation
Logging after the fact and sending notification emails are just paperwork. HIPAA wants explicit prior approval for PHI changes, so you need a hard gate. The classification-and-review design stops the workflow until a human approves it.
Full Explanation
HIPAA and similar healthcare regulations require that changes to systems handling PHI go through an authorization process before execution, not just notification. The key requirement is explicit human approval, which means the workflow cannot continue without a documented human decision to proceed.
The classification-and-review design implements this as a hard technical control: when the migration workflow reaches the deployment step that targets the protected PHI-table environment, the workflow pauses and requires approval from at least one designated reviewer before any commands run. The agent cannot bypass this pause because it is enforced by the GitHub Actions platform.
This design requires two architectural decisions: first, the agent must classify each migration by the tables it touches and determine whether any are in the PHI-table category; second, PHI-touching migrations must be routed to a job that targets the protected environment, while non-PHI migrations can proceed to a non-protected environment.
This creates the required prior authorization record: the GitHub environment approval log shows who approved, when, and for which workflow run, giving a compliance-ready audit trail.
The audit-table logging approach is incorrect because logging after execution does not provide prior authorization. The migration has already run when the log entry is created. This is a documentation requirement, not an authorization control.
The email-notification approach is incorrect because email notification is advisory, not a blocking gate. The agent can continue executing whether or not anyone reads or responds to the email. HIPAA requires authorization, not notification.
The permission-limiting approach is incorrect because limiting the agent's database permissions so it can only modify non-PHI tables prevents the agent from working on PHI tables at all, eliminating the agent's utility for the PHI migration use case. The requirement is controlled access with human approval, not prohibition.