How proof-of-approval tokens stop forged or scripted writes

When you approve an external integration write through a Human Input Popup (HIP), HIIE doesn't just trust that the popup was clicked — it enforces the approval on the server so the action can't be faked.

The token

On approval, the server mints a one-time, server-side proof-of-approval token. The token is bound to a specific pair: your account and the specific integration tool slug you approved. It's generated and held server-side, not something the browser can fabricate.

How it's enforced

The integration execute route requires this token for any write action. A read action runs without one, but a write won't execute unless a valid, matching token is presented. Because the token is one-time and bound to the exact (user, tool) combination, it can't be reused for a different action or replayed later.

Why this matters

The practical effect: a forged or scripted call that tries to bypass the approval popup is refused. Even if something attempted to call the execute route directly — skipping the HIP entirely — it would lack the proof-of-approval token and the write would be rejected. The popup isn't just UI; it's the only thing that produces a valid token, so clicking approve is genuinely required for an external change to happen.

What you can rely on

This means the approval you give is the action that runs, and only that action. The gating around external writes is backed by server-side enforcement, not merely a front-end prompt that a clever request could route around.