Why do AI programmes often fail between innovation and control?

They fail when governance is either too heavy for delivery teams or too weak to constrain reuse. That creates workarounds on one side and unmanaged access on the other. A workable programme balances decision speed with clear accountability, so security does not become a bypass trigger.

Why This Matters for Security Teams

AI programmes usually stall at the point where experimentation becomes repeatable operations. Innovation teams want fast reuse of models, prompts, connectors, and credentials, while security teams need to know exactly who or what can access which data, for how long, and under what conditions. Once those controls feel slow, delivery teams route around them. Once controls are too loose, access spreads faster than governance can track. That is why the gap between innovation and control becomes an execution problem, not a policy debate.

This is especially visible when secrets, API keys, and service accounts are reused across pilots. NHIMG’s The State of Secrets in AppSec shows how fragmented secret management undermines centralised control, while the Ultimate Guide to NHIs frames the governance problem as identity sprawl, not just credential hygiene. The practical issue is that AI workloads are dynamic, so static approvals age badly. Current guidance also aligns with ISO/IEC 42001:2023 AI Management System Standard, which treats AI governance as an operating system for decisions, not a one-time checklist.

In practice, many security teams encounter unmanaged reuse only after a pilot has already been promoted into production.

How It Works in Practice

A workable programme separates the speed of delivery from the duration of access. Instead of granting broad standing permissions to teams or agents, organisations should issue just-in-time access, bind it to a specific task, and revoke it when the task completes. For AI systems, this usually means treating the workload itself as the identity primitive, then layering policy decisions on top of that identity at request time. That approach is more reliable than assuming a prompt, a repository, or a human owner can define safe access patterns in advance.

For autonomous and semi-autonomous systems, the core design choices are:

• Use workload identity, not shared secrets, to prove what the agent is.
• Prefer short-lived tokens and ephemeral credentials over static long-lived credentials.
• Evaluate policy in real time, based on the action requested, the data involved, and the runtime context.
• Limit tool access to the minimum set needed for the current objective, not the whole development lifecycle.
• Log agent actions in a way that connects the identity, the tool, the dataset, and the approval path.

This is where standards such as ISO/IEC 42001:2023 AI Management System Standard help define governance structure, while NHIMG’s DeepSeek breach analysis illustrates how exposed credentials and overbroad data access can turn model development into an incident path. The operational lesson is simple: if access outlives the task, the programme has already drifted from control into accumulation.

These controls tend to break down in environments that still rely on shared service accounts, manual approvals, and long-lived secrets because runtime context cannot be enforced consistently.

Common Variations and Edge Cases

Tighter control often increases operational overhead, so organisations need to balance assurance against developer friction. That tradeoff becomes more visible in fast-moving AI programmes, where teams may need temporary access to data, models, vector stores, or external tools within minutes. Best practice is evolving, but current guidance suggests that context-aware authorisation and ephemeral credentials are more sustainable than trying to pre-approve every possible action.

There are several common edge cases:

• Prototype environments often start with broad access and then forget to narrow it when they move into production.
• Multi-agent pipelines can inherit permissions from upstream systems, creating hidden privilege chains.
• Shared inference services may blur the boundary between one model call and another tenant’s data.
• Human-in-the-loop review can become a bottleneck if every low-risk action requires manual sign-off.

For that reason, governance should distinguish between high-risk actions that need explicit approval and routine actions that can be controlled through policy-as-code and short TTL credentials. The State of Secrets in AppSec is a reminder that fragmentation is a control failure even when each team believes it is being careful. The best answer is not more blanket restriction, but narrower access with clearer ownership and a faster revocation path.

Related resources from NHI Mgmt Group

• What is the difference between DSPM and runtime AI control in security programmes?
• Why do SOC 2 programmes often fail at evidence rather than control design?
• What makes agentic AI an NHI governance issue?
• What is the difference between attack surface management and NHI governance?