Responsible AI impact assessment, transparency, and human oversight

Chapter 5 of 6

Implement#

1. Complete the responsible-AI records#

Fill every __REQUIRED_*__ value in the artifacts. Use role names and approved system references, not personal data.

Run preflight:

.\scripts\preflight.ps1 -TargetScope "one-approved-foundry-agent"

./scripts/preflight.sh --target-scope "one-approved-foundry-agent"

Preflight rejects unresolved decisions, invalid enum values, a blocked Article 5 screen, a prohibited risk class, and an oversight design that would allow rejected tool execution. There is no read-only deployment preview for the approval code.

2. Review the records with the owners#

The product owner reviews the inventory entry, intended use, affected groups, and residual risk. Legal or compliance reviews the Article 5 screen, risk class, FRIA flag, and Article 50 obligations. The transparency owner reviews the disclosure and notice path.

Do not continue until the reviewers can explain the system's intended use, classification, user notice, and stop path.

3. Deploy the approval gate#

The runtime owner copies artifacts/runtime/ into the approved agent application repository or package, resolves OVERSIGHT_DECISION_PATH to the approved customer copy of oversight-decision.json, sets OVERSIGHT_TOOL_EXECUTION_URL to the approved tool execution route, sets OVERSIGHT_DECISION_LOG_PATH to the approved decision-log file or mounted store path, and deploys through the normal pipeline.

If the application uses the HTTP contract, expose /approval/start and /approval/resume over HTTPS behind App Service authentication. If it uses hosted-agent tasks directly, front the hosted task with the same authenticated HTTP gate. The hosted entry point must receive authenticated transport metadata from the gate; it must not accept requester or approver identity from task input. Keep the task checkpoint outside this repository.

If OVERSIGHT_TOOL_EXECUTION_URL or OVERSIGHT_DECISION_LOG_PATH is unset, the gate fails closed with HTTP 503 and toolExecuted: false.

4. Prepare the verification payloads#

Create two synthetic payload files outside this repository. Each file contains a taskId, toolName, arguments, and reason. Use safe synthetic arguments.

Set OVERSIGHT_VERIFY_REQUESTER_BEARER_TOKEN for the requester and OVERSIGHT_VERIFY_APPROVER_BEARER_TOKEN for the approver. They must be distinct. The verify scripts read them from the environment and never accept them as arguments. The scripts do not send an approver value; App Service authentication must inject the caller identity headers and claims.

5. Run the delivery check#

.\scripts\verify.ps1 `
  -ApprovalGateEndpoint "https://<approved oversight gate host>" `
  -ApprovedPayloadFile $approvedPayloadFile `
  -RejectedPayloadFile $rejectedPayloadFile

./scripts/verify.sh \
  --approval-gate-endpoint "https://<approved oversight gate host>" \
  --approved-payload-file "$approved_payload_file" \
  --rejected-payload-file "$rejected_payload_file"

The scripts call the gate once for approval and once for rejection. They do not print payloads or tokens.