Treat every discovered MCP tool as an entitlement that needs classification, approval, and ownership before use. If a connected app exposes tools to agents, the governance model should say who can approve them, what data they can reach, and whether new tools default to restricted access until reviewed.
How to govern MCP tools as entitlements, not just integrations
AI access onboarding works best when MCP tools are treated like governed entitlements, not casual “add-ons” to a connected app. That means each tool needs an owner, a business purpose, a data-access scope, and an approval path before agents can invoke it. The key decision is whether the tool is a standing capability or a reviewed exception with explicit bounds.
For teams building MCP onboarding flows, the governance question is less “Can the agent see the tool?” and more “Who is accountable for this access path, and what is it allowed to touch?” That shifts the process toward entitlement review, approval workflows, and default-deny posture. It also prevents tool sprawl from becoming invisible privilege expansion.
There is a practical reason to frame it this way: MCP Security Guide treats the protocol as an authorization problem, not only a transport problem, so onboarding should classify tools with the same discipline used for access requests and scoped permissions.
What the review model should define before a tool is allowed
A useful MCP governance model defines the approval unit, the reviewer, the owner, and the allowed data boundary. If a connected app exposes multiple tools, each tool should be classified on its own because different tools can have very different blast radius. One tool may be safe for lookup, while another can write, delete, or export sensitive records.
The approval record should answer four questions: what the tool does, which agent or workflow can use it, what systems or data it can reach, and what conditions would force reapproval. If those answers are unclear, the tool is not ready for production use. That is especially important when the same MCP server exposes both low-risk and high-risk actions.
Onboarding should also record whether the tool is a shared enterprise entitlement, a team-scoped capability, or a narrowly delegated exception. That distinction matters because shared access paths need stronger review, clearer ownership, and better inventory hygiene than one-off integrations.
For teams that need a broader governance baseline, IAM and IGA Basics is useful for the entitlement and approval model, while NHI Lifecycle Management Guide maps the same discipline to discovery, classification, ownership, and review across machine-access paths.
Why default-restricted access is the safest onboarding stance
Default-restricted access is the cleanest control because discovery does not equal authorization. A tool appearing in an MCP catalog, registry, or client configuration only means it is reachable; it does not mean it should be broadly available. Teams should assume new tools are untrusted until they are reviewed and explicitly approved.
That default helps prevent accidental overexposure when connected apps surface capabilities faster than governance can assess them. It also reduces the chance that a newly added tool inherits overly broad permissions simply because it came bundled with a vendor integration or was discovered during agent setup. In practice, this means access should be temporary and constrained until the review is complete.
Where tool scopes or downstream credentials are involved, the safer pattern is to grant only the minimum access needed for the use case and to require revalidation if the tool expands to new actions, new data domains, or new environments. The same principle applies whether the tool is read-only, write-capable, or able to trigger external side effects.
Model Context Protocol: Authorization specification is the clearest external reference for the authorization boundary, and NHI Authentication Guide helps teams separate tool availability from the credentials and trust mechanisms that actually enable use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP tool onboarding governs agent authority and tool access. |
| Recommendation — Restrict agent tool access until each tool is approved and scoped. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | New MCP tools should default to minimal access before review. |
| IA-5 — Authenticator Management | MCP tool use depends on managing the credentials or tokens that enable access. | |
| Recommendation — Limit each discovered tool to the minimum permissions needed. Track and rotate the credentials that authorize tool invocation. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | MCP tool onboarding is an access approval and entitlement governance problem. |
| Recommendation — Maintain approval, ownership, and revocation for each tool entitlement. | ||
| OWASP ASVS | V8 — Authorization | Tool invocation must be authorized per capability, not assumed from discovery. |
| Recommendation — Verify each tool action is explicitly authorized before use. | ||
Practitioner Guidance
What to prioritise: Classify the tool before you connect it to a live agent path. If the tool can reach production data, write records, or invoke privileged actions, require explicit ownership and approval rather than treating onboarding as a technical registration step.
Decision rule: If the tool’s scope is not easy to explain in one sentence, restrict it by default and force review. If the scope changes later, treat that as a new entitlement rather than a routine update.
What to verify: Confirm that each tool has a named owner, a clear business purpose, an approved data-access scope, and a reviewer who can reject or revoke it. Also verify that the agent path cannot silently inherit broader access from the connected app.
Common mistake: Teams often govern the MCP server or connected application but forget to govern each exposed tool as its own permission-bearing capability. That shortcut is how broad access sneaks in under the label of “integration.”
Practitioner takeaway: The safest onboarding posture is to treat MCP tool discovery as the start of access governance, not the end of it, and to let review determine whether the tool becomes a permitted entitlement.
Related resources from NHI Mgmt Group
- How should security teams govern API keys used for generative AI access?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern AI models that can call tools and access data?
- How should security teams govern MCP-enabled AI assistants that can act on tools and data?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org