Give the agent its own identity

An agent should not inherit a person's full session, browser profile or long-lived API key. Shared human credentials make the agent's access hard to distinguish from the person's work, and they usually carry permissions accumulated for unrelated reasons.

Create a dedicated workload identity for the agent or for the specific deployed workflow. That identity needs a named owner, an environment, an expiry or review date and a documented purpose. If several workflows have materially different access, separate their identities even when they use the same model and interface.

The identity should be recognisable in source-system logs. A tool gateway can add the task ID and invoking user, but the underlying credential still needs to identify the workload. Otherwise a direct call outside the gateway may look like ordinary human activity.

Use short-lived credentials where the platform supports them. The runtime can exchange its workload identity for a scoped token at the start of a task. Keep provider keys and refresh tokens in a secret manager, not in prompts, chat history, tool output or configuration committed with the application.

Credential handling needs a failure path. Decide what the agent reports when a token expires halfway through a task, when a user loses access after the task starts, or when a secret is rotated. Silent fallback to a broader service credential defeats the original boundary.

Review the effective permission, not only the role name. A role called reader may still export entire collections, retrieve deleted records or expose attachments with a separate confidentiality classification. Test representative calls under the actual identity and inspect what the source returns.