Before scaling GenAI, map your LLM usage and risk zones

In this Help Net Security interview, Paolo del Mundo, Director of Application and Cloud Security at The Motley Fool, discusses how organizations can scale their AI usage by implementing guardrails to mitigate GenAI-specific risks like prompt injection, insecure outputs, and data leakage.

He explains that as GenAI features proliferate, organizations must implement guardrails to manage risk, especially around input/output handling and fine-tuning practices. Establishing these controls early ensures safe, compliant adoption without compromising innovation.

For teams that have already launched GenAI features, what’s the first thing they should audit or check?

GenAI expands your attack surface in ways traditional threat models often overlook. New security practitioners to the space should start by learning about this new class of vulnerabilities and how to defend against them. A good starting point is the OWASP Top 10 for LLMs, which outlines common vulnerabilities like prompt injection, data leakage, and insecure plugin design.

These AI issues are causing alarm among AppSec leaders. In fact, a recent ArmorCode survey of this group found that of those who experienced issues with AI tools, 92% cited insecure code, and 83% pointed to a lack of transparency as their top concerns. At the same time, 55% of all respondents said that overall GenAI-based threats were a top concern.

When it comes to ensuring your company is using GenAI responsibly, start by inventorying LLM usage. Are you calling hosted models, fine-tuning your own, or running a RAG pipeline? Who are your users? Are they internal or external? Are you exposing sensitive data, and do you have fine-grained authorization in place?

Treat your LLM usage like any new service: document inputs, outputs, access controls, and failure modes. Invest in tools that can help map visibility and data flow. Do this before layering on more complex defenses.

What are best practices for implementing input/output sanitization when integrating LLMs into enterprise applications?

Just as traditional web applications use WAFs to identify malicious traffic, GenAI apps have a similar concept. These guardrails inspect both inputs and outputs.

On the input side, these systems detect prompt injection attempts, policy violations, and off-topic or unauthorized queries before they reach the GenAI model.

On the output side, they filter for things the model shouldn’t expose including PII, internal documentation, or topics outside the bot’s scope. For example, if your LLM is meant to help with onboarding, it shouldn’t answer questions about salary bands or internal financials.

These guardrails enforce policy boundaries in real time as a last line of defense. They don’t replace access control, but they greatly reduce the likelihood of exploitation.

If a company fine-tunes or hosts its own LLM, what AppSec considerations become more critical?

Fine-tuning is the process of adapting a pre-trained language model to a specific task or domain by continuing its training on a smaller, specialized dataset. This can expose intellectual property such as code, internal documents, even sensitive customer data that you don’t want echoed back. Without safeguards, a user could extract that information with the right phrasing.

The same AppSec leaders survey also found that 37% of respondents believed lacking GenAI oversight for software development was the biggest application security challenge.

As a result, several AppSec considerations have become more important:

• Training data sanitization: Ensure datasets are scrubbed of secrets, credentials, PII, and proprietary information before fine-tuning.
• Model output testing: Actively test the model for data leakage using red team prompts designed to extract memorized content.
• Access controls and audit logging: Limit who can access the model and log all usage for incident response and anomaly detection.
• Model deployment hygiene: Ensure the serving infrastructure (e.g., APIs) is protected against common web threats (e.g., injection, rate-limiting bypass).
• Secure model hosting: Protect the underlying model files and weights from tampering or exfiltration.
• Data provenance tracking: Maintain records of what data went into the model for compliance and breach impact analysis.

Security teams should treat LLMs as the high-value assets that they are.

Are there specific tools or frameworks you recommend for red-teaming GenAI features?

Yes. If you’re deploying GenAI to production, red-teaming should be part of your SDLC.

Platforms like Lakera Red and Straiker Ascend AI automate the discovery of vulnerabilities in LLM-powered applications. They also simulate attacks like prompt injection, jailbreaks, and agent escapes to surface real, exploitable weaknesses. Think of them as GenAI-specific pentesters that run continuously and scale with your development lifecycle.

The key is integrating these into your release process, not treating them as one-off security checks. ASPM platforms like ArmorCode also integrate pen test findings and AI to help triage and remediate the most important application security risks to an organization.

And while not technically red teaming tools, there’s something to be said about understanding the craft of GenAI exploitation. Games like Lakera’s Gandalf are also useful for personal or a collective team’s education. They raise awareness and help developers experience firsthand how easily LLMs can be manipulated. Education is always part of defense.

What CI/CD pipeline controls are essential when deploying AI-driven features into production?

Treat anything influencing model behavior, such as prompts, system messages, and retrieval logic, as code. Version it, review it, and gate it behind your normal change management process.

Add automated tests that validate not only function but behavior. If an update causes the model to hallucinate sensitive info or violate policy, you want to catch that in staging not after deployment.

Scan fine-tuning inputs for PII or risky content. Validate model artifacts before they’re deployed and restrict who can change production inference settings or prompt templates.

It shouldn’t be easier to change your chatbot’s behavior than it is to deploy a backend service. Hold LLMs to the same standard.