Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsUsing ChatGPT or another large language model (LLM) with company information creates risks across the whole system—not just the model. Sensitive data can be disclosed, retrieved content can manipulate an AI agent, poisoned data can alter behavior, and unsafe output or overly powerful tools can affect connected systems. Reduce those risks with independent authorization, least privilege, controlled data access, validation, isolation, monitoring, and ongoing testing; prompt wording alone is not a security boundary.
Why LLM security is a system problem
The National Institute of Standards and Technology (NIST) treats security and resilience as characteristics of trustworthy AI. Its framing covers confidentiality, integrity, and availability across AI data and the software and hardware that process it. For an organization, that means an LLM deployment can fail in several distinct ways:
- Confidentiality: private information is exposed through a response, retrieval result, log, or connected tool.
- Integrity: data, a model, or an action is altered or manipulated, producing biased, harmful, or unauthorized results.
- Availability: a service or connected resource is exhausted, disrupted, or made too costly to operate.
These are system-level concerns. A deployment may involve a model provider, company data stores, retrieval components, applications, plugins or tools, user identities, and infrastructure. Securing only the model leaves the other parts—and the paths between them—exposed.
Ten application risks to recognize
OWASP’s 2025 Top 10 for LLM and GenAI Applications provides a practical map of application-focused risks. The names below follow that taxonomy; they describe possible failure modes, not a ranking of likelihood.
#1 Best Overall
| Risk | What can go wrong |
|---|---|
| Prompt injection | Crafted instructions in a user prompt or external content steer the model into unintended behavior. |
| Sensitive-information disclosure | Personally identifiable, financial, health, business, security, or legal information is exposed in output or through connected components. |
| Supply-chain risk | A third-party model, dataset, dependency, or other component introduces vulnerabilities or undermines trust. |
| Data and model poisoning | Manipulated training, fine-tuning, or embedding data degrades behavior or introduces bias, harmful behavior, or a backdoor. |
| Improper output handling | Unvalidated model text reaches an interpreter or downstream system, such as code execution, SQL, a browser, or an enterprise application. |
| Excessive agency | An AI application or agent has more tool access or authority than its task requires. |
| System-prompt leakage | Instructions in a system prompt are exposed. Treating those instructions as a secret or access control does not prevent disclosure or misuse. |
| Vector and embedding weaknesses | Weaknesses in retrieval-augmented generation (RAG) components, such as embeddings or vector stores, undermine the handling or access control of retrieved information. |
| Misinformation | Fluent, credible-sounding output is false and is used without appropriate verification. |
| Unbounded consumption | Resource or cost use grows without adequate limits, creating an availability or operational problem. |
OWASP’s 2025 categories are useful for threat modeling, but they do not establish a universal probability or breach rate for any one risk.
How prompt injection can reach company data and tools
OWASP defines prompt injection as crafted input that causes unintended model behavior. It distinguishes direct attacks—content supplied through a user prompt—from indirect attacks, where external content manipulates the model. That content could be an email, webpage, document, or retrieved passage. RAG does not automatically prevent injection: retrieved material is still input the model may interpret as instructions.
The central design rule is to treat external and retrieved content as untrusted data, not as authority. Separate instructions from data where possible, but do not depend on that separation or on a model’s refusal behavior as the final safeguard. A model must not be the sole authorization boundary.
- Check a user’s identity and permissions in the application or connected system before retrieving data or performing an action.
- Apply access controls to retrieval, so the model cannot fetch content the requesting user is not allowed to see.
- Limit each tool to the minimum actions and data needed for its task; avoid broad credentials and unrestricted access.
- Require human confirmation for high-impact or difficult-to-reverse actions.
- Validate model output before passing it to code, SQL, browsers, or enterprise systems.
Why system prompts and refusals are not security controls
OWASP states: “The system prompt should not be considered a secret, nor should it be used as a security control.” A prompt may describe desired behavior, but it cannot safely hold credentials, connection strings, or authorization decisions. Keep those in conventional identity and secret-management systems, and enforce permissions independently of the model.
Rank #3
Likewise, a model’s refusal is not proof that a user is authorized—or that an action is safe. Guardrail models can themselves be susceptible to prompt injection. Use monitoring and multiple independent controls rather than relying on a single model response or filter.
Poisoning threatens data and model integrity
Poisoning can occur in pre-training, fine-tuning, or embedding data. OWASP describes outcomes that include vulnerabilities, bias, toxic behavior, degraded performance, or backdoors. NIST’s AI 100-2e2025 taxonomy places poisoning alongside evasion, privacy, and misuse attacks, offering terminology for assessing attack types and mitigations.
Organizations should track the provenance of data and models, inventory dependencies and model components, and control changes to training, fine-tuning, and retrieval pipelines. Provenance and change records help teams investigate unexpected behavior and determine which components or data sources may be involved.
Controls that reduce risk without disabling useful automation
Effective safeguards put enforcement in the application and infrastructure around the model. The appropriate design depends on what data the system can access and what actions it can take, but these controls address the main failure paths:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Best Value
Identity, permissions, and tool scope
- Use least privilege for users, services, and tools; authorize each data access and action outside the model.
- Scope credentials to the task and environment. Store API keys and other secrets in managed secret stores rather than prompts, source code, or broadly accessible configuration.
- Separate read access from write or execution privileges, and require confirmation where an action has significant impact.
Data handling and isolation
- Minimize the sensitive information sent to a model or retained in application components.
- Enforce tenant boundaries in retrieval stores, application runtimes, and connected systems; do not assume that a shared model context provides isolation.
- Use anonymization or differential privacy where appropriate to the data and purpose. These techniques are not substitutes for access control.
- Apply access checks to retrieved documents and chunks, not just to the model endpoint.
Input, output, and dependency controls
- Treat user prompts and external content as untrusted; validate inputs and constrain how they are incorporated into model context.
- Validate and, where appropriate, encode or sanitize outputs before they reach downstream interpreters or applications.
- Maintain an inventory of models, data sources, and dependencies, and track their provenance and updates.
- Use resource limits and monitoring to detect or contain unbounded consumption.
Logging, testing, and response
- Log interactions and relevant tool activity in a way that supports investigation, while applying appropriate privacy and retention controls to logs.
- Run adversarial tests for direct and indirect prompt injection, data exposure, retrieval access failures, unsafe output handling, and excessive tool authority.
- Plan incident response for compromised keys, unexpected data exposure, poisoned inputs, or harmful tool actions.
- Review guardrails as one layer in a control system, not as a guarantee against attack.
OWASP’s Secure AI Model Ops guidance calls attention to weak isolation, leaked keys, prompt injection, logging, and privacy-preserving techniques. Together, these areas connect model risks to operational controls that teams can implement and verify.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Compare deployment designs using the same security questions
Hosted APIs, self-hosted open models, and systems that add RAG or agentic tools have different architectures. None is automatically secure by category. Compare the actual service terms, configuration, and control boundaries against these questions before selecting or approving a design:
| Review area | Questions to answer |
|---|---|
| Data residency and retention | Where is data processed and stored? What retention terms apply to prompts, outputs, and logs? Are terms specific to the relevant service, region, and configuration? |
| Identity, authorization, and tool scope | Which identity authorizes retrieval and actions? Are permissions checked by the application or connected service independently of the model? What can each tool do? |
| Training and fine-tuning provenance | What data and model components are used, and how are their origins and changes tracked? |
| Isolation and tenant boundaries | How are users, tenants, workloads, retrieval stores, and runtime environments separated? |
| Logging, testing, and incident response | Can the organization investigate relevant interactions and actions, test adversarial cases, and respond to key compromise or data exposure? |
| Updates and supply chain | Which models and dependencies are involved, how are updates managed, and how can changes be reviewed? |
These questions reflect the confidentiality, integrity, availability, disclosure, agency, poisoning, and supply-chain risks described by NIST and OWASP. Resolve them for the specific provider, edition, region, and deployment rather than assuming that a broad label such as “hosted” or “self-hosted” answers them.
Quick Recap
Build a proportionate security review
- Map the data and actions. Identify what users can submit, what sources the system can retrieve, what information may appear in output or logs, and which tools can make changes.
- Set access boundaries. Define permissions in identity and application systems, enforce retrieval access checks, and give tools only the authority they need.
- Protect information and components. Minimize sensitive data, manage secrets outside prompts, isolate tenants and runtimes, and track model, data, and dependency provenance.
- Validate the paths in and out. Test untrusted prompts and retrieved content, and validate output before it reaches an interpreter or connected system.
- Operate and reassess. Log relevant activity with privacy controls, set resource limits, run adversarial testing, and maintain incident-response procedures as models, data, and integrations change.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →
