Settings is not only your display name and the way out. Under it is a list of what happened to the account: codes sent, sign-ins that worked, codes that did not, lockouts, apps connected or declined or disconnected, keys created or revoked, an export, a close.
Each row can carry when, which surface, which client, and from which address.
Why the IP is there
Investigation is the point of a security ledger. Showing it only to an operator would mean you could not see a sign-in from a place you have never been. The first person who should notice that is you.
An administrator looking at the same account sees the same list. The assistant-facing admin tools omit the IP — that conversation is held by a third party.
Two tables, on purpose
Security events hold sign-in attempts, consents, connections, key changes, closure, export. Client IP. Ninety days, then they age out on write, so an account that never comes back still forgets.
The delivery trail holds what happened to a package. No address of any kind. No free-text column a sender chose. The privacy policy describes both halves.
A key name can contain an @, which is why audit detail is built so none of its structure comes from the person being audited. The export asserts it contains no "ApiKey" substring; enum names that would have said that were named for the key, not the credential type.
What is not written
An address with no account. The sign-in form pads both the request and the verify so you cannot time whether someone is registered. A row on the unknown path would undo that.
Reads are not audited — opening your inbox, searching, reading a package. The ledger stays scannable for the handful of things that changed something. Export is the exception, recorded for what it produces.
Nothing here is a session list you can remote-wipe. Disconnect an app, revoke a key, sign out of this browser. Those are the verbs. The history is how you notice you need them.
If a row looks wrong, change the keys and disconnect the apps first. Then ask if you want a person to look.