Tool Whitelisting & Credential Scoping
An agent may only invoke explicitly whitelisted tools, and each tool holds only the credentials it needs for its declared scope.
This page is the complete instruction page for one pattern called "Tool Whitelisting & Credential Scoping." It explains the problem this pattern solves, the idea behind the solution, when you should (and should not) use it, and what happens afterward — both the good effects and the costs.
This matters because building AI agents is not just about making them clever. It is also about making them safe and predictable. Following a well-tested pattern like this one helps avoid common mistakes, and shows you exactly which safety rules and regulations it connects to, listed under "Standards Mesh" on this page.
Context
Agents dynamically wired to new tools via MCP or similar protocols can acquire capability at runtime that was never reviewed. Credentials shared across tools leak authority.
Problem
Implicit tool access expands blast radius silently.
Forces
- Extensibility vs reviewability
- Dev velocity vs security discipline
Solution
Maintain an agent-scoped allowlist of tools and their credentials. New tool connections require a review step, not a runtime decision. Each tool's credential is scoped to the minimum permission set ("read customer X"), not the maximum the backend allows.
Applicability
- All enterprise agents
- MCP-connected agents
- Multi-tenant platforms
Anti-Patterns
- "The agent can call any MCP server it discovers"
- Shared service account across tools
Consequences
- +Capability growth is a reviewed event
- +Credential blast radius bounded
- −Onboarding friction for new tools