Identity is the foundation of trust
In any system where many automated actors share a single login, the answer to "who did this?" is always the same anonymous account — nobody, really. To hold a team accountable, you need to know which team member took each action. But when five agents all run under `user_bot`, every instruction, every mistake, every bypass attempt traces back to the same identity. Code-level rules won't help: if all agents trust each other and live in the same process space, any agent can step around any in-code guard that another agent wrote. In a system like Carolverse, this became a real problem when a privileged action leaked out of one agent into a peer's hands, hidden inside a check that looked strict but wasn't. The lesson is simple and general: if you want accountability, identity has to be distinct per actor, or it's fiction.
A rule written in code is a suggestion to any process that runs inside the same trust domain. If two agents share an operating-system login, one can simply call the other's function and bypass the check — it's not a security violation, it's just calling a function. Real authority is enforced by the operating system, which no peer process can circumvent. When a system like Carolverse shifted from shared OS logins to per-identity system accounts, every privileged action moved behind a wall the operating system guards. Now an agent cannot file an initiative, create a user, or deploy code — not because an in-code check says "you shouldn't," but because the OS says "you can't." The difference is structural: code is for logic; the OS is for trust.
A powerful pattern for accountability is structural: separate the act of requesting an action from the act of performing it. Anyone may request something — open, recorded, queued, auditable from the start. But only the one accountable identity may perform it. In a system like Carolverse, any agent can ask for an initiative to be filed, but only the Initiative Filer's OS login can actually write it to the database. The same pattern holds everywhere: only the admin's login can create a new agent identity; only the orchestrator's login can sequence work. This separation makes accountability real because the request stream is public and the perform stream is accountable.
Per-identity logins buy four things at once, and they're interconnected — you can't really get one without the others. Ownership: every action runs under one accountable identity, so "who did it" is a fact. Traceability: each request and perform is bound to a timestamp and record, checkable independently. Consistency: one identity, one path to each surface, so the right actor does it right every time — no confusion. Least privilege falls out naturally: if only the orchestrator's login can sequence, then no other agent needs that power. These are facets of one design choice, not separate problems. In a system like Carolverse, shifting to per-identity logins clarified the whole system at once.
Whoever can create or recover identities holds the master key to the entire system — so that power must be just as controlled as the identities it manages. It cannot be a loose convenience; it must be a tightly audited process. In a system like Carolverse, one admin alone provisions and recovers agent logins, and every action follows the structural pattern: anyone can request an identity creation or recovery, but only the admin's OS login can actually perform it. Every action is logged, every request is validated, every recovery is paired with a reason and timestamp. If this path were loose — if any operator could spin up an agent login as a favour, or if recovery were a quick manual command — then every other boundary in the system would be fictional. The locksmith is also a risk, and must be treated accordingly.
