An agent with a shared key
is an unaccountable user
Most teams connect their first agent with a service account that has broad read access, because it is the fastest thing that works. It is also the thing that makes the second agent impossible to govern.
What a shared key costs you
A service account is a single identity used by everything that borrows it. When the audit log shows a query, it shows the account, not the agent, not the feature, and not the person whose request set it off.
That is tolerable with one integration. With four agents, two internal tools and a scheduled job all sharing it, the log stops being evidence of anything. You can prove a query ran. You cannot prove who ran it, and you cannot revoke one consumer without breaking the rest.
Onboarding an agent the way you onboard a person
A new analyst gets an identity, a role, access scoped to what the role needs, and an audit trail that follows them. None of that is exotic, and none of it is specific to humans.
An agent should get the same. Its own identity so its activity is attributable. Its own scope, usually narrower than a person's, because an agent needs exactly the fields its task requires and nothing adjacent. Its own limits, because an agent that loops will issue more queries in a minute than a person does in a month.
Acting on behalf of someone
The case that breaks naive setups is the agent answering a question for a specific person. The right result is the intersection: what the agent is permitted to do, restricted further by what that person is permitted to see.
If enforcement lives in the query path, that intersection happens automatically and the agent cannot leak a row the asker was never entitled to. If enforcement lives in the interface, the agent bypasses it entirely, because the agent is not using the interface.
The test worth running
Ask someone to produce, for last month, every query an agent made, the identity behind each one, and which of those touched a masked column. If that takes more than a few minutes, the agent is not governed. It is merely working.
Common questions
Is this not a lot of setup for one agent? For one, yes. The point is that nobody stops at one, and the cost of retrofitting identity across four agents already in production is much higher than doing it once at the start.
What about agents that only read public internal data? Those are genuinely lower risk, and scoping them narrowly is quick. The trap is that the definition of public internal data tends to widen quietly once the agent is useful.