AI security is not a single product category. It is the set of controls that keeps a model, its data, its prompts, and its tool access behaving as intended under deliberate attack. This article is the guide to the AI Security coverage on Global Tech Insights: what each branch covers, how the pieces fit together, and where to start.
NIST’s AI Risk Management Framework treats security as one trustworthiness dimension among several, not as an afterthought. MITRE ATLAS and the OWASP Top 10 for LLM Applications give that idea a working taxonomy of real attacks. The articles below apply both to operating systems rather than to slide decks.
On this page
- What AI security actually covers
- The attack surface is different
- The branch map
- Where to start
- What does not count as AI security
- How the branches connect
- Common failure patterns
- Operating cadence
- Measure the program
- FAQ
What AI security actually covers
AI security spans the lifecycle: the data used to train or fine-tune a model, the model artifact itself, the prompt and system instructions, the retrieval sources, the tools an agent can call, and the output before it reaches a person or another system.
It also spans roles. Data engineering, application security, privacy, model owners, and operations each hold part of the surface. No single team owns all of it, which is why mapping matters before controls, and why every control needs a named owner and a review date from the start.
- Data: training, fine-tuning, and retrieval sources.
- Model: weights, versions, and provenance.
- Runtime: prompts, tools, agents, and outputs.
The attack surface is different
Traditional application security assumes a fixed, auditable code path. AI systems have a probabilistic, data-dependent decision path. The same input can produce different outputs across sessions or model versions, and the attack often arrives as ordinary-looking text rather than malformed syntax.
MITRE ATLAS catalogues real adversary tactics against AI systems, from reconnaissance through data poisoning to model extraction. NIST AI 100-2 groups them into evasion, poisoning, privacy, and abuse. Both references exist because generic threat models miss these paths.
- Instructions and data share one token stream.
- Training data is a long-lived attack vector.
- Agent tool access extends the blast radius.
The branch map
The table below maps each article in this guide to the layer it addresses. Use it to pick the reading order that matches your current risk, not to read sequentially for its own sake.
| Article | Layer covered | Primary question |
|---|---|---|
| AI threat model | Planning | What are we defending and from whom? |
| Prompt injection | Input and instructions | How do we limit manipulation? |
| Agent least privilege | Runtime permissions | What can this agent actually do? |
| Model supply chain | Artifacts | Where did this model come from? |
| Red teaming | Validation | Does it hold under real attack? |
| Data poisoning | Training data | Can the source be trusted? |
| Output handling | Downstream systems | What happens when output executes? |
| Incident response | Recovery | What do we do when it fails? |
| Shadow AI | Discovery | What AI is in use right now? |
| Access logging | Evidence | Can we reconstruct what happened? |
Where to start
Start with discovery and inventory. An organisation cannot secure AI use it has not found, so the shadow AI article is the practical first step even for teams that already have a formal AI policy on paper.
Second, build the threat model for the highest-consequence system you run. Third, close the runtime gaps that cause the most real damage: agent permissions, output validation, and logging. Artifact and data-layer work follows once the runtime is contained.
- Discover actual AI use.
- Threat model the highest-consequence system.
- Contain the runtime before optimizing the data layer.
What does not count as AI security
A vendor’s “secure by design” marketing line is not a control. A one-time red team report from a prior model version is not current evidence. A policy document without an inventory behind it describes intent, not implementation.
None of these are worthless. They are simply not substitutes for an owned, current, tested set of controls tied to the system as it runs today.
Operating rule: A control counts only when a named person can perform it, another person can review it, and evidence exists that it happened.
How the branches connect
These articles share one spine. Discovery feeds the inventory. The inventory feeds the threat model. The threat model decides what the red team tests and what the logs must capture. Incident response consumes all of it when something fails, and its findings feed back into the model.
Treat the branch as a cycle rather than a checklist. Each material change to a model, tool, or data source reopens the loop.
- Discovery feeds inventory.
- Threat model decides test and log scope.
- Incidents refine the whole cycle.
Common failure patterns
Most AI security failures trace to a few patterns rather than exotic attacks. A team grants an agent broad tool access to save setup time. A retrieval source is added without checking what it can leak. A model version changes and nobody retests the controls that were validated against the old one.
These are process failures, not research problems. They are also the reason this branch emphasises owners, evidence, and review triggers over tooling lists. A tool does not compensate for a control nobody operates.
- Broad tool access granted for convenience.
- Retrieval sources added without exposure review.
- Controls validated against a superseded model version.
Operating cadence
An effective cadence pairs scheduled reviews with change triggers. The scheduled review keeps the program honest about drift. The change triggers catch the events a calendar misses: a new model version, a new tool grant, a new data source, or an incident anywhere in the portfolio.
Keep the cadence lightweight enough to actually run. A monthly one-hour review with real evidence beats a quarterly deep dive that slips every quarter.
- Scheduled reviews on a fixed calendar.
- Triggered reviews on material change.
- Evidence attached to every review outcome.
Measure the program
Measure the AI security program the way any security program is measured: by controls operating as designed, not by activity. Useful measures include the share of AI use cases with a named owner, the share of agents with reviewed tool permissions, the time to disable a misbehaving model version, and the percentage of systems with prompt-level logging in place.
Define each measure’s denominator and the action that follows when the number moves. A measure without a decision attached becomes a dashboard decoration rather than a control.
- Share of AI use cases with an accountable owner.
- Agent permission reviews completed on schedule.
- Time to disable or roll back a model version.
FAQ
Do small teams need all ten articles?
No. Start with discovery, threat modeling, and agent permissions. Add the rest as the surface grows.
Is AI security separate from application security?
It overlaps heavily. The AI-specific parts are data, model, and prompt layers that traditional appsec tooling does not inspect.
Which framework should we follow?
NIST’s AI Risk Management Framework is the broadest starting point. ATLAS and the OWASP LLM Top 10 give it tactical depth.
What is the most common gap?
Agent tool permissions. Teams routinely grant broader access to an agent than to the human who configured it.
How often should the cycle repeat?
After every material change to model, tool, or data source, plus a fixed calendar review.
Does a hosted AI provider remove our responsibility?
No. A hosted service changes who operates parts of the stack, not who is accountable for the outcome.
Related reading
- Prompt Injection Defense Needs Layered Controls
- AI Agent Tool Permissions Need Least Privilege
- Shadow AI Needs Discovery Before Policy
How do we measure whether the AI security program works?
Track control coverage rather than activity: owned use cases, reviewed agent permissions, rollback time, and logging coverage, each with a defined action threshold.
What is the difference between AI security and AI safety?
Security protects the system from deliberate attack. Safety addresses harm the system can cause without an attacker. Mature programs run both tracks with shared evidence.
Which team should lead AI security?
Security usually leads, with data engineering, privacy, and model owners holding defined parts of the surface. The key is one accountable program owner.
Is AI security a one-time project?
No. Models, tools, and data sources change. The program needs review triggers tied to material change plus a fixed calendar review.
Conclusion
AI security is a lifecycle discipline, not a product purchase. Discover what is in use, model the threats, contain the runtime, prove the artifacts, and keep the evidence. The articles in this branch cover each step with the same operating focus.
For teams building AI capability alongside security work, external specialists can accelerate the program. See AI consulting services for implementation support.
Sources
More Stories
AI Access Logging Needs Prompt-Level Detail
Standard web access logs are not enough for AI systems. Prompt-level logging captures what an incident reconstruction actually needs.
Shadow AI Needs Discovery Before Policy
A policy written before discovery fails. Find actual AI use through network review, audits, procurement records, and non-punitive surveys.
AI Incident Response Needs a Model-Specific Playbook
A generic IT incident response plan misses AI failure modes. A model-specific playbook covers rollback, evidence, and decision rights.
AI Output Handling Needs Downstream Validation
Raw model output should never reach a database, shell, or user unvalidated. Apply the same discipline used for user input.
Training Data Poisoning Needs Source Control
Poisoning attacks corrupt training or fine-tuning data. Source control, provenance, and auditing reduce the risk before a training run.
AI Red Teaming Needs a Realistic Adversary
Red teaming an AI system differs from red teaming a network. Define the adversary first, then test, document, and feed findings back.