Over this past year, we've spent a lot of time with customers talking through how they're adopting AI and the security concerns that come with it. One concern has grown steadily throughout the year. Security leaders want to know who they need to hire to secure AI, what experience that person should bring, and where to find them. Some tell us they don't have the staff to act on what they already see in their environments. When we gathered with customers at Protect 2026 in San Diego last week, hiring for AI security was one of the most talked-about topics of the conference.
Who to hire is a harder question than it sounds, because most organizations haven't settled who owns AI security in the first place. When Proofpoint's 2025 State of AI Security report asked 275 executives at large enterprises who holds primary responsibility for AI security, the CIO came out on top at 29%. Chief Data Officers followed at 17.4%, infrastructure and operations teams at 15%, CISOs at 14.5%, CTO and engineering at 12.3%, and shared responsibility at 10.1%.
Ownership is scattered because the work draws on three kinds of experience that rarely sit on one team. The person who leads an AI security program needs to understand the organization's data, its applications, and how the business operates.
Security Teams Are Inheriting AI Security Work Before They Are Ready for It
The hiring question has become urgent because the work is already landing on security teams. ISACA's 2026 State of Cybersecurity report found that 51% of cybersecurity professionals are now involved in developing, onboarding, or implementing AI solutions, up from 40% in 2025 and 29% in 2024. Fifty-six percent say they or someone on their team helped develop the policy governing AI use in their organization.
Those teams are taking on the responsibility before they are prepared for it. The same report found that 64% of enterprises have not conducted any AI-related incident response exercises, and 48% of respondents either don't know whether their organization has AI incident playbooks or say it has none. ISACA's 2026 AI Pulse Poll found that 56% of digital trust professionals don't know how long it would take to halt an AI system during a security incident, and only 12% say their organization has a documented, regularly tested process for shutting down or overriding an AI system. Those are the responsibilities a new hire will inherit.
An AI Security Program Needs Three Kinds of Experience
Responding to an AI incident, writing an incident response playbook for AI, and deciding when to halt an AI system all depend on knowing what an AI feature or agent did and whether it should have. That knowledge comes from the three kinds of experience a new hire needs. Data security experience shows what an interaction can expose, application experience explains how an AI feature or agent behaves, and business process knowledge determines whether an AI action violated business policy.
-
Data Security Experience Tells a Team What an AI Interaction Can Expose: Data exposure is the AI incident organizations expect most. In Proofpoint's 2025 State of AI Security report, 50% of respondents named data leakage through generative AI tools as the AI-related incident most likely to affect their organization in the next 12 months, ahead of shadow AI at 49%. Much of that leakage happens through legitimate use. An employee pastes a customer record into an AI assistant to draft a summary, or an agent retrieves a file it has permission to access and passes it to an external model.
AI tools and agents act on enterprise data. They retrieve it to answer prompts, pass it to external models, and write it into other systems. Agents access that data through connectors and MCP servers with the permissions they were granted. Someone with data security experience knows where sensitive data lives, how it's classified, which regulations govern it, and which users and systems are authorized to access it. That person can judge whether a given interaction put data at risk and can set the data access policies AI tools and agents operate under.
Data loss prevention experience applies to sensitive data in prompts and AI outputs, data classification experience applies to the data AI tools and agents access, and data access governance experience applies to deciding which data each agent is authorized to access. The Chief Data Officer's 17.4% share of AI security ownership in our research shows how closely organizations already connect AI security to data. Data risk and AI risk are distinct, and they intersect wherever AI accesses enterprise data. That intersection grows with every tool and agent a team connects to enterprise systems.
-
AI Features and Agents Behave Like Applications: Most enterprise AI arrives inside applications. Copilots are embedded in the SaaS tools employees use every day, chatbots answer customers on public websites, and agents call APIs and MCP servers to complete tasks. Each has its own inputs, permissions, and outputs, and people who already test authentication, authorization, and API exposure know how to reason about them. Help Net Security made this case in January. It argued that AppSec teams should treat AI agents as applications by default and need visibility into how agents behave as they operate, including unexpected API calls, data movement, and action chaining. OWASP publishes a Top 10 for LLM Applications and a Top 10 for Agentic Applications, and both extend threat categories that application security teams already work from.
-
Business Process Knowledge Tells a Team When AI Breaks a Policy: One of our banking customers holds its employees to a conduct policy written for finance professionals, and as employee conduct policies in financial services often do, it prohibits gambling. The bank enforced that part of the policy by blocking network access to gambling websites. When employees started using AI tools, the bank found they could still access gambling sites through an LLM or an AI agent, because the network block didn't account for AI. The policy was violated anyway, and only someone who knew the policy and why the bank prohibits gambling would recognize the AI interaction as a violation of it. The right hire knows the organization's business policies well enough to see when AI violates one.
The Strongest Candidates May Already Work for You
Before opening a requisition, look at the teams that already hold each kind of experience. Data security, privacy, and data governance teams are already taking on AI work. The IAPP reports that 68% of privacy professionals have added AI governance to their responsibilities, and its AI Governance Profession Report 2025 found the privacy function holds primary responsibility for AI governance at 22% of organizations. These professionals already know where regulated data lives and how the organization is allowed to use it.
Application security engineers perform threat modeling, authorization testing, and input validation reviews every day, and the OWASP lists for LLM and agentic applications give them a direct path into AI-specific risks.
The third kind of experience sits outside security entirely. Business analysts, process owners, and compliance leads in the lines of business know which policies govern how work gets done. They are the people who would recognize the bank's gambling policy in an AI interaction, and they belong in the program even if they never join the security team.
When the role does require an outside hire, the job description is the first place a search can go wrong. NIST's NICE program distinguishes securing AI from using AI to improve security work such as data analysis and anomaly detection, and a posting that asks only for AI experience will draw candidates for both. NIST built the NICE Framework to support hiring and workforce planning, and its December 2025 update revised the AI Security Competency Area, which now includes 70 knowledge statements and 20 skill statements. Those statements give a hiring manager specific language for describing the work of securing AI. Credentials offer another signal. ISACA's Advanced in AI Security Management (AAISM) credential is open only to professionals who already hold a CISM or CISSP, and it covers AI governance and program management, AI risk management, and AI technologies and controls. A candidate who holds it pairs security management experience with AI-specific governance knowledge, though no credential replaces knowing your data, your applications, and your business.
One Hire Rarely Covers All Three Kinds of Experience
The profile is demanding. The right person knows the organization's data well enough to judge what an interaction exposes. They understand its applications well enough to reason about how AI features and agents behave inside them, and they know the business processes well enough to recognize when an AI action violates business policy. Few candidates bring all three, which explains the ownership split in our research. Each function in that survey holds part of the experience the program needs.
The practical answer is to hire or appoint a lead who is strong in one of the three areas and name partners from the other two. A lead from data security, for example, would work with a named partner from application security and with process owners from the business units that depend most on AI. Each role needs defined responsibilities. The data security lead decides which data AI tools and agents may access and how that data is classified. The application security partner reviews new AI features and agents as they connect to enterprise systems. The business owners define the policies AI has to follow in their part of the organization. Decision rights need the same clarity, including who approves a new agent, who writes policy, and who investigates when an AI action violates it. With those responsibilities documented, every function that shares ownership of AI security knows what it is accountable for.
Teams That Cannot Add Headcount Need Enforcement They Can Automate
The team structure above puts business owners in charge of defining the policies AI has to follow and the security team in charge of enforcing them. Between those two steps, someone has to convert each written policy into technical controls. That is the work a small team can't keep up with, and some of the organizations we work with can't add headcount to take it on.
Semantic Business Policies, which we introduced at Protect, turn written business policies into runtime controls automatically. At the bank in our earlier example, an administrator could enter the policy the business defined, "Do not allow interactions with gambling websites," in plain English. Proofpoint AI Security interprets the business intent behind the policy, identifies the tools an employee or agent could use to access gambling websites, such as a web search tool like Brave Search, and generates the runtime controls to enforce the policy across employees and agents. The business owner defines the policy, and no one on the security team has to translate it into technical controls.
When customers ask us who they need to hire for AI security, our answer starts with the experience they already have. Their application security engineers understand how AI features and agents behave, their privacy and data governance teams know what data AI tools and agents access, and their business owners know which policies AI has to follow. The hire that completes the program is a lead who takes ownership of AI security and gives each of those teams a defined role within it.
To learn more, visit https://www.proofpoint.com/us/platform/ai-security