Give the agent its own identity

I wouldn't let an agent run on a person's full session, their browser profile or a long-lived API key. If it shares a human's credentials, you can't tell the agent's access apart from the person's own work, and those credentials usually carry a pile of permissions picked up over time for unrelated reasons.

Instead, create a dedicated workload identity for the agent, or for the specific workflow you're deploying. It should have a named owner, an environment, an expiry or review date and a written purpose. If two workflows need meaningfully different access, give them separate identities, even if they use the same model and interface.

You also want that identity to show up clearly in the source system's logs. A tool gateway can stamp each call with the task ID and the user who started it, but the underlying credential still has to identify the workload. Otherwise a direct call that skips the gateway can look like ordinary human activity.

Use short-lived credentials wherever the platform supports them. The runtime can swap its workload identity for a scoped token at the start of each task. Provider keys and refresh tokens belong in a secret manager. Keep them out of prompts, chat history, tool output and any configuration committed with the application.

Think about what happens when credentials go wrong, too. What should the agent report if a token expires halfway through a task, if the user loses access after the task has started, or if a secret gets rotated? Whatever the answer is, it shouldn't quietly fall back to a broader service credential, because that throws away the boundary you set up in the first place.

And check the effective permission, since the role name can be misleading. A role called reader might still be able to export whole collections, pull back deleted records or expose attachments that carry their own confidentiality classification. I'd make representative calls under the actual identity and look at what the source returns.