If an agent performs operations in enterprise systems, there is an identity behind those operations. Who that identity is remains one of the most skipped questions in production deployments.
01. Two Models
An agent either acts on behalf of the user or under its own service identity. In the first it's bounded by the user's permissions and traceability is natural. In the second there's a tendency to grant broad rights — and that's the source of risk.
02. The Broad Permission Trap
An agent running with administrator rights "to keep things simple" means full system access in a prompt-manipulation incident. Least privilege matters more here than in classic applications.
03. Tool-Level Boundaries
Grant permissions at tool level, not system level. Which tools the agent may call, and which records each tool may touch, should be defined separately.
04. Write Operations
Tools that create, update or delete records should require an approval step. Not exposing irreversible operations directly to an agent is the basic principle; money, contracts and outbound communication fall under it.
05. Time Limits
Don't give agent identities permanent keys. Short-lived, narrowly scoped credentials bound the damage if they leak.
06. Audit Trail
Every operation must record which agent performed it, on which user request and within which run. That chain is the only way to trace a problem back to its source.