[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-agent-identity::en":3,"gloss-cluster-agent-identity::en":23,"gloss-next-agent-identity::en":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"agent-identity","agents","Agent Identity","Agent identity is the question of whose credential an agent acts under, and in most implementations it is answered by default: the agent reuses the session of the person who started it, or a long-lived key that already existed for something else. Both are convenient on the first day and both remove the ability to answer any useful question afterwards.\n\nThree things break when an agent borrows a person's identity. The audit log records the person, so actions nobody took appear under their name with nothing to distinguish them from actions that person genuinely performed. The permission set is the person's too, so the agent inherits everything that human can reach rather than the narrow slice the task needs — and the more senior the person who started it, the worse that is. And revocation becomes all-or-nothing: stopping the agent means disabling the employee.\n\nA distinct identity fixes all three at once. The agent gets a principal of its own, with its own credential, its own permissions and its own lifecycle, and a name that will still mean something to whoever reads the log a month later. This costs very little to set up at the start and is close to impossible to retrofit, because once the borrowed-credential version has been in production for a while nobody can say which past actions were automated and which were not.\n\nDelegation is the case that needs thought, because a great deal of agent work genuinely is done on a person's behalf and should be bounded by what that person could do themselves. The durable pattern records both facts rather than collapsing them into one: which agent acted, and on whose authority it was acting. An entry carrying only one of the two answers half of every question that gets asked after something goes wrong.\n\nThe lifecycle is where this rots quietly. Machine credentials outlive the projects that created them, they are rarely rotated because nothing forces the issue, and they usually sit outside the joiner-mover-leaver process that governs human accounts. Every non-human identity needs a named human owner, an expiry, and a place in the same access review as everybody else — otherwise the count of credentials nobody can attribute only ever goes up.","Agent identity is whose credential an agent acts under. Borrowing a person's session breaks the audit trail, the permissions and the ability to revoke.",null,[11,14,17,20],{"slug":12,"name":13},"api-key","API Key",{"slug":15,"name":16},"audit-log","Audit Log (Audit Trail)",{"slug":18,"name":19},"least-privilege","Principle of Least Privilege",{"slug":21,"name":22},"service-account","Service Account",[24,28,32,35,38,41,44,47,50,53,56,59],{"slug":25,"category":5,"name":26,"updated_at":27},"acceptance-criteria","Acceptance Criteria","2026-09-08T21:32:37+00:00",{"slug":29,"category":5,"name":30,"updated_at":31},"agent-budget","Agent Budget","2026-09-08T21:32:36+00:00",{"slug":33,"category":5,"name":34,"updated_at":31},"agent-checkpointing","Agent Checkpointing",{"slug":36,"category":5,"name":37,"updated_at":31},"agent-handoff","Agent Handoff",{"slug":39,"category":5,"name":40,"updated_at":31},"agent-loop","Agent Loop",{"slug":42,"category":5,"name":43,"updated_at":31},"agent-memory","Agent Memory",{"slug":45,"category":5,"name":46,"updated_at":31},"agent-sandbox","Agent Sandbox",{"slug":48,"category":5,"name":49,"updated_at":27},"agent-simulation","Agent Simulation",{"slug":51,"category":5,"name":52,"updated_at":31},"agent-trajectory","Agent Trajectory",{"slug":54,"category":5,"name":55,"updated_at":31},"agentic-rag","Agentic RAG",{"slug":57,"category":5,"name":58,"updated_at":27},"approval-fatigue","Approval Fatigue",{"slug":60,"category":5,"name":61,"updated_at":31},"computer-use","Computer Use"]