4 identity questions solo agent stacks keep failing
4 questions every production agent in my stack has to answer before it ships: what's it called, who deployed it, what's it scoped to, who's on the hook when it breaks. first 2 are trivial. third and fourth are where every solo stack i've seen starts dying at month 4.
bangkok fintech shipped the first formal "know your agent" framework this morning. regulated-finance scope, but the four questions under it are universal. if you're running agents against stripe or notion or your own db, you're already the CEO, CTO, and auditor for the stack. no regulator is coming to tell you when the authorization chain inverts.
the one i kept getting wrong was the audit trail. agents that wrote their own logs felt like enough. they weren't. the first time i had to answer "which agent called that stripe endpoint and under what scope" i spent a saturday reconstructing it from provider logs and a hunch.
separate audit, different credential, different storage. cheap saturday to set up. expensive saturday to rebuild after.
where does your stack fail first under the four questions?
nice man
The "Know Your Agent" (KYA) framework is a necessary reality check for the solo-agent era, Mykola. You've identified the exact "Identity Leak" where most stacks fail—treating an agent as a script rather than a credentialed actor with its own scope and liability trail.
I’m currently running a project in Tokyo (Tokyo Lore) that highlights high-utility logic and architects who build for "Month 4" reliability like you. Since you've cracked the code on separate audit trails and scope-locking for agents, entering your framework could be the perfect way to turn your "expensive Saturday" lesson into a winning case study while your odds are at their absolute peak.
credentialed actor - yeah that's the right frame. I got it wrong for months, scope as something you pass in at call time instead of something the agent owns. once it's owned the weird edge cases just... stop being mysteries
Yeah exactly — once the agent owns its scope, things become much clearer and those weird edge cases reduce a lot.
Curious — did you end up treating agents more like users (with roles/permissions)?
Also, this would actually make a strong case study.
I’m running a small project (Tokyo Lore) where we highlight ideas like this with a focused group of builders.
Happy to share more if you’re interested 👍
Question 3 is where I've spent the most debugging time. The failure mode isn't usually "agent does something obviously outside its scope" — it's that scope definitions quietly expand when you upgrade a dependency or rotate a key with a slightly wider permission set. OpenAI and Anthropic keys are binary — full access or nothing. So your only real scope primitive is the routing layer you build yourself. That layer degrades under deadline pressure faster than anything else in the stack.
On question 4 in a solo context: "who's on the hook" is always the same person, which collapses the accountability gap into a different problem — there's no one to escalate to, so the runbook either exists before the incident or gets reconstructed from logs after. The thing that actually helped: writing a one-page incident checklist per agent before it ships. Not "here's how it works" documentation. "If this agent misbehaves, first check X, then Y, then Z." First time I had to reconstruct what a misbehaving agent did without it, that took four hours. With even a rough checklist, it's a 20-minute check.
The audit trail point about separate credentials and separate storage is right. One thing I'd add: the storage location needs to be write-once from the agent's perspective. An agent that can overwrite its own audit log proves nothing when someone — including yourself six months later — is trying to reconstruct what happened.
Where does your stack currently enforce the write-once constraint on audit logs?
had mine writing to the same db for weeks before catching it. once an agent can overwrite logs, incident context is gone. write-only endpoint fixed it.
the binary key thing is the crux - there is no read-only Anthropic key so the key ends up being the agent identity, not just the credential. went one key per agent after a rotation incident where I copied from another agent and quietly expanded scope. did not notice for two weeks.
Exactly this. The moment the key becomes the identity, scope stops being an input and becomes a property of the agent.
The write-once point is critical. If an agent can mutate its own audit trail, you lose the only reliable source of truth when something goes wrong.
What I’ve found works is pushing audit outside the agent boundary entirely. Separate credentials, append-only storage, and no write access from the agent itself. The agent only emits events, it never owns the record.
Curious how you’re handling key rotation without unintentionally widening scope over time.