The Question
You have decided to build an AI security function. The budget case is approved, the program architecture is defined, the tooling decisions are in progress. Now the organizational question: who builds and runs this?
Does AI security live inside the existing SOC? Does it report to the CISO directly? Does it sit between the security team and the AI/ML engineering team? Who has the skills you need, and where do you find them if you do not have them internally?
The organizational design of an AI security function directly determines its ability to address the full OWASP Top 10 for Large Language Model Applications and the five agentic threat classes — because different threat classes require different expertise, and that expertise may not exist in a traditional security team structure.
Why This Matters Now
The 2026 Stackcurve AI Security CURVE™ Report documents that roughly 30% of enterprises have not held a single formal discussion about agentic AI security. For organizations moving from that baseline to an active AI security function, the organizational design question is the first practical decision after budget approval.
The challenge is that AI security sits at an intersection that existing organizational boundaries were not designed for. Traditional security teams understand threat detection, incident response, and compliance — but many lack the ML and LLM-specific knowledge to assess AI model behavior, understand agentic threat classes, or evaluate AI security vendor claims. AI and ML engineering teams understand the technology but typically lack the adversarial mindset, the incident response experience, and the regulatory context that security functions provide.
The leading enterprises are resolving this intersection deliberately — not by assigning AI security to whichever team already exists, but by building a hybrid function that combines both knowledge bases.
What the CURVE™ Data Shows
The 2026 Stackcurve AI Security CURVE™ Report's strategic recommendations include an explicit call for enterprises to establish an AI security function distinct from traditional SecOps within 90 days of first agentic AI deployment. The rationale is operational: AI security incidents require different analyst skills, different detection rules, different containment procedures, and different recovery protocols than traditional security incidents.
The vendors at the Frontier tier of the CURVE™ — Palo Alto Networks, Microsoft, CrowdStrike, and Cisco — have each built dedicated AI security teams internally that are separate from their general security operations. The structure they have adopted — which Stackcurve assessed across multiple engagements — consistently combines three roles: security engineers with AI/ML fluency, ML engineers with security mindset, and a governance lead with regulatory expertise.
The full strategic recommendations are in the 2026 AI Security CURVE™ Report — free to download.
The enterprises with the most mature AI security postures are not necessarily those with the largest teams. They are those with the right skills in the right structure — and a clear mandate that AI security is a first-class security function, not a side project of the existing SOC.
The Gap Most Buyers Miss
The most common organizational failure in AI security is assigning ownership without authority. A security engineer is told to "own AI security" on top of their existing responsibilities, without dedicated budget, without the organizational authority to require AI teams to submit deployments for security review, and without the time to develop the AI/ML knowledge the role requires.
This produces an AI security function that is nominal — it exists on paper and in org charts — but has no actual capacity to improve the organization's AI security posture. The person designated as AI security owner is aware of the gaps and powerless to close them.
The organizational prerequisites for a functional AI security role:
Dedicated capacity — AI security cannot be a part-time addition to a full-time traditional security role. Even a 50% dedicated resource is more effective than a 100% assignment with no time available. The scope of the problem — inventory management, vendor evaluation, policy development, incident response planning, red team coordination — requires dedicated attention.
Cross-functional mandate — the AI security function needs authority to require AI deployment teams to submit new systems for security review before production launch. Without this mandate, AI security becomes advisory rather than operational: teams may choose to engage, or may not. Authority requires executive sponsorship and explicit organizational policy.
Access to AI/ML engineering — the AI security function needs a working relationship with the teams building and deploying AI systems. Threat models are better when security engineers understand the system architecture. Detection rules are better when ML engineers understand what anomalous behavior looks like in their models. This relationship is organizational, not just technical.
Building the Function: Three Models
Model 1: Embedded security engineer in AI/ML teams A security engineer with AI/ML fluency is embedded within each major AI/ML team — similar to how product security engineers are embedded in application development teams. This model provides the closest integration with AI development but requires rare dual-expertise talent and can result in inconsistent security standards across teams.
Best for: organizations with large, decentralized AI development programs where centralized oversight is impractical.
Model 2: Centralized AI-SOC A dedicated AI security operations center — separate from the traditional SOC — staffed with a mixed team of security engineers and ML engineers, with a dedicated threat intelligence and governance function. This model provides the deepest specialization and the most consistent standards but requires the most organizational investment and is the hardest model to staff.
Best for: enterprises with significant agentic AI deployments, large AI security risk profiles, or regulatory requirements for formal AI security governance.
Model 3: Augmented SOC with AI security specialization The existing SOC adds an AI security specialization track — a subset of analysts who develop AI security expertise and own the AI security alerting, response procedures, and vendor relationships, while remaining integrated with the broader SOC for shared telemetry and coordinated response. This model is the most practical entry point for most enterprises.
Best for: organizations building an AI security function from a traditional SOC baseline, where the organizational investment in a dedicated AI-SOC is not yet justified by the AI deployment footprint.
Questions Your Buying Team Should Be Asking
1. Where does AI security ownership currently sit in our organization? If it is not clearly owned — if the answer is "probably the SOC" or "probably the AI team" without a designated owner — that ambiguity is itself the first problem to solve. Ownership clarity precedes everything else.
2. What skills does our designated AI security owner have, and what do they need? Assess honestly: does the person (or team) you are designating have both security expertise and AI/ML fluency? Identify the specific skill gaps and build a development or hiring plan to close them.
3. Does the AI security function have authority to require deployment reviews? This is the mandate question. Without formal authority to review AI deployments before production launch, the function is advisory. The authority needs to be defined in policy and supported by executive sponsorship.
4. How does the AI security function interface with AI/ML engineering? Define the working relationship — review process, escalation paths, shared tooling — before it is needed for an incident. The incident response will be faster if the relationship exists before the incident.
5. What is the hiring profile for AI security talent, and where do we find it? AI security talent is rare and in high demand. The best candidates typically come from one of two backgrounds: security engineers who have developed ML/AI knowledge through self-directed learning or adjacent roles, and ML engineers who have moved into adversarial thinking through AI safety research or red teaming. Academic ML with no security background is a harder starting point than either.
The Stackcurve Take
The AI security organizational design question has no universal right answer — it depends on your AI deployment footprint, your existing security team structure, your regulatory context, and your available talent. What the research is clear on is that the organizational design matters as much as the technical controls, and the organizations that treat it as an afterthought produce nominal AI security functions rather than operational ones.
The minimum viable AI security organization is: one dedicated owner with a meaningful time allocation, an explicit cross-functional mandate backed by executive sponsorship, and a working relationship with the AI/ML engineering teams. That structure, even at small scale, can execute the five-pillar maturity model and deliver a genuine improvement in AI security posture.
The 90-day recommendation from the Stackcurve CURVE™ Report — establish a distinct AI security function within 90 days of first agentic AI deployment — is not aspirational. It reflects the pace at which agentic AI deployments create risk that the existing security function cannot see. The organizational capability needs to exist before the incident that requires it.
The 2026 Stackcurve AI Security CURVE™ Report is the research foundation for building your AI security program and making the sourcing decisions that follow. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.