Every AI security article we have read opens the same way: a list of enterprise controls, a reference to the NIST AI Risk Management Framework, and an implicit assumption that your organization has a dedicated CISO, a security engineering team, and several months to implement a proper program.
Most teams building with AI in 2026 have none of that. They have two or three engineers, a founder making security decisions in their spare time, and agents already running in production that have access to APIs, databases, and customer data.
This post is for those teams. Not because enterprise security is wrong. Because the waiting-until-we-have-a-real-security-team posture has a cost that compounds silently. An agent that can be manipulated into leaking data or calling the wrong API is a liability now, not hypothetically.
Here is the threat landscape as it actually looks at small scale, and the defense stack that addresses it without a dedicated budget or team.
The threat landscape, plainly
The attack surface for an AI system is different from a traditional web application. The model processes natural language from multiple sources: user input, retrieved documents, tool responses, memory stores. Any of those channels can carry malicious instructions.
Prompt injection
The most common attack against deployed LLM systems. An attacker embeds instructions in content the model will read. In a RAG system, the injected payload can be a document in the knowledge base. In an agent with web access, it can be text on a web page. In a customer-facing chatbot, it can come directly from a user message.
A real example: in 2023, a security researcher demonstrated that a malicious email in an auto-summarizing email client could instruct the model to forward sensitive emails to an external address. The model followed the instruction because it came through the same channel as legitimate content and there was no filtering layer to distinguish the two.
Indirect prompt injection, where the payload arrives through a tool or retrieval system rather than direct user input, is harder to detect and currently underdefended across the industry.
Jailbreaks and alignment bypasses
Jailbreaks exploit the model’s instruction-following behavior by constructing prompts that circumvent the safety guidance baked in during training. The attack surface shifts with every model update but never closes entirely because alignment is trained, not enforced at the protocol level.
For most production systems the practical concern is not someone bypassing political content filters. It is an attacker who finds a prompt pattern that causes your agent to ignore its system instructions about data access scope or tool usage limits.
Model exfiltration and data leakage
Fine-tuned models trained on proprietary data can leak that data through carefully constructed queries. Even base models can be coaxed into revealing information from their context window if output filtering is absent.
The more pressing concern for small teams is not model exfiltration but context leakage: system prompts, retrieved documents, and prior conversation turns that the model includes in its reasoning and surfaces in output when it should not. We have seen production systems where the full system prompt was recoverable with a single-turn jailbreak because there was no output filtering layer.
Supply chain risk
Most AI applications stack several dependencies: an LLM provider, an embedding model, a vector database, an orchestration framework like LangChain or LlamaIndex, a tool library. Each dependency is a trust boundary.
A compromised package in your agent’s tool layer can inject instructions into tool responses. A tampered model checkpoint (more relevant for teams hosting open-weight models) can carry backdoored behavior that activates on specific trigger phrases. Neither threat requires the attacker to touch your application code.
Tool misuse and scope creep
Agents with broad tool access can be manipulated into using tools outside their intended scope. An agent with access to a file system, an email API, and a database has an attack surface that includes all three simultaneously. Prompt injection that reaches an insufficiently scoped agent can turn a customer-service bot into an exfiltration vector.
The principle of least privilege applies to agents at least as much as it applies to service accounts, but it is inconsistently applied in practice because “give the agent what it needs to do its job” is a reasonable-sounding rule that does not account for what happens when the agent is manipulated.
The defense stack that actually works at small scale
You do not need a six-figure tooling budget. You need six controls, applied in order of leverage.
1. Input and output filtering layers
The first and cheapest control is a filtering layer on every input channel and every output before it reaches the user or another system.
For inputs: a classifier that detects prompt injection attempts, jailbreak patterns, and attempts to override system instructions. OpenAI Moderation API covers a useful baseline for harmful content. For injection-specific detection, Lakera Guard provides a dedicated classifier trained on adversarial prompt patterns. Robust Intelligence and ProtectAI offer broader LLM firewall options with more granular policy control.
For outputs: a classifier that checks whether the response contains material the model should not have surfaced. At minimum, run a regex and classifier pass for secrets, PII patterns, and system prompt fragments before returning output to the caller.
Both filters should log their decisions. A filter that silently blocks without a trace is an incident response liability.
The filtering layer does not need to be perfect on day one. It needs to exist and be observable.
2. Tool-call review and approval gates
Every tool an agent can invoke should have an explicit authorization check before execution. For high-risk tools (file writes, email sends, database mutations, external API calls), that authorization should require explicit human confirmation for the first several invocations of a new pattern, not just a technical permission grant.
The preview gate pattern: agent proposes a tool call, system surfaces the proposed action to a human in a structured card, human confirms or cancels, action executes only on explicit confirmation. This pattern slows agents down on novel actions and does not block high-velocity routine operations once they are confirmed as safe patterns.
We run this in production for every agent that touches external APIs or persistent storage. The friction cost is low for high-risk operations and near-zero for routine ones. The audit trail is the larger benefit.
3. Red-team workflows
Running your own attacks on your own systems before someone else does is the fastest way to find gaps the other controls miss.
A basic AI red-team exercise for a small team takes about four hours and covers the top injection patterns, common jailbreak templates, and scope-creep scenarios specific to the tools your agent can access. The output is a ranked list of weaknesses with reproduction steps.
We are publishing a detailed walkthrough of how we run these exercises on production agent systems. That post covers the full red-team methodology, including the tooling we use and the anonymized findings from a real pass. We will link it here when it publishes.
For now: a red-team exercise with two people and the OWASP LLM Top 10 as a checklist is a meaningful starting point. The OWASP list covers prompt injection, insecure output handling, training data poisoning, model denial of service, supply chain vulnerabilities, sensitive information disclosure, insecure plugin design, excessive agency, overreliance, and model theft. Running through each category against your specific system surfaces the real gaps.
4. Output validation against intent
Filtering catches known bad patterns. Validation catches semantic drift: an output that is technically clean but does not match what the agent was supposed to do.
For agents with structured outputs, validate the output schema before using it downstream. A response that should be a JSON object with a specific set of keys should be checked against that schema, not passed directly to the next step.
For agents making decisions, spot-check a sample of output against the decision criteria in the system prompt. An agent that is drifting toward overconfidence or toward refusing legitimate requests is exhibiting a problem that filtering will not catch.
The lightest version of this is a human review queue: route a random 5 percent of agent decisions to a human for spot-check review. The overhead is manageable and the signal is high.
5. Logging and audit trails
You cannot respond to an incident you cannot reconstruct. Every LLM call should be logged with enough context to replay it: the full prompt sent to the model, the response received, the tool calls made, and the final output.
Langfuse is the observability layer we use and recommend. It captures traces by pipeline run ID, links judge spans to evaluation rubrics, and provides a query interface for incident reconstruction. For teams already on the OpenAI stack, the Langfuse SDK wraps the OpenAI client with minimal code change.
The log should be append-only and stored outside the application’s primary data path. An attacker who compromises the application should not be able to modify the audit trail.
Minimum retention: 90 days. For systems handling regulated data, check whether longer retention is required by applicable frameworks.
6. Sandboxed execution contexts
Agents that execute code or interact with external systems should do so in isolated environments that cannot reach production credentials or data.
Practical implementation at small scale: a dedicated service account with the minimum permissions required for the agent’s legitimate functions, a separate network segment or VPC for agent execution, and explicit deny rules on paths the agent should never access (production database write endpoints, credential stores, admin APIs).
The goal is not to prevent every possible compromise. It is to ensure that a compromised agent cannot directly access the highest-value targets. The blast radius of a successful attack should be bounded by design.
What buying looks like
Most small teams should build the filtering, logging, and sandboxing controls themselves. The implementation cost is low and the operational understanding you gain is worth more than a vendor abstraction.
The cases for buying:
LLM gateways (AWS Bedrock Guardrails, Azure AI Content Safety, Google Vertex AI safety filters): if you are already on a major cloud provider’s AI stack, their native guardrails are the cheapest path to production-grade input and output filtering. They are not as specialized as dedicated AI firewall tools but they are well-integrated and maintained.
Dedicated AI firewall layers (Lakera Guard, Robust Intelligence, ProtectAI): for teams with agents handling sensitive data or high-stakes decisions, a specialized AI firewall that is trained specifically on adversarial LLM patterns is worth the additional cost. The detection accuracy on injection and jailbreak attempts is meaningfully better than generic content moderation.
Red-team as a service (Adversa AI, HiddenLayer, dedicated AI security consultancies): for teams that lack the internal expertise to run meaningful red-team exercises, a periodic external assessment is a high-leverage spend. One good red-team pass per year is more valuable than a moderate filtering investment.
Agent governance platforms (Patronus AI, Guardrails AI, NeMo Guardrails from NVIDIA): for teams building agent systems that need policy enforcement across multiple models and tool chains, a governance layer that externalizes policy from application code is worth evaluating once you have enough agents in production that per-agent manual controls become operationally expensive.
Questions to ask any vendor in this space:
- What attack patterns is the detection trained on, and how recently was it updated?
- What is the false positive rate on legitimate inputs in a system like ours?
- What does the audit log look like, and can we export it?
- What happens when the detection service is unavailable: does it fail open or fail closed?
RAGnos lab notes
We run this stack in production across several agent systems. A few observations from actual operation:
The filtering layer catches more than you expect on day one. When we turned on injection detection on a retrieval-augmented system that had been running in production for several months, the first week of logs showed 23 blocked requests that matched injection patterns. None had caused visible incidents. All had the structural signature of probing attempts rather than benign queries.
The tool-call approval gate changes developer behavior. Engineers building new agent capabilities started writing narrower tool scopes once they saw their proposed actions flowing through the review interface. The review gate was not just a security control; it made the blast radius of each agent action visible to the people building it.
Logging density matters more than log volume. A log that captures prompt, response, and outcome but not the tool calls in between is insufficient for incident reconstruction. We learned this after an agent produced an unexpected output and we could not determine which tool call had contributed the anomalous context because the intermediate steps were not captured.
Red-team exercises find things automated tools miss. A two-person exercise on one of our production agents found a multi-turn manipulation pattern where a benign first message established a false context that the second message exploited. The injection classifier did not flag either message in isolation. The combination was exploitable. That finding led directly to a stateful context validation layer that the automated tools had not surfaced.
Talk to us
If you are running agents in production without a security layer, or if you have a layer in place and want an independent read on where the gaps are, we run assessments and help teams close the highest-risk issues before they become incidents.
Email us at hello@ragnos.io or schedule a walkthrough. We will look at what you have, tell you what we find, and give you a ranked list of what to fix first.
No retainer required to start. One session is enough to determine whether the engagement makes sense.