An AI feature can be perfectly functional and still create a security problem. A chatbot answers correctly, a coding assistant saves developers hours, or an internal agent automates routine work. Meanwhile, the same application may be handling sensitive prompts, calling external models, installing dependencies, retrieving private documents, and executing actions with permissions that were never designed with AI in mind.
Securing an AI application therefore requires more than protecting the model. The surrounding code, data, infrastructure, integrations, and development environment all become part of the attack surface. The practical question is not simply whether the LLM is safe. It is whether the entire system remains secure when an LLM is allowed to interact with it.
Start with the application, not only the model
Model behavior receives much of the attention in AI security because attacks such as prompt injection are easy to demonstrate. Yet an LLM rarely operates alone. Production applications typically connect it to databases, APIs, retrieval systems, cloud resources, third-party packages, and sometimes tools capable of taking actions.
That creates several places where security can fail. A model might receive information a particular user should never have been able to retrieve. Generated output might reach another system without adequate validation. An agent may have broader permissions than its task requires. A vulnerable dependency can compromise the application regardless of how carefully its prompts were designed.
Security architecture needs to account for this entire chain rather than treating the LLM as an isolated component.
Map where data can travel
Before adding controls, teams need to understand the paths information takes through the application. AI systems can move data through more services than developers initially expect, particularly when retrieval, logging, analytics, external model APIs, and agent tools are involved.
A useful data map should identify:
- What information users can submit to the model.
- Which databases and document stores the application can retrieve from.
- What information is included in prompts sent to external providers.
- Where prompts, responses, embeddings, and logs are stored.
- Which services and tools can receive model output.
- What sensitive information could appear at each stage.
Once these paths are visible, access rules and data handling requirements become much easier to define. It also becomes possible to spot situations where confidential information is being copied into systems that were never intended to hold it.
Treat retrieval permissions as application permissions
RAG introduces a particularly important access control question. Connecting an LLM to internal documents does not mean every user of the AI feature should automatically be able to retrieve every document in that knowledge base.
Authorization should follow the user through retrieval. If an employee cannot open a particular document through the normal application interface, asking the assistant a carefully phrased question should not provide another route to the same information.
Testing should therefore cover direct questions as well as indirect attempts to recover restricted material. Summaries, partial quotations, metadata, document titles, and information reconstructed across several responses can all expose data without returning the original file.
Assume model output is untrusted
Developers usually understand that user input requires validation. LLM output deserves the same treatment.
A model can produce malformed data, unexpected instructions, unsafe code, incorrect URLs, or content influenced by an attacker through indirect prompt injection. Problems become more serious when that output is passed directly to a browser, database, shell, API, or another automated component.
The application should validate model output according to where it is going. Structured responses can be checked against schemas. Tool parameters can be restricted to expected formats and values. Generated code should go through the same security controls as human-written code rather than receiving an automatic pass because it came from an approved assistant.
Give agents less authority than their users
Agentic applications make permission design more consequential because the model can do something rather than simply return text. An agent might send messages, edit records, access cloud storage, create tickets, or trigger internal workflows.
Broad credentials make those capabilities dangerous. If an agent needs to read three fields from a customer record, it should not receive a token that can modify the entire database. The same principle applies to file access, APIs, cloud roles, and administrative functions.
Sensitive operations can also require additional authorization outside the model. Deleting records, changing permissions, publishing content, or moving money should not depend solely on an LLM deciding that a request looks legitimate.
Protect the software surrounding the LLM
AI applications still inherit ordinary software vulnerabilities. Secrets can be committed to repositories, dependencies can contain known vulnerabilities, cloud resources can be misconfigured, and containers can ship with unnecessary or vulnerable components.
AI-assisted development adds another layer. Coding models can suggest nonexistent packages, introduce insecure patterns, or reproduce vulnerable implementation choices. Developers may accept larger amounts of generated code quickly, which makes traditional review harder to scale.
For that reason, teams evaluating LLM security tools should look beyond prompt filtering alone. A platform such as Aikido approaches the problem across code, dependencies, supply chain risks, cloud configuration, secrets, runtime protection, and offensive testing. This broader coverage matters because an AI application’s security ultimately depends on the software and infrastructure around the model as much as on the model itself.
The objective is to catch problems at the stage where they can still be corrected easily. Vulnerable generated code is considerably easier to deal with in development than after it has reached production.
Watch the AI supply chain
Dependencies deserve particular attention because modern AI development relies heavily on external libraries, frameworks, model tooling, plugins, and integrations. A package does not have to contain a known CVE to be dangerous. It may be malicious from the beginning.
Hallucinated package names create an additional concern. A coding assistant can recommend a plausible dependency that does not actually exist, while an attacker can register that name and wait for someone to install it.
Dependency controls should consequently consider several different questions:
- Is the package actually the intended dependency?
- Does it contain known vulnerabilities?
- Is there evidence of malicious behavior?
- Is its version maintained?
- Does its license create an unacceptable risk?
- Was the dependency introduced by generated code?
Checking dependencies before or during installation can prevent some attacks earlier than discovering them after they have entered the environment.
Test what happens when instructions become hostile
Normal QA demonstrates how an AI application behaves when people use it as intended. Security testing needs to examine what happens when someone deliberately tries to break those assumptions.
Tests can include direct and indirect prompt injection, attempts to retrieve restricted information, manipulated RAG documents, unexpected tool parameters, excessive agent actions, poisoned dependencies, and adversarial API requests. Applications with meaningful external exposure can also benefit from dynamic testing and penetration testing against the complete system.
The important distinction is that testing should examine consequences, not merely whether a model follows an unwanted instruction. A successful injection becomes much more serious when it leads to data disclosure, unauthorized actions, credential exposure, or execution elsewhere in the application.
Keep visibility after deployment
Deployment does not end the security problem. Teams still need to know which models applications are calling, what new dependencies appear, whether cloud configurations change, and whether previously unreachable vulnerabilities become exploitable.
AI usage itself can become difficult to inventory as developers experiment with new providers and services. Unapproved model integrations may send company data outside expected boundaries without appearing in the original architecture documentation.
Useful monitoring therefore combines conventional application security with visibility into AI-specific behavior. The goal is to detect meaningful changes in the system before an undocumented experiment quietly becomes part of production.
Security has to follow the whole application
There is no single control that makes an AI application secure. Prompt defenses cannot repair vulnerable code, dependency scanning cannot enforce RAG permissions, and strict access controls cannot stop every malicious package.
A stronger approach follows the application from development to production. Code is checked as it is created, dependencies are examined before they become trusted, data access follows existing authorization rules, model output is validated, agents receive limited privileges, and deployed systems remain observable. Once those controls work together, AI security becomes part of application security rather than a separate layer added around the model.
