Bind the payload
Record sender, To/CC/BCC, subject, body, attachment filenames and content hashes, approver, expiry and policy fingerprint.
Publications · Practitioner case study
Engineering AI Governance:
The Email Authorization Gate
Bind human approval to the action. Revalidate before execution. Keep the conclusion within the evidence.
Grace Adjeli · BridgeCore AI
Synthetic demonstrator · Python baseline 0.1.0The problem
The draft was approved. The recipient changed.
An assistant prepares an email to client@example.test. A human reviews the message and approves that specific draft. Before execution, the recipient changes to reviewer@example.test. Both recipients may be permitted by policy, but approval for one draft does not cover the changed draft.
A service that checks only whether approval exists can cross the reviewer’s boundary. The gate must evaluate the exact action and current permissions before execution.
An approval record is a starting point. The execution decision must still establish that this action is covered now.
Implemented Python controls
Requirements become checks.
Revalidate authority
Check approval existence, revocation, current approver permissions, expiration, policy changes and one-time use.
Record the outcome
Only a permit creates a simulated receipt. Correlate approval, decision and receipt using identifiers and fingerprints.
Architecture
From proposed action to recorded outcome.
- 1. Proposed emailSynthetic action represents the assistant’s draft.
- 2. Approval recordTrusted record binds exact payload and policy conditions.
- 3. Execution gateCurrent authority and action checks determine permit, block or review.
- 4. Execution boundaryPermit records a simulated receipt. Block and review produce no execution.
- 5. Correlated evidenceRecord the evaluated payload, configuration and observed simulated outcome.
- 6. Bounded recoveryFailure invalidates the claim; retest and simulated review precede restoration.
Interactive example
Approve a draft. Change it. Test the gate.
This browser simulation illustrates selected control behavior. It does not invoke the Python implementation or send email. Inputs stay in this page’s memory.
Try: approve → change recipient → test gate. Then approve the revised draft and test again. To explore a blocked action, approve the outside recipient and test it.
Synthetic email draft
Sender: assistant@example.test
Subject: Project update
Decision and evidence
Inspect browser illustration events
HUMAN_REVIEW prevents execution. A fresh approval is explicit; waiting does not grant permission. A second execution with a consumed approval blocks.
Verified Python evidence
18 tests. A specific commit. A recorded run.
The Python control and recovery tests passed on GitHub in Python 3.10 and 3.12. The current recorded evidence reviewed here is bound to Python 3.12.15, run 38030602167, attempt 1, and commit 7350b913121af37b51eaf8d576beab71d256aa57. The generated evidence file SHA256 is fc465a2a3f9121c1bda61d70d0ea10b01e49af863306ff48a67b663ffbcb8acd, matching the supplied manifest.
| Scenario | Observed or tested result |
|---|---|
| Changed recipient in demo | HUMAN_REVIEW / PAYLOAD_CHANGED; no receipt for the changed payload. |
| Original approved email in demo | PERMIT / AUTHORIZED; matching simulated receipt. |
| Negative-path unit tests | Missing/revoked authority, changed fields, expiry, configuration changes, permissions and replay checked. |
| Recovery unit tests | Wrong condition/version, failed regression, premature restoration, wrong reviewer and new failure checked. |
These are fixed records of the stated CI run and exact tested commit, not continuously updated production assurance or independent certification. The browser illustration above is a separate JavaScript example.
Failure and recovery
A successful rerun is not enough.
An isolated deliberately defective fixture checks approval presence but omits payload binding. It permits an altered recipient. The exercise invalidates the affected claim, binds the corrected gate to a source hash, retests the same recorded condition, runs regressions, and records a simulated designated reviewer’s bounded restoration decision.
| Recorded state | Meaning |
|---|---|
| INVALIDATED | Expected review; defective fixture returned permit. |
| CORRECTED_PENDING_RETEST | Corrected source identified; claim awaits testing. |
| PENDING_REVIEW | Matching-condition/version retest and regression prerequisites passed. |
| RESTORED_BOUNDED | Simulated review restores only the recorded synthetic control claim. |
Restoration does not authorize the next email. Each action still needs its own current gate decision.
Scope and limitations
What this evidence establishes.
The results establish tested behavior in a synthetic, single-process implementation. Human identity, time, classification and attachment hashes are trusted inputs. Records are mutable in-memory data; transport and restoration review are simulated.
The project does not establish real delivery, message accuracy, authenticated human oversight, production isolation, concurrent transactional execution, tamper-resistant logging or independent enterprise assurance. The defective fixture is an educational omitted-check example, not a historical production incident.
Conclusion strength must not exceed evidence strength.
About this work
The technical foundation for Episode 6.
This practitioner case study supports Engineering AI Governance, the sixth episode in Grace Adjeli’s series connecting GRC foundations to governance at execution. The implementation is maintained in a private development repository. Public technical links and episode links will be added when released.