A strong answer. “Not with a shared service account, for two reasons.

The first is attribution. With a shared account you cannot tell which agent, which user's request, or which run took an action, so you cannot investigate an incident and you cannot audit. Each agent needs its own identity, and every tool call needs to carry an agent identity, a run identifier and the initiating human.

The second is the confused deputy, which is the real problem. If the agent holds a broad credential and anything it reads can influence what it does — and with an agent reading tickets written by strangers, that is the design — then whoever wrote that ticket has effectively borrowed the credential. Rotation does not help, because the credential is being used as intended by an authorised process.

So the agent should act on behalf of the requesting user, with authority scoped per request and bounded in time. The established mechanism is delegation — OAuth token exchange, on-behalf-of flows — where the agent presents its own identity plus the user's context and receives a short-lived token carrying the intersection of both permissions. If the user could not update that record, neither can the agent acting for them.

Where there is no human in the loop — a scheduled agent — then it needs its own narrowly-scoped identity with a written owner, an expiry, and separation between the component that reads untrusted content and the one that holds write access.

And I'd want an inventory. Most organisations cannot list their non-human identities, and you cannot govern what you cannot enumerate.”