AI-native security tools are model-dependent by design

At a glance

What this is: Pentera argues that AI-native security products built around a single frontier model can fail when that model is deprecated, suspended or switched off.

Why it matters: For IAM and security teams, the issue is governance of dependency, data exposure and resilience, because model availability and behaviour now sit inside the control plane of the product.

Context

AI-native security tools increasingly depend on external foundation models for core functionality, which means the security product inherits the model provider’s availability, policy and retention decisions. When a model can be retired, suspended or reconfigured outside the buyer’s control, the product’s governance model changes with it.

That creates a genuine security and operational gap for teams managing identity, secrets or AI-assisted workflows. The relevant question is no longer whether the tool uses AI, but whether its decisioning, auditability and data handling remain stable if the underlying model changes or disappears.

Key questions

Q: What breaks when an AI security tool depends on a third-party foundation model?

A: Behaviour can drift after provider updates, access can disappear through policy changes, and sensitive test data may leave your control boundary. Those risks make the tool harder to govern and harder to operationalise in regulated environments. Ownership of the surrounding harness does not remove dependency on the underlying model.

Q: Why do external model dependencies create risk for security governance?

A: Because the provider can change availability, retention, routing or output behaviour without the buyer controlling that lifecycle. Security teams need repeatable controls and defensible evidence, so any hidden dependency that can change the result undercuts governance. The risk is concentration, not just outage.

Q: How can teams tell whether AI security workflows are actually reliable?

A: Check whether the workflow produces consistent results from the same underlying evidence and whether it preserves the relationship between findings, identities, and assets. Reliable workflows reduce rework, surface the right context on the first pass, and generate remediation steps that still make sense when reviewed against the live environment.

Q: What should security teams do before sending sensitive data to an external model?

A: Classify the data flow first, then verify retention, deletion and cross-border processing terms. If logs, code, identities or secrets leave the environment for inference, the model provider becomes part of the data-governance boundary. The buyer remains accountable for that exposure.

Technical breakdown

Model dependency turns into control-plane risk

Many AI-native security tools are not self-contained systems. They are orchestration layers that call an external model for classification, analysis or recommendations, then present the result as a product feature. That architecture creates a hidden dependency on a provider’s model lifecycle, including version retirement, access suspension and policy changes. If the model disappears or changes behaviour, the product may still be online technically, but its security function becomes unreliable or unavailable. In governance terms, the model is no longer just a component. It is part of the control plane.

Practical implication: Treat model selection and model continuity as a security dependency, not a procurement detail.

Reproducibility breaks when model outputs drift

Security operations depend on results that can be repeated, explained and defended. Frontier models are inherently nondeterministic, and even stable-looking deployments can drift when providers update weights, routing or retention settings. That matters when a tool is making detections, validations or policy recommendations that may later need audit evidence. If the same input can produce different outputs, the control is no longer stable enough for assurance work. For identity and security teams, this is especially problematic where workflows depend on consistent decisions over time.

Practical implication: Require version visibility and re-test controls whenever the underlying model changes.

Data exposure follows the model boundary

When logs, source code, identities or security telemetry are sent to a third-party model API, the product inherits that provider’s retention and processing terms. The article’s point is not that AI itself is unsafe, but that the surrounding data path can quietly shift the compliance posture of the product. Retention defaults, opt-out limits and cross-border processing all become part of the control story. For security teams, the model boundary is also a data boundary, and that boundary must be governed explicitly.

Practical implication: Classify model prompts and outputs as governed data flows, then review retention and sharing terms before deployment.

Threat narrative

Attacker objective: The practical objective is not exfiltration but control disruption through dependency failure, leaving downstream security workflows unable to function as designed.

1. Entry occurs when a security product depends on an external frontier model to perform core analysis or validation.
2. Credential or access loss follows when the model provider suspends, retires or changes access to that model, removing a critical runtime dependency.
3. Impact is operational and governance-related, because the product can lose availability, reproducibility and compliance continuity without any code compromise.

Breaches seen in the wild

• Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-native security tools are increasingly model-hosted control systems, not standalone controls. When a product’s effectiveness depends on a third-party model being continuously available, the buyer has outsourced part of the control plane. That creates a governance dependency that standard software assurance questions do not fully capture. Practitioners should evaluate the model lifecycle as part of the security architecture, not as background infrastructure.

Model shutdown risk is really concentration risk in security tooling. Multiple vendors can appear diversified while relying on the same foundation model or provider family. If that model changes, fails or is withdrawn, the blast radius extends across the buyer’s stack at once. The practitioner conclusion is to test for provider concentration the same way they would test for cloud-region concentration or shared identity infrastructure concentration.

Reproducibility is the overlooked requirement in AI-enabled security. Security decisions need repeatable evidence, especially when they affect access, prioritisation or validation outcomes. If a model update silently changes outputs, assurance work becomes unstable and audit trails weaken. The practical implication is that AI-native security needs version pinning, test revalidation and a fallback path that preserves operational continuity.

Data-governance boundaries matter more than AI branding. Many products marketed as AI-native are actually data-export products with a model in the middle. Once logs, code, credentials or identity telemetry leave the environment for inference, retention and processing terms become part of the control design. Teams should assess whether the model boundary aligns with their confidentiality and residency requirements before adoption.

What this signals

Model dependency should be treated as a governance category in its own right. A security product that stops working when a third-party model is withdrawn is not simply an AI-enhanced tool, it is an outsourced control with an unstable dependency boundary. For practitioners, that means model provenance, version control and fallback design belong in architecture review before deployment.

The deeper risk is that buyers often evaluate AI-native security products as if the model were interchangeable infrastructure. In practice, the model can shape data handling, behavioural consistency and even auditability, so the governing question is whether the tool still functions when its model assumption changes.

For practitioners

• Define model dependency as a security control Inventory which security products rely on external foundation models for core function, then document what breaks if each model is suspended or changed.
• Test for model concentration risk Map vendors to the underlying model providers they use and look for hidden single points of failure across tools that appear separate.
• Require versioned revalidation for model changes Make every model version change trigger regression testing for detections, recommendations and audit outputs before the new version is accepted.
• Review model-data retention terms Check whether prompts, logs, code or identity data are retained by the model provider and whether opt-out or deletion terms meet policy requirements.

Key takeaways

• AI-native security tools can inherit the availability and policy decisions of the external models they depend on, which turns model continuity into a security requirement.
• The key failure mode is not AI itself but concentration on one provider model, which can affect multiple products at once and undermine resilience.
• Practitioners should assess model versioning, fallback behaviour and data retention terms before accepting AI-native tooling into security workflows.

Key terms

• Model Dependency Risk: The operational and governance exposure created when a product depends on a third-party model for core functionality. If the model is retired, restricted or updated, the buyer can lose availability, stability or auditability even when the surrounding software is still running.
• Model Drift: Model drift is the gradual change in a model’s behaviour or performance after deployment. It happens when the operating environment, user patterns, or inputs no longer match the conditions used to validate the system. Drift matters because a model can appear functional while no longer meeting approved standards.
• Control Plane: The control plane is the set of actions that create, configure, or manage a service. For AI workloads, it covers deployment and administration of the model platform, while data-plane permissions govern what the service and its identities can read or process.
• Fallback Path: A secondary access route used when the primary authentication method fails. Fallback paths matter because they often become the real control in day-to-day use. If they are easier than the intended method, the organisation will drift toward them and weaken its identity posture.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity and secrets management. It helps practitioners connect identity controls to the wider security architecture they operate and audit.