Most AI security incidents that get reported publicly do not trace back to an exotic new attack technique. They trace back to a small set of architecture decisions, made early, often for good reasons like speed or simplicity, that quietly widened the system's blast radius. These mistakes repeat across organizations and frameworks because the underlying temptation, take a shortcut that makes the demo work faster, is the same everywhere.
Treating the system prompt as a security boundary
A common early design decision is to put the important rules directly in the system prompt: "never reveal internal data," "never approve a transaction over this amount," and trust the model to follow them. This works most of the time in testing, which is exactly what makes it feel safe enough to ship. It fails under adversarial pressure, because a system prompt is a strong suggestion to the model, not a boundary anything else in the system checks. The fix is to move the actual rule into code that runs independently of the model's compliance: an authorization check, a hard limit, an approval requirement enforced outside the prompt.
Giving the model a single, powerful credential
Sharing one broad database or API credential across every user's requests, because provisioning per-user access felt like unnecessary complexity early on, is one of the most common and most damaging architecture mistakes. It means the model's authority is bounded only by what that one credential can do, not by what the current user should be allowed to do. The fix is to propagate the requesting user's actual identity and permissions through to every tool and retrieval call, even when that requires more upfront integration work than a single shared credential.
Retrieving broadly and filtering with instructions
Building retrieval to pull the most relevant documents regardless of the requesting user's access rights, and then instructing the model to "only use information the user is authorized to see," is a mistake that looks reasonable until someone actually tests it with a user who should not have access to a specific document. Relevance ranking and authorization are different concerns, and only one of them can be enforced deterministically. The fix is straightforward in principle and often skipped for convenience: filter by authorization before ranking by relevance, so unauthorized documents never reach the model's context at all.
Trusting tool responses as much as user input
Some architectures carefully validate user input but treat the output of a tool call, a web fetch, a document retrieval, as implicitly trustworthy simply because it came from "your own system." An attacker who can influence what a tool returns, by poisoning a document that gets retrieved or compromising an external service a tool calls, can inject instructions through this path just as effectively as through direct user input. The fix is to treat tool output as untrusted content flowing back into the model's context, subject to the same scrutiny as any other external input.
No limit on agent loops
Giving an agent the ability to call tools repeatedly in pursuit of a goal, with no cap on how many iterations or how much it can spend before stopping, creates a risk that is easy to overlook until a misconfigured goal or a manipulated input causes the agent to loop far longer, and far more expensively, than anyone intended. The fix is a hard limit on iterations, resource consumption, and elapsed time, enforced outside the agent's own control, with an explicit stop condition rather than an implicit assumption that the agent will naturally know when to stop.
No fail-safe default when a dependency is unavailable
Architectures that assume every dependency, a policy service, an approval system, an authorization check, will always be available tend to handle the unavailable case poorly, often by letting the action through by default because that was the simplest code path to write. The fix is to decide and implement explicit fail-safe behavior for every dependency a security decision relies on, defaulting to deny for high-impact actions rather than defaulting to allow.
Building bespoke enforcement per agent
As organizations add more agents, a common pattern is for each team to implement its own version of authorization checks, logging, and limits, because building it from scratch for each new agent felt faster than coordinating on shared infrastructure. This produces inconsistent enforcement, some agents well protected, others with gaps nobody noticed, because nobody has a single view across all of them. The fix is a shared enforcement layer that every agent's activity passes through, so the same policy applies consistently regardless of which team built which agent.
Where TELEON fits
TELEON is designed to address the last two mistakes directly: providing a consistent, fail-safe enforcement point across agents, applied through the gateway or supported middleware, rather than requiring each team to build its own version. It does not fix credential sharing, retrieval filtering, or loop limits on its own; those require specific architecture decisions inside the application and its integrations.
A short architecture review checklist
- Confirm no security rule depends solely on a system prompt instruction.
- Confirm the model's authority is scoped to the requesting user's
permissions, not a shared credential.
- Confirm retrieval filters by authorization before ranking by relevance.
- Confirm tool output is treated as untrusted input, not implicitly
trusted.
- Confirm agent loops have a hard limit on iterations, cost, and time.
- Confirm every security dependency has an explicit, deny-by-default
fail-safe.
- Confirm enforcement logic is shared across agents, not reimplemented per
team.
These mistakes recur because each one is individually easy to justify as a reasonable shortcut when a system is first being built. None of them look dangerous in isolation, and together they explain most of the AI security incidents that make it past a demo into production.