An AI agent should get its own scoped credential for each system it touches, not one identity that spans all of them. A single cross-system identity is easier to set up and easier to manage. It also means one leaked token opens your CRM, your accounting system and your ticketing tool at the same time.
The cost of the per-system approach is real: more credentials, more rotation, more things to break at 2 a.m. That cost is manageable, but only if you stop handling credentials by hand. This article covers what the trade-off looks like at a mid-size company and where a broker or vault earns its place.
A single identity turns one leak into a skeleton key
Picture a 150-person company with a CRM, an accounting system and a ticketing tool. The agent’s job is to read support tickets, check the customer’s account status, and draft a billing adjustment for a person to approve. The quick way to build it is one service account, one token, and one config file that all three integrations read from.
It works in the demo. Then the token ends up in a debug log, a pasted config or a contractor’s laptop. Whoever holds it can read customer records, see invoices and edit tickets, because the token was never scoped to the task. It was scoped to whatever was easiest to set up.
There is a quieter problem too. When all three systems see the same identity, none of them can tell which request was the agent doing its job and which was someone else using its token. Each system’s own access log stops being useful evidence. We covered the downstream effects in what breaks when AI agents share logins, and the cross-system version is the same failure with a larger blast radius.
Per-system credentials make the blast radius a design choice
With a separate credential per system, you decide in advance what each one can do. The CRM credential reads accounts and contacts. The accounting credential reads invoices and can create a draft credit note, but cannot post it. The ticketing credential reads and comments on tickets, and nothing more.
Now a leaked ticketing token exposes tickets. It doesn’t expose the ledger. That is the Identity principle in practice: the agent has a distinct, scoped identity in every system, and each system can see it, restrict it and revoke it independently. It’s also what makes the Governance layer workable. An approval policy can only say “the agent may draft but not post” if the underlying credential is actually unable to post.
It also stops the agent’s access from growing unnoticed. A cross-system identity tends to collect permissions, because the next integration is always easier to add to what already exists. We described that pattern in why an agent ends up with admin access to the CRM.
The rotation burden is real, and it’s why people give up
Three credentials means three rotation schedules, three expiry dates and three places a stale secret can sit. Each vendor has its own token lifetime, its own scope model and its own way of failing when a token expires. Someone has to own all of that, and in most mid-size companies that someone doesn’t exist.
The usual result is that per-system credentials get created once, never rotated, and stored in the same config file the shared token would have lived in. That is the worst outcome. You pay the management cost of separation and keep the exposure of a single secret.
So the position is not simply “use more credentials.” It is that you can only afford separate credentials if issuing, storing and rotating them is automated.
A broker earns its keep at the third system
A broker, or a vault with dynamic secrets, sits between the agent and the systems. The agent never holds a long-lived secret. When it needs to act, it asks the broker, which checks the request against policy and hands back a short-lived, narrowly scoped credential for that one system. Rotation becomes the broker’s job, not a calendar reminder.
A broker is also a natural place to enforce policy and write the record. Every credential issued is tied to an agent, a system, a scope and a reason, at the moment it happens. That supports the Audit principle, because “which agent touched the ledger, and under what rule” has an answer that doesn’t depend on reconstructing it from three vendors’ logs. It is the difference we described in why “we have logs” isn’t an audit trail.
In our deployments the broker runs inside the customer’s own infrastructure, and the secrets never leave it. That matters for the same reason the rest of the design does: the agent’s access shouldn’t depend on anyone else’s environment.
For a single system with a single agent, a broker is overkill. A scoped credential and a rotation reminder is fine. By the second or third system, the manual approach starts to fail, and that is when the broker pays for itself.
Where it still gets hard
Not every system supports the scoping you want. Some SaaS tools offer only coarse roles, such as “admin” or “user,” and nothing in between. In that case a per-system credential can still be far too broad, and you compensate by putting a narrower interface in front of it. That is more engineering, and it adds a component that can itself fail.
A broker is also a new single point of failure and a new high-value target. If it goes down, the agent stops working. If it is compromised, the attacker has a path to everything it can issue. You have to protect it more carefully than any individual integration, and you have to decide whether the agent fails closed or limps along when the broker is unavailable.
Scope design takes judgment too. Too narrow, and the agent hits permission errors on routine work and people grant exceptions. Too loose, and the separation is cosmetic. We start agents with read-only access and widen it against observed need, which is slower than granting everything up front. It is also how you learn what the real scopes should be.
The question to sit with
If the token your agent uses today were posted in a public channel this afternoon, how many systems would you need to check, and could you revoke access to one without breaking the other two? If you aren’t sure, a short Book a diagnostic call is a reasonable way to find out what the agent can actually reach.