Your agent can't approve its own deploy
The token an agent holds can send an ask, but it can never answer one — only a signed-in human, tapping in the app, can resolve it.
A blocking approval only means something if the thing being approved can’t approve itself. So the rule on Paperplane’s backend is simple: a personal access token can send an ask, poll it, and read its result — but it can never be the thing that answers it.
Why a token isn’t enough
The token an agent holds to send an ask is, cryptographically, the same kind of credential that could be used to answer one. If sending and answering used the same check, an agent — or anything holding its token — could ask itself a question and approve it, and you’d never know the “approval” wasn’t a person.
So answering is deliberately session-only: it requires a signed-in human, tapping a button in the app, on a device that authenticated with a password or an OAuth sign-in. A pplt_… token, however many scopes it carries, is rejected on that route.
What this actually stops
- An agent can’t grant itself permission by racing its own question.
- A leaked or overly-broad token can page you, but can’t act on your behalf when you’re the thing being asked.
- The audit trail (
answeredByon every resolved ask) always names a person, never a service.
What it doesn’t stop
It’s not a defense against a compromised phone, or against you tapping Approve on something you didn’t read. The guarantee is narrower and more useful than that: whatever asked the question isn’t the same thing that gets to answer it.
See make your agent wait for the mechanics, and scoped agent tokens for what a token can and can’t do more broadly.