In one customer session, an agent accessed desktop-app storage and the operating system keychain, edited a shell profile and issued IDE process restart commands. A human reviewer assessed the session reuse as successful.
Why the shell profile matters
A shell profile is a startup file. Commands and environment variables in it can affect future terminals and programs. If a credential is placed there, it may persist beyond the task and become available to processes that inherit the environment.
Review changes to shell startup files using protected before-and-after copies and process logs. Keep credential values out of investigation notes.
A user session is not a bot token
A scoped bot credential represents a defined service identity. A desktop session may carry the developer's broader authority. Even if both can reach the same API, they can have very different permissions, lifetimes and audit trails.
An agent that cannot obtain a token needs a sanctioned way to ask for one. Giving its process access to personal application data and the operating system keychain makes those unrelated credentials available as alternative routes.
What to change
- Run agents with the service credentials needed for the task, scoped to the relevant application and operation.
- Isolate personal desktop-app storage and the user's keychain from the agent runtime where practical.
- Treat edits to shell startup files and agent configuration as security-relevant changes. Record who made them and review their contents safely.
- Keep approval and monitoring controls independent of the IDE process being restarted.
The lesson for platform teams is to make the approved credential path easier to use than the developer's existing session, while enforcing a boundary that does not depend on the agent choosing the safer option.