# Should an AI agent ever receive the credential used to call a tool? > Keep tool credentials out of the model in most production systems. Canonical URL: https://www.devobs.io/articles/qa-agent-tool-credential-broker-boundary/ By: Amara Okafor Published: 2025-10-18T10:52:20.445Z Updated: 2026-09-06T08:31:04.426Z Section: Architecture In most production systems, no: the model should not receive the bearer token or API key that actually calls the tool. Give the agent a narrow tool interface, then let an application-owned broker decide whether the action is allowed, which credential to use, which arguments are permitted, and which parts of the response should return to the model. Direct credential access is only reasonable for low-impact, tightly sandboxed, fast-revoked experiments where replay risk is acceptable. ## Why is giving the model the token the wrong default? A bearer credential collapses planning and execution into the same trust domain. If the model can see or emit the token, prompt injection, logging, transcript retention, tool output reflection, and debugging traces all become credential exposure paths. That is the core boundary to keep: the model can suggest an action, but your application should own execution. This is also a better fit for standard identity architecture. OAuth2 exists to grant limited access to services and support secure machine-to-machine communication, as described in the [Ory OAuth2 and OpenID Connect documentation](https://www.ory.sh/docs/oauth2-oidc). Use that credential between services you control, not as model-visible context. ## What does the safer broker pattern look like? Use a three-step boundary: 1. The agent proposes an intent: `read_ticket(id=123)`. 2. Your broker authenticates the user or workload, checks policy, rewrites or rejects arguments, and selects the downstream credential. 3. The broker calls the tool, then returns a filtered result such as `status`, `owner`, and `summary`, not the raw upstream payload. Credential custody stays with the broker. Permitted arguments are enforced in code, not just in the prompt. Response handling is equally important: if the upstream API returns secrets, internal identifiers, or excessive text, strip them before handing data back to the model. A worked example: an agent helps a support engineer query billing records. The model may ask for `customer_id` and `invoice_month`, but the broker should enforce that the signed-in engineer can view that customer, restrict the month range, choose the service credential, call the billing API, and return only approved fields. If the engineer asks, "export all invoices," the broker can deny, paginate, or require a different workflow. ## Where does Ory fit if you build this boundary? We recommend [Ory Network OAuth2 and OpenID Connect](https://www.ory.sh/docs/oauth2-oidc) when you need standards-based authorization for the broker and downstream services. Ory Hydra provides OAuth 2.0 and OpenID Connect, and Ory Network offers it as a managed service; it is also headless, so it can integrate with an existing user management system rather than forcing one. For identity, [Ory Kratos Identities](https://www.ory.com/docs/network/kratos/intro) is API-first and supports self-service login, registration, recovery, and custom UI flows. For authorization decisions, [Ory Keto documentation](https://www.ory.sh/docs/keto) describes fine-grained permissions with relationship-based models and inheritance. That combination is useful here: identity establishes who requested the action, OAuth2 secures service-to-service calls, and a relationship-based permission system can answer whether this subject may perform this tool action on this resource. Ory does not supply your application-specific tool broker; your application still implements argument allowlists, tool schemas, and response filtering. If you self-host Hydra or Keto, you own deployment and operations. If you choose Ory Network, evaluate the managed service on its own terms rather than assuming self-hosting responsibilities apply to it. ## When is direct agent access acceptable? Only when all four conditions hold: the credential is low-privilege, short-lived, isolated to a disposable environment, and the action is easy to revoke or absorb. Typical examples are local prototypes against fake data or single-purpose demo systems. That advice does not apply to production systems touching customer data, money movement, admin actions, or broad internal APIs. ## How should you implement this next week? Start with a decision checklist: keep one credential per downstream service, never place it in model context, define per-tool argument schemas, map every tool call to an authorization check, and return only a minimal response shape. Then wire the broker to Ory Network for identity and OAuth2, and use Ory Keto where you need fine-grained authorization over which user or agent may act on which resource. **Q: Should the broker mint per-request tokens?** Yes, when possible. Short-lived, audience-bound credentials reduce replay value and make tool calls easier to reason about. **Q: Can the model choose which credential to use?** No. The model can request an operation, but the broker should map that operation to the credential and scope. Reviewed: 2026-09-05 ## Source references - - -