How can organisations reduce risk from AI tools without banning them?

Why This Matters for Security Teams

AI tools do not need to be banned to be dangerous. The real issue is uncontrolled access: broad prompt exposure, over-permissioned connectors, and unmanaged secrets can turn a productivity tool into a data exfiltration path. NHI risk rises quickly when tools inherit standing access that was never meant for autonomous use. Current guidance from NIST Cybersecurity Framework 2.0 and NHIMG’s Top 10 NHI Issues points in the same direction: limit what the workload can reach, and verify continuously rather than trusting a one-time approval.

The most common mistake is treating AI tools like ordinary SaaS accounts. They are often chained into chat, retrieval, code generation, ticketing, and cloud actions within the same workflow, which means a single weak integration can widen exposure far beyond the original use case. In practice, many security teams encounter this only after a sensitive dataset has already been indexed by an approved tool, rather than through intentional data-governance design.

How It Works in Practice

Risk reduction starts with controlled enablement: approve specific tools, define what data classes each tool may see, and separate low-risk assistant functions from high-risk actions such as file writes, API calls, or infrastructure changes. For AI agents and autonomous workflows, static RBAC alone is usually too blunt because behavior is goal-driven and can vary by task. Better practice is evolving toward intent-based authorisation, where access is decided at runtime based on what the tool is trying to do, what context it is operating in, and whether the action fits policy.

That usually means short-lived access, not standing privilege. JIT credential provisioning, ephemeral secrets, and workload identity help reduce blast radius because the tool receives only what it needs for the task and only for the duration of that task. If the workload is truly autonomous, the identity primitive should be the workload itself, not a shared human account. Technologies such as OIDC-backed workload tokens or SPIFFE-style identity can support that model when paired with policy-as-code and continuous evaluation.

• Classify allowed inputs first, then map them to specific tool scopes.
• Use JIT access for privileged integrations and revoke immediately after task completion.
• Separate read-only retrieval from write-capable actions and require explicit policy checks for each.
• Rotate and expire secrets aggressively so approval does not become permanent access.

This approach aligns with OWASP NHI Top 10 guidance on agentic application risk, and it fits the governance direction described in Ultimate Guide to NHIs — Why NHI Security Matters Now. These controls tend to break down when organisations connect an approved tool to legacy systems that cannot support per-request policy checks or short-lived credentials.

Common Variations and Edge Cases

Tighter control often increases workflow friction, so organisations have to balance productivity against governance overhead. That tradeoff is manageable for most teams, but there is no universal standard for every tool category yet. A low-risk summarisation assistant can often operate with coarse data boundaries, while an agent that can open tickets, run code, or call cloud APIs needs stronger separation, stronger approvals, and much shorter credential lifetimes.

There is also a practical distinction between tools that merely assist a human and agents that can act on their own. For autonomous systems, the main concern is not just access to sensitive content; it is the ability to chain actions in ways that were never explicitly approved. That is why policy must be expressed in operational terms: which data is in scope, which actions are permitted, what happens when the agent deviates, and how revocation is enforced. The DeepSeek breach is a reminder that exposure often comes from over-collection and over-retention, not just direct compromise, while the broader risk patterns in Ultimate Guide to NHIs — Key Challenges and Risks show why governance must cover both identity and data flow.

In short, banning AI is rarely necessary; unmanaged AI is. The practical target is controlled adoption with explicit scopes, short-lived credentials, and runtime authorisation that can keep pace with unpredictable tool behaviour.

Related resources from NHI Mgmt Group

• How can organisations reduce shadow AI risk without blocking adoption?
• Should organisations treat shadow AI as a security risk or an innovation issue?
• Why do AI tools create NHI governance risk?
• Why do collaboration tools create such a large secrets risk?