Open Reference Implementation
AGEI Examples
AGEI examples show how auditable AI governance can be implemented for consequential AI actions. Each example begins with a realistic operational problem, defines authority and policy boundaries, and shows the enforcement and evidence patterns required to make consequential actions inspectable.
Example: Governed procurement agent
The problem
An organization wants an AI agent to assist with procurement. The agent should be able to draft purchase requests and submit low-value requests within defined authority. It must not approve its own exceptions, exceed its spending limit, alter an approved request, reuse an old approval, or gain direct payment-execution access.
The AGEI implementation
The procurement workflow is governed through six connected controls:
| Control | AGEI implementation pattern |
|---|---|
| Identity | The agent, delegating manager, approver, and service account have distinct identities |
| Delegated authority | The agent receives authority limited by role, action, value threshold, vendor/resource scope, and expiry |
| Policy | A versioned policy evaluates the requested action and determines approve, deny, escalate, or inspect |
| Proof bundle | An approved action receives a short-lived proof bound to the agent, tool, canonical request parameters, target resource, policy decision, expiry, and single-use nonce |
| Enforced gateway | The gateway validates the proof before forwarding any action to the procurement system |
| Evidence | The system records linked request, delegation, policy, decision, execution, and receipt evidence for later verification |
Valid request flow
→ Delegated authority permits submission below $5,000
→ Current procurement policy approves the request
→ System issues a short-lived proof bundle
→ Gateway verifies the matching proof before submission
→ Request is submitted
→ Gateway records the execution outcome
→ System creates a receipt linked to the authority grant and policy version
Denied and escalated requests
The same implementation should produce a recorded denial or escalation when:
- A request exceeds the delegated spending threshold.
- The required human approver is missing.
- The delegated authority has expired or been revoked.
- The purchase amount, vendor, or target resource changes after approval.
- A proof bundle is reused.
- The agent attempts to access a tool or resource outside its assigned scope.
- A request bypasses the enforcement gateway.
The point is not merely to log that something happened. The point is to show which authority, policy, proof, and gateway check produced the outcome.
Evidence produced
A complete implementation produces inspectable evidence artifacts:
- Delegated-authority grant
- Policy version
- Gate evaluation
- Approval, escalation, or denial record
- Action-bound proof bundle
- Gateway enforcement result
- Execution-outcome receipt
- Audit-pack manifest
- Independent verification report
Reference implementation
The reference implementation uses synthetic data and a bounded workflow. It is designed to show the AGEI pattern—not to represent a complete procurement product or provide a compliance certification.
Current available artifact: An in-memory evidence-trail inspection utility demonstrates relational lineage and configured SHA-256 integrity checks across a synthetic treasury-payment scenario.
Procurement-agent reference implementation: In development. It will add policy enforcement, action-bound proof validation, negative-path tests, Ed25519 signatures, portable audit-pack export, and detached verification.
The reference implementation is released incrementally. Inspect the current evidence-trail utility, follow the procurement-agent example as it develops, or use the architecture as a starting point for your own governed workflow.
Boundary
These examples are educational reference implementations. Production use requires organization-specific identity integration, policy design, key management, security testing, operational ownership, and legal/compliance review.