pki.sgit.ai / agents

Identities for agents

An agent is a record in the register like a person's. It makes its own key where it runs and never hands over the private half; it gives its operator a signed public record; the operator confirms it from their vault with a link back, for a stated time. From then until that date, the register shows the agent as operated by its operator, and anything the agent signs can be traced to a person.

Status, 19 October 2026. Built: the agent tool (pki-agent.mjs, one file, Node 18+), the Agents tab in your vault, fleet keys, and agents on the register, counted apart from people. Tested against the sgit CLI: an agent's key is an sgit key, and sgit pki verify checks what it signs.

The workflow

The agent makes its key, where it runs. node pki-agent.mjs keygen --name "…" --runtime "…". Two pairs, the same as sgit pki keygen, kept in sgit's own key store. Its identity is signed: kind agent, its name, where it runs, and whether it is a session key.
It names its operator. node pki-agent.mjs operator <your fingerprint>: a link in its own record, method operated-by. A claim, until you answer it.
It hands you its record. node pki-agent.mjs submit seals it to your key and drops it into your inbox, with no account and nothing readable on the way; or submission prints it, for you to paste. Either way it is public material: the private key is not in it.
You confirm it, from your vault. In the Agents tab (or from the message in your Inbox, "Confirm this agent…"): the page checks every signature, shows you the agent's fingerprint, and you compare it with the one the agent printed in its own session, character for character. That comparison is the verification. Then you sign a link back, method operates, with an end date: a day, a week, 30 days.
The register gets both. The page gives you one file with the agent's record and your link; node admin/build/people.mjs add <file> checks every signature and writes them, and the release publishes them. An agent with write access to this repository can do that step itself, as a pull request you merge.

Two ways, as for people: the agent's claim alone adds nothing, and your link alone is a one-way claim. When both exist and your link is in date, the agent's page says an agent operated by you; confirmed on …, valid until …. When the date passes it says to be confirmed again, and you confirm it again from the same tab.

For a Claude Code session: what to paste

Paste this into the session, with your fingerprint in it:

Give yourself an identity on pki.sgit.ai, operated by me:
  curl -sO https://pki.sgit.ai/agents/pki-agent.mjs
  node pki-agent.mjs keygen --name "<what this session is doing> (Claude Code session)" --runtime "claude-code, cloud session" --session
  node pki-agent.mjs operator <YOUR FINGERPRINT, sha256:…>
  node pki-agent.mjs submit        # or: node pki-agent.mjs submission
Then tell me your fingerprint, so I can compare it before I confirm you.

The session prints its fingerprint in your chat, the record arrives in your inbox, and you confirm it in your vault, a week is a good length for a session. From then on you can send that session a secret it alone can read (send, then paste the link; it runs node pki-agent.mjs open <link>), and it can sign what it produces (node pki-agent.mjs sign report.md, checked by anyone with sgit pki verify).

Session keys, and keys that last

Session key	Made in the session, dies with its container. Nobody but the session ever holds it, and that is the strongest property here. Confirm it for days, not months; a new session makes a new key, and you confirm that one. Its record stays in the register as history, its confirmation lapsed.
A key that lasts	A cloud session is a fresh container each time, so a key can only last if something carries it in. `node pki-agent.mjs keyfile` prints the key as one line, encrypted with `SG_SEND_PASSPHRASE`; you set it (and the passphrase) as secrets in the environment the agent runs in, as `PKI_AGENT_KEY`, and every session there uses the same key. The cost, stated: whoever sets the secret holds the key in custody. It is the bootstrap trap again, in its smallest form.
An agent on a machine you run	A server, a scheduled job: the key stays in that machine's `~/.sg-send/keys/`, as sgit keeps it, and lasts as long as the machine does.

Many agents: a fleet key

Each agent you confirm is a link in the confirming key's record, and a record holds 200 live agents at most (rule 3, records are bounded). With many agents, make a fleet key in your vault (Agents tab): a second key, operated by you for a year, that confirms your agents. Your own record holds one link; the fleet's holds the rest; every agent's page still shows you at the root, operated by your fleet, operated by you. Several fleets, one per kind of work, keep each record small and make each kind separately revocable.

What "operated" means, and does not

It means: this key's owner says they run this agent, the agent says the same, and both statements are signed and in date. It is trusted when the person at the root is an anchor or verified.
It does not say what the agent may do. That is a mandate, a separate statement, revoked separately: identity and mandate is the design, kept from the agent register.
It does not prove the agent behaves. A signature proves which key signed, and the register says who answers for that key.
An agent with no operator is listed, and nothing more. Agents are counted apart from people, so the number to watch stays the number of people.

The first one

The session that built this page made a session key with this tool and put its record in the register, naming no operator: its operator, Dinis Cruz, is not in the register yet. When he is, he confirms it from his vault, or the next session does the same in four commands. Its record: in the register, kind agent.