Why do traditional security tools miss many AI security risks?

Why Traditional Security Tools Miss AI Risk

Traditional controls were built for systems with stable identities, predictable sessions, and traffic that can be classified by known signatures or fixed policy. AI workloads break those assumptions. Prompts change intent at runtime, agents call tools, memory persists across steps, and outputs can trigger new actions. That means the risk is not just the model itself, but the identity, permissions, and data flows around it.

Security teams also lose visibility when AI components blend human input, service accounts, and external APIs into one workflow. A firewall can see a request, but it cannot reliably judge whether a model is about to exfiltrate a secret, escalate privilege, or chain actions through an MCP-connected tool. Current guidance suggests looking at the whole control plane, not just the model, as explained in OWASP NHI Top 10 and the CSA MAESTRO agentic AI threat modeling framework.

In practice, many security teams encounter AI misuse only after an agent has already been granted broad access and started interacting with real data.

How It Works in Practice

Effective AI security starts by treating each agent, connector, and workload as an identity-bearing entity, not as a neutral application feature. That shifts the design toward workload identity, short-lived credentials, and runtime authorization. Instead of handing an autonomous agent a long-lived secret, teams issue JIT credentials for a specific task, scope them tightly, and revoke them as soon as the task ends. That reduces the blast radius if the agent is manipulated, misprompted, or compromised.

Runtime policy matters just as much as credential hygiene. A static RBAC role often says what an agent may do in theory, but not whether it should do it in the current context. Intent-based authorisation is emerging because it lets policy engines evaluate what the agent is trying to do, what data it is touching, and whether the action matches the task. NIST’s NIST Cybersecurity Framework 2.0 supports this broader risk-based approach, while implementation patterns are increasingly discussed alongside Ultimate Guide to NHIs — Key Challenges and Risks and Top 10 NHI Issues.

• Use workload identity as the primary trust signal for agents, such as cryptographic proof from SPIFFE or OIDC-backed service identity.
• Prefer ephemeral secrets and narrow token scopes over reusable API keys and shared service accounts.
• Evaluate access at request time with policy-as-code rather than relying only on pre-defined roles.
• Log tool calls, secret access, and cross-system actions as part of the agent’s security trail.

These controls tend to break down in multi-step agent workflows with broad connector access because the system can drift from the original intent before a human review ever occurs.

Common Variations and Edge Cases

Tighter runtime controls often increase operational overhead, requiring organisations to balance faster automation against more policy exceptions and review points. That tradeoff is real, especially when teams run mixed environments with legacy apps, cloud services, and experimental agents side by side. Best practice is evolving here: there is no universal standard for intent-based authorisation yet, so teams should expect to combine several methods rather than wait for a single perfect control.

One common edge case is third-party tooling. If an agent can use OAuth-connected apps, hidden permissions can defeat otherwise strong internal controls. Another is memory-driven behaviour: an agent may not be malicious, but it can still surface sensitive context from prior tasks if retention and retrieval are not constrained. The DeepSeek breach shows how quickly exposed secrets and data can compound when governance lags behind deployment. For broader AI governance context, Ultimate Guide to NHIs — Why NHI Security Matters Now is a useful companion reference, especially when paired with Anthropic Project Glasswing for emerging agent safety thinking.

Traditional tools still matter, but they miss AI risk when the failure mode is identity abuse, dynamic delegation, or autonomous tool use rather than a known malware signature.

Related resources from NHI Mgmt Group

• What steps should security teams take to prevent Shadow AI risks?
• Why do traditional discovery tools miss shadow AI agents?
• Why do IoT and ot environments create different security risks from standard IT systems?
• Should organisations allow AI tools that can generate attack code?