Why do AI security controls need to extend beyond the model itself?

Why This Matters for Security Teams

AI security fails when teams treat the model as the only asset worth protecting. In reality, the model is often the least privileged component in a wider chain that includes data sources, connectors, orchestration services, service identities, and export paths. If any of those layers are weak, a well-tuned model can still be used to exfiltrate data, trigger unsafe actions, or produce outcomes that are untrusted by design. This is why current guidance increasingly treats the surrounding control plane as part of the security boundary, not just the model weights.

NHIMG research shows how quickly attackers move once secrets or identities are exposed: in the LLMjacking report, publicly exposed AWS credentials were accessed by attackers in an average of 17 minutes. That same speed applies to AI-adjacent services when service identities, API keys, or OAuth grants are overexposed. The lesson is reinforced by the DeepSeek breach, which shows how embedded secrets and exposed data stores can create a security failure even when the model itself is not the root cause.

In practice, many security teams discover model-adjacent weaknesses only after a connector, token, or permissions issue has already been abused.

How It Works in Practice

Effective AI security shifts from model-only controls to end-to-end trust chain controls. That means verifying who or what can call the model, what data it can see, which tools it can invoke, and whether those actions are constrained at runtime. For agentic systems, this is even more important because the agent can chain actions, request new context, and move across services in ways that are not predictable at design time. The control question is not simply “Is the model safe?” but “What can this workload reach, change, or export at this moment?”

Practitioners usually need three layers working together:

• Identity: give the agent or service a workload identity, not a shared static secret, so the system can prove what is acting and where it is allowed to act. Standards such as SPIFFE and SPIRE are commonly used for this pattern.

• Authorisation: evaluate policy at request time using context, task, and sensitivity, rather than relying only on pre-defined role mappings. For AI systems, this aligns better with runtime intent than static RBAC.

• Secrets and tokens: issue short-lived credentials and rotate them aggressively. JIT access reduces the blast radius when a token is leaked, copied, or replayed.

This operating model is also reflected in the State of Non-Human Identity Security, where lack of credential rotation was cited as the top cause of NHI-related attacks by 45% of organisations. For agentic deployments, the CSA MAESTRO agentic AI threat modeling framework is useful because it forces teams to map how agents, tools, and trust boundaries interact across the full workflow.

These controls tend to break down when agents are granted broad, persistent access to SaaS tools and internal APIs because the runtime cannot reliably predict which path the agent will choose next.

Common Variations and Edge Cases

Tighter control of the AI trust chain often increases integration overhead, requiring organisations to balance operational speed against reduced blast radius. That tradeoff is real, especially in early-stage deployments where teams want rapid experimentation. Best practice is evolving, but the direction is clear: the more autonomous the system, the less defensible long-lived credentials and broad standing access become.

There are a few common edge cases. Some organisations can secure a model behind a single API gateway and still remain exposed because downstream data pipelines or export jobs are unconstrained. Others rely on vendor-hosted model endpoints and assume the provider owns the security boundary, when in fact the customer still controls the inputs, outputs, identities, and authorisations that drive risk. For high-trust use cases, runtime logging, tool-level policy enforcement, and scoped data access matter more than model selection alone.

For governance, the Anthropic Project Glasswing example is a useful reminder that advanced AI security work is moving toward system-level containment and oversight, not isolated model checks. NHI guidance from the Ultimate Guide to NHIs — Standards also reinforces that identities, secrets, and permissions must be governed as a chain, not as separate checkbox controls.

Where this guidance becomes hardest to apply is in multi-agent environments with shared memory, delegated tool use, and third-party plugins, because responsibility for each action path can become difficult to attribute in real time.

Related resources from NHI Mgmt Group

• What is the difference between model guardrails and runtime AI security controls?
• Should organisations use a dedicated AI agent identity model or extend current NHI controls?
• Why do AI systems create identity and data risk beyond the model itself?
• What breaks when model-level guardrails are treated as security controls for AI systems?