What do security teams get wrong about deploying AI safely?

Why This Matters for Security Teams

Security teams often misread AI deployment as a one-time release problem instead of an ongoing control problem. The real risk is not just model quality, but what the system can reach: data, tools, secrets, and downstream workflows. That is why the control plane matters as much as the model itself, especially when agents can act on prompts, chain actions, and persist access across sessions. NIST frames this as an enterprise governance issue in the NIST Cybersecurity Framework 2.0, but AI adds faster change and less predictable behaviour.

In NHI terms, the risk pattern often looks familiar. The State of Non-Human Identity Security found that only 1.5 out of 10 organisations are highly confident in securing NHIs, which reflects a broader gap in how machine identities are governed once they are live. That gap becomes more dangerous when AI systems inherit over-privileged tokens, stale API keys, or broad service roles. In practice, many security teams encounter abuse only after an AI workflow has already accessed sensitive systems, rather than through intentional pre-deployment assurance.

How It Works in Practice

Safe AI deployment starts by treating the model or agent as a workload that must prove what it is, what it may do, and under which context. That means shifting from static role grants to runtime decisions, and from long-lived credentials to short-lived access. The best-practice direction is still evolving, but current guidance suggests combining workload identity, policy-as-code, and just-in-time credential issuance so each task receives only the access needed for that task.

In agentic environments, this usually means issuing ephemeral tokens to the agent, binding them to a specific service, session, or action, and revoking them when the task completes. Cryptographic workload identity such as SPIFFE or OIDC-backed assertions is more reliable than assuming a named role is enough. Policy engines can then evaluate whether a request is safe based on intent, target system, data sensitivity, and current posture. This is where DeepSeek breach analysis is useful: it reinforces how quickly data exposure can scale when access paths are not constrained at runtime.

• Use workload identity for the agent, not shared human credentials.
• Issue short-lived secrets per task, not reusable credentials per environment.
• Evaluate access at request time with current context, not only at onboarding.
• Log every tool call, data fetch, and privilege elevation as a security event.

NIST Cybersecurity Framework 2.0 helps anchor governance, but AI systems need tighter runtime controls because behaviour can change after deployment. These controls tend to break down when a single agent can chain multiple tools across loosely governed SaaS services because the trust boundary is already fragmented.

Common Variations and Edge Cases

Tighter AI control often increases operational overhead, requiring organisations to balance safety against latency, integration complexity, and developer friction. That tradeoff is most visible in environments that rely on many vendor APIs, shared service accounts, or legacy automation where per-task credentialing is difficult to retrofit. In those cases, teams may need to phase in controls rather than attempt a full redesign at once.

There is no universal standard for agent authorisation yet, so organisations should avoid presenting any single pattern as settled. Some will start with coarse allowlists, others with context-aware policy engines, and others with gateway-based mediation. The important point is that pre-approved roles are usually too blunt for autonomous behaviour. The State of Secrets in AppSec is also relevant here because leaked or poorly rotated secrets are still a common failure mode when AI systems are wired into code, CI/CD, or operational tooling.

Edge cases include offline inference, air-gapped environments, and batch processing pipelines where runtime policy checks can be delayed or partially delegated. Even there, current guidance suggests using the shortest viable credential lifetime and preserving an audit trail of every access path. In practice, the hardest failures appear when teams assume a model sandbox is equivalent to a production boundary, especially once the agent can export data, call tools, or write back into business systems.

Related resources from NHI Mgmt Group

• What do teams get wrong about hybrid AI security deployments?
• What do security teams get wrong about self-service app requests?
• What do security teams get wrong about ITSM and access governance?
• What do security teams get wrong about role explosion?