Every tool call your model makes eventually needs to touch something that requires proof of identity: a database, a ticketing API, a customer's CRM record, an internal service behind a gateway. That proof is a credential -- an API key, an OAuth bearer token, a signed session -- and the moment you wire a tool up to a real system, you have to decide where that credential lives.
There is exactly one rule that matters here, and it is worth stating plainly before anything else: a credential should never be reachable by the model. Not in a prompt, not in an argument the model fills in, not in a result the model reads back. The model's job is to decide WHAT action to request. Your executor code's job is to hold the key and decide WHETHER, and how, to actually perform that action.
This single line -- the model requests, your code decides and authorizes -- is not a stylistic preference. It is the boundary that makes every other defense in this lesson possible: scoped credentials, per-user authorization, auditability, safe token rotation. Blur that line even once, and none of those defenses hold, because the thing they were all protecting turns out to already be sitting in a place the model can read it.
Analogy🏏Cricket
🏏 Think of it like cricket: When Jasprit Bumrah thinks a batter is out lbw, he doesn't personally consult the ball-tracking system and overturn the decision himself. He appeals. The on-field umpire hears the appeal and, if unsure, sends it upstairs. Only the third umpire, sitting in a separate room with access to Hawk-Eye, UltraEdge and the stump microphone, actually operates the technology and renders the final call. Bumrah never touches the review system, never sees its internal feeds, and never gets to keep a standing connection to it between deliveries -- he only ever gets a result: out, or not out. That separation is deliberate. If a bowler could operate Hawk-Eye directly, the temptation to lean on it, misuse it, or simply trust his own read over the data would be built into the game's structure. The BCCI's system is built so authority to act on sensitive tools sits with a designated official, not with whoever is asking. A model asking a tool to do something is Bumrah appealing. Your executor code, holding the credential and deciding whether to honor the request, is the third umpire. The model should never hold the key; it should only ever get the verdict. Everything about protecting credentials in a tool-using system follows from keeping that one line intact: the appealer names what he wants checked, and only the official holding the technology decides whether, and how, to check it.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.