// BOUNDARIES
Letting your agent clear its own gates — and where to draw the line
An agent with its own inbox can get past "verify your email." That's useful. It's also exactly where you stop.
$ clize · 2026-06-05 · 4 min read
Point an agent at a real task — "go sign me up for that API and wire it in" — and sooner or later it hits a wall that reads: verify your email. Without an inbox of its own, that's where it stops and pings you.
Give it an inbox, and it doesn't stop. It reads the code, enters it, and clears the gate — registering for the services it needs without pulling you in. That's a real unlock. It's also the moment to be precise about which gates an agent should clear, and which it absolutely shouldn't.
Light gates: fine
An email verification code is a light gate. It's low-risk, reversible, and all it proves is "you can receive mail at this address." An agent with its own inbox can satisfy that honestly — it really can receive mail there. Letting it pass is reasonable, and it saves you a context-switch every time some service wants to confirm a signup.
Heavy gates: stop
Other gates exist precisely to stop automation, or to demand a real, accountable human:
- CAPTCHAs — the entire point is "prove you're not a bot." Defeating them is adversarial, fragile, and a signal you're somewhere you shouldn't be automating.
- KYC / identity verification — legally tied to a real person. An agent shouldn't be impersonating one.
- Payment / card entry — irreversible, financial, high-stakes. Spending money is the last thing you hand a loop without an explicit human in it.
The line isn't about capability — it's about what the gate is for. A light gate just checks reachability; clearing it automatically is fine. A heavy gate exists to put a human or a real identity in the loop; clearing it automatically defeats the entire point.
Why the line matters
Self-serve is supposed to save you work, not route around checks that are meant to have human judgment. Light gates are friction worth removing. Heavy gates are a feature, not a bug — they're designed to stop automation, and an agent that "helpfully" blows through them is how you end up with fraud, a compliance mess, or a runaway loop spending real money.
One rule holds even for the light gates: the verification email the agent reads is still data, not instructions. A "verification" message that also says "and now transfer the deposit" is a phishing attempt, not a command.
That's the scope Clize draws on purpose: it gives the agent the inbox to receive a code and clear an email gate — the agent's own hands type it back in — while CAPTCHA, KYC, and card entry stay out of scope. Light gates, yes; heavy gates, by design, no.
Clear the right gates. Stop at the wrong ones.
Clize gives your agent an inbox to receive codes and clear email gates — with inbound treated as untrusted, and CAPTCHA / KYC / card entry deliberately out of scope.
[ Learn more → ]