Approvals and audit for a regulated payments estate

A payments platform ran its workload across ten AWS accounts (production, staging, a data lane, and a set of regional shards). Each account had its own console, its own IAM story, and its own idea of who approved what. The change-control process was strict on paper and fuzzy in practice: tickets were filed, chats were had, and screenshots were pasted into the audit folder.

The problem: evidence you couldn't defend

The regulator never asked whether the team was careful. It asked what changed, who approved it, and how the change moved through the estate. Screenshots answer 'what happened' poorly and 'who approved it' almost not at all, because a screenshot is easy to stage and impossible to trust.

The deeper problem was that approval lived outside the system. A person clicked 'approve' in one tool, pasted the result into a ticket, and the actual apply happened later through a different surface. Any of those steps could be missed, and nothing tied them together.

If your approval is a screenshot and your apply is a terminal session, your audit trail is an argument, not a record.

The approach: policy before apply, approvals inside the graph

We connected all ten accounts through the SDK adapters so one inventory and one policy engine saw the whole estate. Then we changed where approval happened. Instead of a checkbox in a chat, an approved change became a node in the control plane: a plan, a policy result, an approval record, and an apply, all referencing each other.

plan (OpenTofu) ──▶ policy evaluationpolicy pass/deny ──▶ approval requirementapproval (human, named) ──▶ deploy waveapply ──▶ audit envelope (plan+policy+approver+outcome)

Implementation steps

• Connected all ten accounts; reconciled inventory and deleted a pile of stale IAM assumptions.
• Defined an estate policy that denies changes to the payments data lane without a named approver.
• Mapped each change type to an approval requirement so policy and approval are enforced by the same engine.
• Grouped cross-account changes into deployment waves to review scope and health before apply.
• Enabled the audit trail with signed envelopes: plan, policy result, approver identity, and outcome in one record.

Guardrails: the AI proposes, the human signs

The AI assistant was scoped to investigation and proposal: it could read a change, flag a risk in the policy context, and draft the plan. It was never given the authority to approve or apply in the payments lane. Approvers are named humans, approvals are recorded, and every apply is bound to both.

Lessons learned

The rule that changed everything was tying approval to the plan inside the system, rather than to a ticket number outside it. The moment an approved plan and its apply live in the same graph, the audit question answers itself.

Second, start with the policy that matters most. We did not build a hundred policies; we built the deny rule for the data lane first, because that is where the regulator would look. Everything else followed from the same engine.

Third, do not over-rotate on the AI. In a regulated estate the assistant's job is to make the human's review faster, not to replace it. Keep it on investigation and proposals, and your reviewers will trust it, which is exactly what you want.