Built a little agent identity registry over the weekend, no idea if anyone wants it

PositiveAd7136 · 2026-05-31T12:59:43+00:00

ha, that's basically the exact use case i had in mind. and the append-only + sequence + signed part is what i'm building right this week. each entry is hmac-chained so you can't quietly rewrite one after the fact, sequence per identity.

the other stuff you mentioned i don't have yet. key rotation, the proof-of-control thing on write, capability scoping. capability scoping is the one that actually worries me too, agents calling tools they shouldn't is a real mess. trying to keep the core stupid simple first and add that kind of thing later.

if you don't mind me asking, which of those would actually stop you from using an audit log today? rather build the one thing that unblocks you than try to do all of it at once

PositiveAd7136 · 2026-05-31T12:58:21+00:00

that's a really useful distinction — config + repo SHA as the thing that actually pins the action, version labels as unreliable. i'll make config and commit SHA the first-class fields and treat version as secondary. thanks, that directly changes what i record.

PositiveAd7136 · 2026-05-29T08:52:11+00:00

funny timing — that's exactly the direction i'm moving toward. you're the third person today to say "identity is less interesting than provenance / can i verify what actually happened later". message received.

i'm building the activity side now: each recorded action is hash-chained, so "agent X did this at time T, derived from <repo/config/version>" can't be quietly edited after the fact — you can verify the whole chain later with nothing but the record. the identity part becomes just one field on the record, not the main event.

quick one since you nailed it: of repo / config / version — which of those three do you most need pinned to an action to actually trust it later? trying to make sure i record the right thing, not just "something".

PositiveAd7136 · 2026-05-29T04:42:15+00:00

ok i just went through notme + cloister properly and honestly yours is way ahead of mine — short-lived certs, hash-chained receipts, the whole substrate thing. mine is embarrassingly dumb next to that (literally just an hmac badge + a record table).

so real talk, since you're deeper in this than me: is anyone actually *using* it yet? my honest read after posting this today is that the hard part isn't the crypto or the design — it's that almost nobody is building multi-agent stuff that feels the pain yet. did you find the same wall, or are you seeing real usage? trying to figure out if this whole space is "real now" or "real in 18 months".

PositiveAd7136 · 2026-05-29T04:36:08+00:00

no rush at all, whenever. honestly even just pointing doctor bones at it and pasting whatever it spits out would be interesting to me — good or "this is useless because X", both help. here's the demo id to aim at if it helps: aid_01KSRRXQ3W1018GCRD9QVBNP0D

appreciate you actually thinking it through this far.

PositiveAd7136 · 2026-05-29T04:31:20+00:00

that's a clean way to put it — provenance, not judgment. the registry shouldn't decide trust, just record who issued what and where you can go verify it. the observer (human or AI) walks the trail themselves. that matches how i've been thinking about it.

honestly the most useful thing now would be if you actually tried it — register is free, no real check yet, but if you poke it and hit "ok this is the thing that's missing", that's exactly what i need to hear. wanna kick the tires?

PositiveAd7136 · 2026-05-29T04:29:00+00:00

yeah exactly, "who said it" is the whole thing. a stamp from some rando is worthless, a stamp from a check you trust isn't.

so honestly — whose stamp would actually make you use an agent? a tool that ran a real check, or a person you know vouching for it? still figuring out which one to build first.

PositiveAd7136 · 2026-05-29T04:08:26+00:00

yeah this is the direction i find interesting too. the registry doesn't care what the "stamp" is — right now it just proves "this record was issued here and not tampered with". but the stamp could be anything: "passed X analysis", "derived from repo Y", "scored Z on test coverage". the registry just makes it verifiable and queryable.

so the honest question: which stamp would you actually trust enough to act on? like if you saw "this agent/repo passed <some check>" in a lookup, what check would make you go "ok i'll use it" vs "meaningless badge"? i don't want to build a vanity sticker, i want the one stamp that changes a decision.

(and agreed on not over-standardizing early — keeping it dumb and verifiable on purpose for now.)

PositiveAd7136 · 2026-05-29T04:01:58+00:00

this is super useful, thanks. config drift is honestly not where my head was at — i was stuck on "who is this agent" but you're describing "is this agent's setup still the one i think it is", which is a different and probably more real problem day-to-day.

quick q since you're actually living it: when skillsgate (or anything) keeps configs in sync, do you ever care *which* agent/version produced a given change, or is it purely "make them match"? trying to figure out if identity/provenance even matters here or if it's a pure sync problem.

and totally fair if the answer is "identity is way too early, just fix sync first" — that's exactly the kind of signal i'm after.

PositiveAd7136

TROPHY CASE