Why does AI make economies of scale harder to secure?

Why This Matters for Security Teams

AI changes the economics of production, and it changes the economics of attack surface with it. When organisations can spin up many bespoke models, workflows, and toolchains instead of one standard platform, security loses the leverage that comes from uniformity. The result is more identities, more secrets, more policy exceptions, and more paths for drift. That is why the old assumption that scale automatically improves control no longer holds.

Security teams also have to account for the fact that AI systems can reproduce risky patterns from the environments they are trained on, which makes governance of inputs and outputs part of the security problem. NHIMG has documented how quickly exposed credentials are targeted in the wild in the LLMjacking research, and the broader Ultimate Guide to NHIs — Why NHI Security Matters Now explains why machine-scale identity sprawl is now a first-order risk. The basic lesson is simple: more bespoke AI usually means less shared control unless governance is designed in from the start.

In practice, many security teams discover the failure mode only after a model, agent, or integration has already been granted broad access through an exception that was meant to be temporary.

How It Works in Practice

At scale, traditional security benefits from standardisation: a small number of approved systems, a narrow set of access patterns, and repeatable controls. AI pushes against all three. Different teams build different models, connect them to different data sources, and wrap them in different agentic workflows. That creates a distributed estate where a single control plane is hard to maintain and even harder to audit.

Current guidance suggests shifting from static governance to runtime governance. Instead of assuming that every workload will behave the same way, security teams should evaluate what the workload is trying to do at the moment of access, what context it is operating in, and whether the action is still justified. The NIST Cybersecurity Framework 2.0 is useful here as a broad control lens, while NHI-specific guidance points to the need for tighter identity and secret management around machine actors.

Operationally, that usually means:

• using workload identity for AI services and agents rather than shared human-style accounts
• issuing short-lived credentials per task instead of long-lived secrets that accumulate risk
• binding access to policy evaluated at request time, not to broad standing roles
• tracking each model, agent, and tool connection as a separate identity-bearing component
• revoking access automatically when the task ends or the context changes

This is where standards and implementation detail matter. NIST Cybersecurity Framework 2.0 supports the governance side, while the DeepSeek breach shows how fast exposed data and credentials can compound once an AI environment is reachable from the internet. These controls tend to break down when organisations let many teams ship AI integrations with ad hoc exceptions because the resulting access graph becomes too dynamic for periodic review alone.

Common Variations and Edge Cases

Tighter AI governance often increases operational overhead, so organisations have to balance speed of experimentation against the cost of control. That tradeoff is real, especially where product teams need frequent model changes or where each customer deployment is intentionally customised. Best practice is evolving, and there is no universal standard for how much variation is acceptable before security starts to fail.

In highly regulated environments, the safest approach is usually to constrain AI variability at the platform layer and allow customisation only through approved patterns. In fast-moving product teams, the better pattern may be to allow more variation but require strong guardrails: separate secrets per workload, narrow tool permissions, and continuous monitoring for unusual agent behaviour. The practical issue is not whether custom AI exists, but whether each new variant inherits the same identity, logging, and revocation discipline.

There is also an edge case around shared foundation services. Centralising model hosting can restore some economies of scale, but it can also create a high-value concentration point if one compromised identity can reach many downstream systems. That is why NHI guidance and AI governance need to be aligned, not treated as separate programmes. For a deeper view of the underlying NHI risk, see Ultimate Guide to NHIs — Why NHI Security Matters Now.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• Why do AI agents make non-human identity governance harder?
• What makes agentic AI an NHI governance issue?
• Why is NHI governance critical in the age of AI attacks?