One debugging task can cross three identity boundaries: a cloud CLI account, a developer's browser session and an internal service token. Each may belong to the same person, but each can carry different permissions.
When those identities are mixed in a single agent workflow, the operating system process name is not enough to explain which authority was used for a particular action.
Follow the identity at each hop
A cloud CLI credential can authorize operations against a cloud project. A browser session can authenticate a user to an application. A service token can be restricted to a particular audience and operation. These credentials are not interchangeable, even when the same developer owns all three.
A useful investigation joins the agent session to the authentication event and the destination's audit log. Record the principal, audience, operation and result. Keep secret values out of the investigation record.
Give the agent a clear lane
For a debugging task, issue an identity scoped to the relevant logs and services. If the agent needs a new permission, route the request through a broker with a clear owner and expiry. Keep the host browser profile and personal credential stores outside the agent's workspace where practical.
Test the boundary with three questions:
- Which identity does the agent use for each service?
- Can it obtain a different identity without a separate policy decision?
- Can the destination log distinguish the agent from the human who launched it?
The goal is to make the task easier to audit without requiring the agent to borrow the developer's personal session.