As the use of artificial intelligence (AI) in business continues to rise rapidly—now estimated at 18% of organizations with more than 10 employees according to INSEE—the safeguarding of data and data flows has become a central concern.
While model vendors naturally embed their own protective mechanisms, these standard safeguards quickly reveal their limits in professional settings. Designed to cover publishers’ liability rather than the true business risks faced by users, these generic restraints create a false sense of security while adding operational frictions.
Consequently, relying solely on default protections is no longer sufficient to meet the real requirements of SecOps teams.
For issues that native guardrails are theoretically supposed to handle—such as jailbreak attempts—AI providers themselves have conceded that perfect resistance is not possible. They thus advocate a necessary trade-off between security and practicality. Companies must therefore implement their own AI guardrails rather than relying solely on the providers’ or platforms’ uncertain safeguards.
A Personal Protection with Variable Geometry
Each user requires a different level of control. For cybersecurity researchers, guardrails must allow them to lean on the models for research. Otherwise, they will employ the usual jailbreak tricks to bypass them, or will switch models until they find one that enables their work.
By contrast, the activities of other departments, such as human resources, require far stricter control to shield them from a broad range of malicious content. Likewise, software engineers cannot allow any malicious or vulnerable code to infiltrate the codebase.
Thus, even these highly skilled users with very technical profiles require a protection level different from that of cybersecurity researchers. Deploying bespoke guardrails makes it possible to supply protection levels tailored to each user group.
Moreover, the protections offered by providers primarily shield the providers themselves, notably by preventing model distillation—which could erode their competitive edge—and by policing generic abuse that could expose them to liability.
For a company, the objective remains to protect its own assets by preventing sensitive data from leaking to third parties, avoiding misuse of its IT systems, or safeguarding its networks against malicious code generated by an LLM, for example. Added to this is the legal discoverability of AI exchanges and the providers’ recent changes to retention policies.
All of these elements clearly support the imperative to implement guardrails to prevent users from divulging confidential information to AI providers.
Furthermore, in the absence of proper controls, AI becomes a force multiplier for insider threats. For instance, indirect prompt injection and cross-origin context poisoning allow external attackers to covertly exploit the victim’s LLM to cause comparable damage or to steal sensitive data.
Many organizations also fear that their users will rely on compromised LLMs that deliver inappropriate content or covertly insert malicious code into responses. Building bespoke guardrails thus ensures a robust and consistent level of security, no matter which provider or model is used.
Uniformity and Observability
In addition, a properly structured security infrastructure also enables uniform enforcement of security policies. Different use cases require different models, and two versions of the same model often come with distinct guardrails. Some companies operate more than 100 models and model versions across multiple providers.
However, resting on the provider’s guardrails poses a visibility problem, as they operate like black boxes. They typically enforce restrictions through generic refusals or silent degradation of responses, without clear logs indicating when a guardrail was triggered and why.
As a result, SecOps teams have little visibility into which users encounter guardrails, how often they encounter them, which specific guardrails were triggered, and whether the user abandoned the request or persisted to bypass the restriction.
The deployment of customized guardrails bridges this visibility gap, equipping teams to assess the risk level associated with each user when they face these blocks.
Native guardrails also present another observability limit in that they usually stay confined to the model itself. They do not analyze the wider ecosystem, such as the MCP servers with which agents calling the model interact, or other tools used during the process. Deploying bespoke guardrails enables inspection of this entire critical traffic.
Model vendors rely on probabilistic classifiers based on LLMs to filter content. This approach meets strong resistance from cybersecurity professionals due to false positives, and because persistence can often bypass these protections.
By contrast, using bespoke guardrails allows combining deterministic rules (regular expressions, exact data matches, data fingerprinting) to detect sensitive content before it leaves the network, and a separate set of deterministic rules to detect malicious or inappropriate content before it is reinjected into the network from the LLM.
Coupled with LLM-based classifiers, such guardrails provide defenses that are both predictable and comprehensive, while preserving the flexibility inherent to LLMs to detect a broad range of threats.
Relying solely on the native guardrails provided by AI vendors exposes enterprises to significant security and operability gaps. These barriers are designed to protect the publishers rather than their customers, and they often lack transparency, agility, and effectiveness in the face of data leaks or targeted cyberattacks.
To safeguard assets and ensure robust governance, organizations must implement their own control solutions. This tailor-made approach allows adjusting restrictions by business function, restores full SecOps visibility over data flows, and unifies security across the entire AI ecosystem, regardless of the model in use.
