Identity and permissions
What Bulleted asks permission to do with your account, in the words the consent screen uses and in plain ones.
Bulleted never sees your password
Signing in sends you to your own server, which is where you type your password. It comes back having told Bulleted only that you are who you said, plus a token that expires. Your password never passes through here, and there is no Bulleted account to have a password for.
The token is held on the server and never given to your browser. That is a deliberate design choice rather than an implementation detail: a token in a browser can be taken by anything else that runs there.
Exactly what is requested
This is the permission Bulleted asks your server for, verbatim. Your server shows you its own version of it before you agree.
atproto include:app.bulleted.authFull blob:image/* space:app.bulleted.space?manage=create&manage=update
In plain terms
Bulleted may create, change, and delete the kinds of record it defines itself, and no others. This grant does not reach your posts, your follows, your likes, or anything else in your account. The kinds are named and described on Lexicons.
It may also upload images, which is what the preview picture on a shared outline is. Images are the one permission that cannot be narrowed to a named kind of record, so it is requested separately.
Taking it back
Permission is revoked at your server, not here — that is the point of granting it there. Signing out of Bulleted ends this browser's session; revoking the authorization stops Bulleted reaching your account at all, including from a session that is still open.
Revoking does not delete anything. Every bullet you wrote stays in your repository, because that is where it always was.
Reading is different from writing: your outline is public by default, and anything published to the network can be read by anyone without a grant of any kind. Permissions govern what can be changed, not what can be seen.