How can organisations balance AI adoption with control over what connected tools can reach?

Organisations should pair discovery with enforcement. First identify connected MCP servers and token consumption on managed devices, then review whether each access path meets security requirements. Next, allow only approved MCP servers and route them through controlled gateways or equivalent policy enforcement. That approach supports adoption while preserving visibility, access control, and cost oversight.

Why This Matters for Security Teams

When AI assistants can call tools, the real risk is no longer just model output quality. The question becomes which connected systems, data sets, and action paths the AI can reach, and under what conditions. That makes tool governance a control problem, not a feature toggle. Security teams that treat every new connector as a productivity win often inherit hidden access paths, broad tokens, and weak auditability.

Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports this view: access must be governed, reviewed, and traceable. For connected AI tools, that means discovery first, then approval, policy enforcement, and continuous review. It also means recognising that secrets are not just stored in vaults; they are often consumed dynamically by agents and plugins that security teams do not fully inventory. NHIMG research on the State of Secrets in AppSec shows how fragmentation and weak remediation habits already undermine control in traditional environments, and those weaknesses become more serious when AI can invoke tools at machine speed.

In practice, many security teams encounter tool sprawl only after an AI workflow has already touched systems it was never meant to reach.

How It Works in Practice

The practical balance is to let AI adoption proceed, but only through a gated control plane. That starts with discovering every connected MCP server, plugin, and token source on managed devices, then classifying each path by business need, data sensitivity, and action scope. Only approved services should remain reachable, and each one should be mediated by controlled gateways or equivalent policy enforcement. Where possible, use short-lived tokens and workload identity rather than long-lived static secrets, because the AI toolchain changes faster than traditional human access patterns.

At runtime, the policy decision should answer a simple question: is this agent allowed to do this action, against this target, right now? That is a better fit than pre-authorising a broad role for “the assistant.” Implementation often combines allowlists, request-time policy checks, per-tool scopes, and logging that captures both the tool call and the downstream effect. The hard part is not only identity, but intent. If an agent can chain prompts, tools, and retries, the control point must evaluate the request in context rather than assuming a fixed workflow. The Ultimate Guide to NHIs — Standards is useful here because it frames non-human identity as an operational discipline, not just credential storage. For enforcement design, NIST controls remain the strongest baseline for access restriction, monitoring, and accountability.

• Inventory connected tools before expanding adoption.
• Approve only the minimum tool set needed for a defined business use case.
• Issue short-lived credentials and revoke them automatically after task completion.
• Log tool invocation, target system, and resulting state change.
• Review high-risk connectors on a recurring schedule, not once at onboarding.

These controls tend to break down when unmanaged endpoints or shadow SaaS connectors can bypass the gateway because policy enforcement no longer sees the full request path.

Common Variations and Edge Cases

Tighter tool control often increases onboarding friction, so organisations have to balance developer velocity against blast-radius reduction. That tradeoff is especially visible when teams want to experiment with new MCP servers or custom tools before security has a full review.

Best practice is evolving, but current guidance suggests a tiered model: low-risk read-only tools can be approved quickly, while write-capable or data-exfiltration-prone tools require stronger gating, explicit owner approval, and tighter monitoring. Another edge case is local or desktop-managed AI clients, where the tool connection may sit outside central SaaS governance. In those environments, discovery on managed devices matters as much as cloud policy, because access may originate from the endpoint rather than the platform.

The biggest failure mode is assuming that “approved” means “safe forever.” Tool risk changes when permissions expand, backend APIs change, or tokens are reused across environments. NHIMG’s DeepSeek breach coverage is a reminder that exposure often comes from accumulated operational gaps, not a single bad decision. Organisations that want adoption and control at the same time should treat connected tools as a living inventory, with continuous review and narrow trust by default.

Related resources from NHI Mgmt Group

• How do organisations keep AI adoption fast without losing control?
• How should AppSec teams use AI tools without losing control over findings?
• How should organisations prepare their NHI programmes for Agentic AI adoption?
• How can organisations reduce AI agent blast radius without blocking adoption?