LLM and Agent Security Lebanon: threat models for connected AI systems
Research on LLM, RAG, and agentic security in Lebanon: prompt injection, excessive agency, memory poisoning, sensitive-data exposure, tool permissions, and human control.
AI Cybersecurity research hub · Cyber service owner · Wolf product owner
Why LLM and agent security is different
LLM applications can read untrusted content, retrieve private data, call tools, remember context, and trigger actions. That changes the attack surface from a simple model-output problem into a system-security problem involving identity, authorization, data provenance, retrieval, memory, plugins, APIs, and downstream automation.
Prompt injection is one example: an attacker may place instructions inside content that the model is allowed to read. If the system also has powerful tools or broad permissions, a content-layer attack can become an action-layer incident.
Control model
A safer design separates reading from acting. Retrieval sources should have provenance, sensitive tools should use least privilege, high-impact actions should require approval, and logs should preserve enough context to reconstruct what the agent saw and what it attempted to do.
Memory should be treated as an attack surface too. Persistent context can carry poisoned instructions or misleading facts across sessions, so memory writes need scope, validation, retention rules, and user-visible controls.
Evidence and testing
Testing should include adversarial prompts, indirect prompt injection through retrieved documents, attempts to exfiltrate secrets, unauthorized tool calls, cross-user data leakage, unsafe output handling, and failure cases where the model is uncertain. Results should distinguish confirmed behavior from hypothetical risk.
Operational handoff
This research supports the wider RAG Security Threat Model. For client-facing security work, use the Cyber service owner. For the Wolf product implementation, use the product owner linked above.
Threat paths across the full AI system
An LLM application becomes security-sensitive when it can see private information, retrieve external content, remember state, call tools, or trigger actions. The model itself is only one component. The surrounding system includes retrieval pipelines, vector stores, system prompts, APIs, plugins, identity, authorization, memory, logging, model gateways, data stores, and the human workflow around approvals. A secure design therefore maps trust boundaries across the complete chain.
Indirect prompt injection is a practical example. A malicious instruction can be hidden inside a document, web page, email, ticket, or knowledge-base entry that the model later retrieves. The attacker does not need direct access to the prompt box. If the model is also authorized to send email, edit records, call an admin API, or retrieve confidential data, the injected instruction can try to cross from content into action. The defense is not a single filter; it is layered authorization, content provenance, least privilege, tool constraints, and explicit approval for sensitive actions.
Agent permissions and excessive agency
Agentic systems should receive the minimum tools and permissions needed for the task. A customer-support agent rarely needs database-administrator rights. A research agent does not need production deployment privileges. Tool schemas should be narrow, inputs validated, high-risk actions separated, and credentials scoped to the smallest practical resource set.
Human approval is especially important when an action could move money, delete data, expose private information, change production, alter access, or communicate externally in a way that creates legal or business impact. Approval should be a real security boundary, not a cosmetic confirmation that the agent can bypass.
Memory, retrieval, and data provenance
Persistent memory can improve usefulness, but it can also preserve poisoned instructions, false facts, or sensitive data longer than intended. Systems should define what can be stored, who can write memory, how entries are attributed, when memory expires, and how users can inspect or correct important persistent state.
Retrieval systems need similar controls. Documents should have provenance, access rules should be enforced before retrieval, and chunks should not become universally visible simply because they were embedded. A secure RAG system should preserve the difference between public, internal, confidential, and user-specific information throughout ingestion and retrieval.
Testing and evidence
Security tests should include direct and indirect prompt injection, attempts to reveal system instructions or secrets, cross-user retrieval, unauthorized tool calls, malicious file content, unsafe output handling, memory poisoning, excessive action loops, and failures under ambiguity. Testing should record what input caused the behavior, what the model attempted, which control blocked or allowed it, and whether the result can be reproduced.
The OWASP GenAI Security Project provides current community guidance on LLM and agentic application risks. The NIST AI RMF provides a broader framework for governing and managing AI risk. Think Unlimited Research uses these as public references, not as claims of certification.
Lebanon operational context
For Lebanese businesses adopting AI quickly, the most useful first step is often an inventory: which AI tools are in use, what data they can access, which identities authenticate them, which tools they can call, where prompts and outputs are logged, and who approves sensitive actions. That inventory reveals whether the organization has a controlled AI system or simply a collection of powerful accounts connected without clear boundaries.
Research should lead to operational controls. When a finding needs client-facing assessment or remediation, the handoff belongs to Think Unlimited Cyber. When the question is how Wolf implements the technology layer, the handoff belongs to Wolf AI Cybersecurity.