Ask any platform team how a team gets more budget once they hit their limit, and a distressing number will describe, in essence, an email with a button in it. Someone clicks the button. Something happens. Nobody can later prove who clicked it, whether they were authorized to, or whether the email was still valid when they did.
This is fine right up until it isn't - usually during an audit, an incident retro, or the day someone asks "wait, who approved this $80,000 increase" and the honest answer is "a link, apparently."
The Shape of the Problem
Self-service budget systems need two paths, and only one of them is hard to get right. Path one - usage within the allocated limit - is easy: approve automatically, log it, move on. Path two - a request to exceed the limit - is where organizations reach for the fastest thing available, which is almost always some flavor of "send an email with a link, someone senior clicks approve."
The email-link pattern feels like it has an audit trail because it produces artifacts: a sent email, maybe a clicked-link timestamp in some logging system. But look closely at what it actually proves, which is nothing. It proves a link with a token in it was activated from some browser, at some point. It doesn't prove who was sitting at that browser. It doesn't prevent the email from being forwarded to someone with no approval authority. It doesn't stop a screenshot of the "approved" confirmation page from being passed around as proof of something that never actually happened through the real system. And critically, it creates no structured record you can query later - "show me every over-budget approval in the last quarter, grouped by approver" becomes an archaeology project through an inbox instead of a database query.
Why "It's Just for Convenience" Doesn't Hold For Us
We've heard the defense of the email-link approach plenty of times, including from ourselves early on: it's only for a fast-moving edge case - the budget override is rare, so why build real infrastructure for it? This gets the risk backwards. The common path (spend within budget) is low-stakes precisely because it's bounded - the worst case is capped by the limit itself. The override path is where the actual financial and governance risk concentrates, because by definition it's the moment someone is authorizing spend beyond the guardrail. That's exactly the path that most needs non-repudiation, not the one you can afford to wave through with the least rigor.
There's a second, quieter cost too: email approval flows train your organization to treat governance as theater. Once people learn that "approval" is a formality routed through whoever happens to be free to click a link, the control stops functioning as a control. It becomes a latency tax with no actual gatekeeping value - worse than having no process, because it looks like you have one.
What "Authenticated API/CLI-Only" Bought Us
The fix we landed on sounds almost boringly simple: route the override path through an authenticated call - a CLI command or API request tied to a real, verifiable identity - that writes a structured record as a side effect of succeeding, not as an afterthought logged by whoever remembers to.
Concretely, this gets you three things an email link structurally cannot:
- Non-repudiation. The call is authenticated with the approver's actual credentials (SSO token, service identity, whatever your platform already trusts elsewhere). There's no "someone with access to my inbox" ambiguity - the identity that approved the override is the identity that authenticated the call.
- A structured, queryable record. Every override becomes a row: who, what resource, previous limit, new limit, timestamp, reason (if you require one - you should). This is the difference between "let me check the inbox" and "let me run a query" when finance asks for a quarterly override report.
- Enforceable authorization scope. An API/CLI path can check "is this identity actually allowed to approve overrides for this team/environment" before doing anything. An email link generally can't - by the time someone's clicking it, you're trusting the email system's delivery, not your authorization system's decision.
Imagine a scaling logistics company where budget overrides used to go through a shared "platform-approvals" inbox. During a routine review, they discovered two overrides approved by someone who had left the company three weeks earlier - their email forwarding was still active, and nobody had thought to check. Moving the override path to an authenticated CLI command (platform budget override approve --resource X --new-limit Y, gated by the same SSO the rest of the platform already used) turned "we think this was fine" into "here is the exact identity, timestamp, and justification on record."
Pitfalls
The most common failure when teams do build this correctly is making the override path so procedurally heavy that people route around it - reintroducing the email thread as a shadow process because the "real" path takes three days and five approvals. An authenticated audit trail should be strict about who can approve, not slow about how. If your legitimate override path is slower than sending an email, you've just guaranteed the email thread survives anyway, quietly, alongside the system you built to replace it.
The second pitfall: logging the override but not logging the reason. A timestamp and an approver identity tell you who's accountable; they don't tell you whether the decision was sound. We require a short justification field now - a mandatory one-liner - though we'll admit we're not fully sure how much people actually read it back versus just filling it in to get past the prompt. If you've found a way to make that field genuinely useful rather than a rubber stamp, we'd like to know.
Once you've got budgets and approvals nailed down, the next governance question is usually "okay, but what actually stops two people from mutating the same resource at the same time?" That's the elegant trick - and the trap - we cover next: Using Your Workflow Engine's Execution ID as a Concurrency Lock.
Suggested hashtags: #EnterpriseAI #AIInfrastructure #AIPlatform #AIGovernance #PlatformEngineering #Compliance #Auditability #SecurityEngineering #AccessControl