Using a capable AI model does not automatically make the application around it secure.
LiteByte uses the OWASP Top 10 for LLM Applications 2026 as a reference framework for identifying and addressing security risks that are specific to software built around large language models.
Our AI systems will typically integrate established models from providers such as OpenAI, Anthropic, Microsoft or Google through APIs rather than train or host foundation models ourselves.
That means our security focus is on the system we actually control: prompts, data, retrieval, permissions, tools, application logic, model outputs, integrations and the boundaries between them.
The OWASP framework helps us ask a practical question:
If somebody deliberately tried to make the AI application behave in a way we did not intend, what could they reach and what could they make happen?
Prompt injection
What happens if the model follows an instruction we did not intend it to follow?
Prompt injection can come directly from a user or indirectly through information the model is asked to process, such as documents, web pages, retrieved knowledge or tool responses.
We therefore do not treat a system prompt as a security boundary.
Security-sensitive decisions such as permissions, authorisation and access to external systems are enforced by application logic outside the model. Where AI can trigger actions, the surrounding architecture is designed to limit what a successful injection could actually achieve.
Testing can include direct, indirect and retrieval-based prompt injection rather than assuming that a model refusing one malicious prompt proves the system is secure.
OWASP identifies the underlying problem as the model receiving trusted instructions and untrusted data within the same context without a guaranteed security boundary between them.
Sensitive information disclosure
Could the AI reveal information that the user should not be able to access?
Sensitive information can leak through more than the final response.
AI applications can expose information through:
- prompts and context;
- retrieved documents;
- tool arguments;
- conversation history;
- logs and traces;
- system instructions;
- embeddings; and
- connected services.
We minimise the information supplied to the model, keep credentials and secrets outside model context, and enforce access controls before information is retrieved and passed to AI.
For multi-user or multi-client systems, a model must not gain access to another user's information simply because retrieval considers it semantically similar.
OWASP specifically highlights PII exposure, sensitive information in logs, unauthorised retrieval and excessive sensitive data being sent to external services as important LLM application risks.
Excessive agency
What is the AI actually allowed to do?
An AI assistant that can answer a question presents a very different security risk from an agent that can:
- send emails;
- modify records;
- delete information;
- make API calls;
- access files;
- or perform other actions.
Where AI is connected to tools, we minimise both the number of capabilities available and the permissions attached to them.
Authorisation is enforced by trusted application code rather than allowing the model itself to decide whether an action is permitted.
High-impact or irreversible actions can require explicit human confirmation.
OWASP identifies excessive functionality, over-privileged identities and insufficient limits around tool execution as key causes of excessive agency.
AI supply chain
What external components are we trusting?
Modern AI applications depend on more than the model provider.
They can include:
- AI APIs;
- SDKs;
- orchestration frameworks;
- MCP servers;
- third-party tools;
- embedding services;
- vector databases;
- and conventional software dependencies.
We assess the providers and components introduced into the system, track the important dependencies and apply normal vulnerability and dependency-management practices.
We also do not assume that a package or library recommended by an AI coding tool actually exists or is trustworthy simply because the model generated its name.
Because LiteByte normally consumes established models through APIs, controls around downloading, signing or modifying model weights will often not apply. The security of the dependencies and integrations around the modelstill does.
OWASP explicitly treats third-party models, packages and AI components as part of the application supply-chain attack surface.
Data and retrieval poisoning
Can an attacker influence the information the AI treats as trusted knowledge?
For the systems we build, poisoning is often more relevant to RAG and knowledge bases than to model training.
If an AI system retrieves documents, uses persistent memory or automatically ingests information, we consider:
- where that information came from;
- who can modify it;
- whether external information is trusted;
- how incorrect or malicious content can be removed;
- and whether manipulated content could influence future responses or actions.
Automatically indexing information does not automatically make that information trustworthy.
OWASP specifically extends poisoning risks into retrieval stores and other AI data pipelines where attacker-controlled content can be mixed with trusted information.
Unbounded consumption
Can someone make the AI consume unreasonable resources or cost?
LLM APIs introduce resource limits that conventional web applications may not have in quite the same form.
A single request can consume large amounts of:
- tokens;
- reasoning time;
- API spend;
- tool calls;
- or downstream resources.
Depending on the system, we therefore define controls such as:
- request limits;
- maximum context size;
- output limits;
- timeouts;
- per-user quotas;
- cost monitoring;
- spending limits;
- and limits on tool or agent execution.
This protects both availability and cost.
OWASP specifically identifies missing rate, token, cost and queue limits as a root cause of unbounded resource consumption.
Misinformation
What happens when the model confidently produces something that is wrong?
Generative models can produce convincing but incorrect information.
The consequence depends on what happens next.
If AI output is used only as a draft for a person to review, the risk may be relatively limited.
If the output can trigger a system action, influence an important decision or become accepted as authoritative evidence, stronger controls are required.
Where appropriate, we separate what the model claims from what the system is allowed to do because of that claim.
Important information can be checked against trusted sources or actual system state before consequential actions occur.
OWASP identifies unvalidated or misleading AI output being trusted and acted upon as the central weakness behind this risk.
Hidden context exposure
What if someone discovers the system prompt?
We design on the assumption that hidden model context may eventually be extracted or inferred.
A system prompt therefore should not contain:
- passwords;
- API keys;
- database credentials;
- security-critical secrets;
- or permissions that only work because the user cannot see them.
Security controls are implemented outside the model.
A leaked system prompt may reveal how an application works, but it should not provide the credentials or authority required to compromise it.
OWASP explicitly warns against credentials in system prompts and against relying on hidden context to enforce authorisation or security policy.
Vector and embedding security
Is the retrieval layer enforcing the same permissions as the rest of the application?
Embeddings and vector databases introduce their own security boundary.
A similarity search should not retrieve another customer's information and only afterwards ask whether the current user was allowed to see it.
Where RAG is used, access control is applied at the retrieval layer so that only authorised information can enter the model context.
We also treat embeddings according to the sensitivity of their source information rather than assuming that converting text into vectors makes the underlying information harmless.
Where appropriate, that includes controls around:
- tenant isolation;
- document-level permissions;
- vector-store access;
- backups;
- retention;
- and deletion.
OWASP specifically highlights cross-tenant retrieval, embedding inversion and retrieval poisoning as risks associated with vector and embedding systems.
Improper output handling
What happens when AI output reaches another system?
Model output is treated as untrusted input.
That is particularly important when AI-generated information is passed into:
- a browser;
- HTML or Markdown;
- a database query;
- a file path;
- an API;
- a terminal;
- or executable code.
The fact that text came from an AI model does not make it safe to execute.
Where appropriate, outputs are validated, structured, encoded or sanitised before reaching downstream systems. Database operations use appropriate parameterisation, generated paths and commands are constrained, and AI-generated code remains subject to ordinary engineering and security review.
OWASP specifically connects unsafe handling of model output to vulnerabilities including command execution, cross-site scripting, SQL injection and privilege escalation.
Security testing for the AI application
The objective is not simply to test whether the model gives good answers.
We test the boundaries around the model.
Depending on the architecture, that can include attempts to:
- inject malicious instructions;
- extract sensitive context;
- cross tenant boundaries;
- poison retrieved information;
- invoke unauthorised tools;
- exhaust resources;
- produce unsafe downstream output;
- or exploit assumptions made by the surrounding application.
Findings feed back into the architecture, permissions, validation and operating controls before release.
What OWASP alignment means at LiteByte
The OWASP Top 10 gives us a practical security model for the attack surface created when large language models become part of an application.
We use it to identify which LLM-specific risks apply to the architecture, translate those risks into engineering requirements, test the relevant controls before release and reassess them when material capabilities change.
That creates a simple rule:
We do not rely on the AI model itself to make an AI application secure. We assume the model can be manipulated, mistaken or exposed, and design the surrounding system so those behaviours cannot automatically become a security compromise.
For applications that evolve into more autonomous agents with significant tool use, persistent memory or multi-step actions, we extend that assessment into OWASP's agentic AI security guidance as well.
Our broader AI governance, risk, privacy and regulatory processes are supported separately through our NIST AI RMF, ISO/IEC 42001, ISO/IEC 27018 and EU AI Act-aligned practices.