AI applications, agents and models are moving into production in many organizations, and the security around them often arrives later. The reason is practical: the first model is built by a data or AI team, the security team hears about it at go-live, and nobody owns its security in between. The controls below are the ones to settle before that first go-live, so that AI adoption extends the security posture you have rather than opening a gap in it.
AI changes what has to be protected
A traditional application has a code base, an infrastructure footprint and a set of users. An AI system adds more: the model itself, the data used to train or ground it, the prompts and outputs that pass through it, the integrations that let it read from and act on other systems, and, for agents, the actions it can take on its own.
Each of these is an asset or a path that security has to account for. The data an assistant can retrieve, the APIs an agent can call and the cloud workload the model runs on are all in scope. Treating the model as just another application misses most of them.
AI security has an owner
The first control is organizational. Decide who owns the security of AI systems: the requirements they have to meet, the review before go-live and the monitoring after it. Without an owner, AI applications and agents reach production and nobody owns their security.
The owner does not have to build everything. The owner makes sure the questions in this piece are asked for each AI system and that the answers are recorded. Cybersecurity is a trust layer across the whole journey, so security requirements belong in data architecture and governance and in AI design and deployment, not only in operations.
The data the model can reach is known
An AI system is a new way to reach data. An assistant grounded in enterprise documents can surface anything it is allowed to retrieve, including material that was protected only by being hard to find. The control is to know, before go-live, which data the system can access and whether that matches its purpose and the classification of the data.
Data classification and ownership come from data governance. Data security and data loss prevention controls enforce them across the lifecycle of the data. A data and AI security assessment checks that the two agree for the systems about to go live.
Identity and access are controlled for people and for agents
Who may use the AI system, and what may the system do on their behalf? For assistants, the answer is about users and roles. For agents, it is also about the identity of the agent itself: the permissions it holds in the systems it acts on, and whether those permissions are the minimum its job requires.
Identity and access management, privileged access and Zero Trust principles apply to agents as they do to people. An agent with broad standing access is a privileged account, and it should be managed as one.
The application, the APIs and the workload around the model are protected
The model runs inside an application, exposes or consumes APIs, and lives on cloud or hybrid infrastructure. Each layer needs the protection that layer normally gets: application and API security for the interfaces, cloud and workload security for where the model runs, and controls specific to AI for the model and its data access, such as limits on what a prompt can make the system do.
These controls are chosen for your environment and kept effective once they are in place. Security tools that are not fully deployed or tuned do not protect the AI workload any better than they protect anything else.
AI activity is visible to security operations
Once live, the AI system has to be seen. Its requests, its outputs, the data it touched and the actions it took should land in the same monitoring the rest of the environment uses, so that unusual behavior can be detected and responded to.
That means integrating AI activity into security monitoring and analytics, including the AI system in exposure and vulnerability management, and covering it in incident readiness plans. A model that misbehaves is an incident, and the organization should know how it will respond before it happens.
The controls are in place before the first go-live
Before the first AI system reaches production, the following should be in place:
- A named owner for AI security and a review step before go-live.
- An inventory of the data the system can reach, checked against its classification and purpose.
- Identities and least-privilege access for users and for the agent itself.
- Application, API and workload protection around the model, plus AI-specific controls.
- AI activity in security monitoring, exposure management and incident readiness.
Putting these in from the design stage, not after development is complete, avoids retrofitting them under pressure once the system is live. It also lets the organization adopt AI with the same confidence it expects of every other production system.