Teams building AI products often use "AI security" to describe two different bodies of work as if they were one thing. Model security is about the model artifact itself: its training data, its weights, its resistance to extraction and adversarial manipulation. Application security is about everything built around the model: the prompts it receives, the tools it can call, the data it touches, and the actions those tools perform.
Confusing the two leads to predictable gaps. A team that focuses entirely on model security might harden a model against adversarial examples and still ship an application where a prompt injection convinces that hardened model to misuse an unrestricted tool. A team that focuses entirely on application security might build tight tool permissions around a model that was trained on poisoned or improperly sourced data. Both gaps are real, and they need different people paying attention to them.
What model security actually covers
Model security is concerned with the artifact: the weights, the training process, and the model's behavior under adversarial pressure. This includes protecting training and fine-tuning data from poisoning, where an attacker introduces manipulated examples intended to bias future model outputs. It includes model extraction, where an attacker uses repeated queries to reconstruct a functional copy of a proprietary model. It includes adversarial robustness, testing whether small, deliberately crafted perturbations to input can cause disproportionate or dangerous changes in output.
It also includes provenance: knowing where a model or its weights came from, whether they have been tampered with since, and whether a fine-tuned derivative can be traced back to a known base model and known training data. This is largely a machine learning and data science responsibility, closer to the discipline of securing a supply chain than to conventional application security.
What application security actually covers
Application security, in the AI context, covers the surrounding system: how requests reach the model, what content and instructions are mixed together in a prompt, what the model is authorized to do once it produces a response, and how that response is handled downstream. This includes prompt injection defenses, retrieval access control, tool permission scoping, output validation, and the conventional practices of authentication, authorization, and secure coding that apply to any software product.
This is the layer most organizations interact with day to day, because most teams are building applications on top of models they did not train, using providers who are responsible for the model artifact's own security. For these teams, application security is where almost all of the practical risk and almost all of the available control lives.
Why the split matters for ownership
If an organization trains or fine-tunes its own models, model security needs a dedicated owner with machine learning expertise: someone who understands data provenance, training pipeline integrity, and adversarial testing methodology. Application security teams generally do not have this expertise, and expecting them to own model-level risk produces gaps that nobody with the right background is actually checking.
If an organization only consumes models through an API from a third-party provider, model security responsibility is largely delegated to that provider, though it is still worth understanding what the provider actually guarantees about training data integrity and model provenance before relying on it for something sensitive. In this case, application security is where almost all of the organization's own risk and its own responsibility to act concentrates, because the model itself is someone else's artifact operating under someone else's controls.
Where the two layers interact
The layers are not fully independent. A model with weak adversarial robustness makes application-level input validation more important, because the application has to compensate for a model that can be pushed off course more easily. A well-hardened model does not make application-level tool permissions unnecessary, because even a robust model can be legitimately instructed, through ordinary prompt injection rather than adversarial perturbation, to request an action it should not be authorized to take.
Neither layer substitutes for the other. A secure model behind an insecure application is still an insecure system. A secure application built on a model with poisoned training data is still exposed to whatever that poisoning was designed to cause.
A practical way to divide the work
For organizations that train or significantly fine-tune their own models, assign a model security owner who works with data science on training data provenance, poisoning defenses, and adversarial evaluation, separate from the application security owner who works on prompt handling, tool permissions, retrieval access control, and output validation. These two owners should coordinate, because a change on either side, a new fine-tuning run or a new tool, can shift what the other side needs to re-test.
For organizations consuming third-party models through an API, application security carries most of the practical weight, but it is still worth periodically asking the provider what they can state about training data sourcing and known model vulnerabilities, rather than assuming that layer is fully handled simply because it is out of your direct control.
Where TELEON fits
TELEON operates at the application security layer, applying runtime policy enforcement and producing an audit trail around agent and tool activity where it is deployed through the gateway or supported middleware. It does not perform model-level work like adversarial robustness testing or training data provenance verification, and organizations doing meaningful model training or fine-tuning still need a dedicated model security practice alongside it.
A short ownership checklist
- Determine whether your organization trains or fine-tunes models, or only
consumes them through an API.
- If you train or fine-tune, assign a model security owner with machine
learning background, separate from application security.
- If you only consume models, focus your own effort on application-layer
controls: prompts, retrieval, tools, and output handling.
- Ask any model provider what they guarantee about training data
provenance and known vulnerabilities.
- Coordinate model and application security owners whenever either side
changes.
Model security and application security are both necessary, and they are not the same job. Naming the difference clearly is what makes it possible to assign an actual owner to each one, instead of leaving both under a single vague "AI security" heading that nobody with the right expertise is fully accountable for.