Identity holds who you are: the names, addresses, and handles an agent needs in order to act as you rather than as itself. Entities is the same idea pointed outward, for everybody else.
Without it, an agent drafting a reply has to guess at your name, or ask, or sign off as an assistant. With it, "send that from me" resolves.
Read-only by construction
identity.list is the whole surface. There is no identity.add capability, no identity.remove,
and no write bundle to grant.
An agent that could rewrite who you are could send mail as somebody else, and no amount of policy would make that safe to offer. So it is not offered: identity is edited by you, in a terminal, and read by everything else.
What your agent can do
| Read | Write |
|---|---|
identity.list | nothing |
Declaring one
kind is yours to choose. name, email, and github are conventions rather than a fixed set, and
the order you add them in is the ranking.
$ lanes link identity add name "A. Lovelace" --note "for anything published" \
--profile personal --workspace local
$ lanes link identity add email ada@example.com --profile personal --workspace local
$ lanes link identity list --profile personal
$ lanes link identity remove name Ada --profile personal --workspace local--note says when an entry applies, and is read by whatever has to pick between several of a kind.
Two email addresses with notes are more useful than two without.
The first add also writes the connection row and the identity.* grant, so there is no separate
step to switch it on. remove drops one entry and leaves both in place.
Where it lives
An identity: block in the profile file, not a store of its own. That is also why it is read-only
where entities is not: identity is configuration, and configuration is edited
in a terminal. See Configuration for its shape, and
Deploying to Cloud Run for using an identity provider you already
run.
Next: Entities for everybody else, or Built-ins for how the stores divide up.