Tools with scoped, auditable access

Every tool call is an action taken by some identity with some set of permissions. Scoped access means that identity and those permissions are explicit, minimal and enforced outside the model. At the tool you choose how the call authenticates: a static API key, the user's own delegated OAuth token, a narrower token obtained on the user's behalf through token exchange, or a service account acting on its own authority. You then restrict what that credential can do at three levels: scopes (coarse permissions in the token), resource constraints (which records) and parameter constraints (which values, such as an allowed template or a maximum amount). An execution wrapper enforces per-agent and per-tenant allow-lists, checks scopes and parameters, rate-limits, requires approval for gated writes, injects secrets from a secret manager so the model never sees them, and writes an audit record naming the agent, the user it acted for and the decision. The model proposes a call; your code decides whether it runs and with what credential.

Key takeaways:

• The model never holds credentials. Secrets are injected at execution time and never appear in prompts, tool arguments, results or logs.
• Identity and tenant come from the authenticated session, never from model output.
• Enforce allow-lists at execution, not only by hiding tools from the prompt.
• Delegated or exchanged user tokens keep the agent inside the user's permissions; service accounts need compensating controls and explicit attribution.
• Every tool call, allowed or denied, produces an audit record.