An agent that can call a payments API, a database, or an internal admin tool needs some credential to do it — an API key, a database connection string, a service-account token. The instinct most teams follow is the same one they'd use for a human developer: mint one strong credential, hand it to the agent's runtime environment, and let every tool call use it. That instinct is wrong for an agent in a way it is not quite as wrong for a human, because the agent's behaviour is steered by text an attacker can partially control. A credential scoped broadly enough to do everything the agent might legitimately need is also, by construction, broad enough to do everything a successful prompt injection might get the agent to attempt.
The failure mode is not exotic. A support agent holds a single API key with read-and-write access to the ticketing system because provisioning a separate read-only key felt like unnecessary process. A crafted ticket description instructs the agent, mid-conversation, to also close out three unrelated high-priority tickets and mark them resolved. The agent's reasoning was manipulated, but the actual damage — three tickets silently closed — was only possible because the credential in scope could do it. A read-only key would have turned the same manipulated reasoning into a failed API call and nothing else.
This lesson treats credential scope as a guardrail in its own right, independent of whether the model's behaviour was correct: the question is not just what the agent tried to do, but what it was ever capable of doing with the token it was holding.
Analogy🏏Cricket
🏏 Think of it like cricket: A national selection committee does not hand the same authority to a specialist death-bowling coach that it hands to the head coach. Rahul Dravid, as India's head coach, could set the batting order, manage team composition, and speak for the squad's overall strategy. A specialist bowling consultant brought in for a single tour, by contrast, is authorised to work with the pace attack on yorker execution and nothing else — he cannot rewrite the batting order, cannot speak to selectors about who gets picked, cannot access the medical staff's confidential fitness reports on players outside the bowling group. If that consultant's laptop were stolen the week before a series, the damage is bounded by what his role could ever touch: bowling plans, not selection strategy, not medical files. Just as the consultant's authority is scoped tightly to the one job he was brought in for, a credential handed to an agent should be scoped tightly to the one capability that agent's task actually requires. Just as a stolen laptop belonging to a narrowly scoped consultant leaks far less than a stolen laptop belonging to the head coach, a leaked or misused narrowly scoped token does far less damage than a leaked broad one, regardless of how the leak or misuse happened. The insight is that the damage a compromised credential can do is capped not by how careful anyone was, but by how narrowly the credential itself was scoped in the first place.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.