AI Security Platforms Are Governance Boundary Resources

Gartner projects that 50% of enterprises will adopt AI security platforms by 2028. I nodded when I read that. Every organization I have talked to is trying to figure out what to do about employees using ChatGPT, GitHub Copilot, and a dozen other AI tools without telling IT. The second number is the one that made me stop. Gartner also projects that 80% of unauthorized AI transactions will stem from internal policy violations, not external attacks. I read that sentence three times. Not because I disagreed with it. Because it confirmed something I had been circling around for months. The threat model for AI is not the hacker. It is the employee. And that changes what kind of product an AI security platform actually is.

An AISP is a product category that consolidates controls for AI services and custom AI applications. It sits between the user and the model, monitoring inputs, checking outputs, enforcing policies, logging activity. On the surface it looks like a security product. It blocks things. It alerts. It integrates with the existing security stack. But the internal policy violation number changes the frame. If 80% of the unauthorized behavior you are trying to stop originates from inside the organization, your system is not primarily protecting a perimeter. It is enforcing a set of rules about which AI tools people may use, for what purposes, and with what data. That is not a firewall problem. That is a governance problem.

I have been spending a lot of time with platform governance theory recently. I wrote about platform governance before and the argument there was that platforms govern through boundary resources: the APIs, rules, interfaces, and tools through which a platform owner coordinates complementors while keeping control. Tiwana (2014) framed it as decision rights, control mechanisms, and ownership of interfaces. Parker, Van Alstyne, and Jiang (2017) showed that platforms create value by facilitating interactions, not by producing. The platform decides who wins because it controls the rules of participation.

Mayer, Kostis, Strich, and Holmstrom (2025) extend this logic into the GenAI context. They show that GenAI as a boundary resource reshapes platform governance through three specific challenges. The first is validation. When a complementor creates something with GenAI, the output needs checking in a way that traditional boundary resources do not require. The second is standardization. Generative outputs are flexible and hard to align with stable platform rules. The third is complementor-skill challenges. People need new abilities to work with GenAI-enabled resources, and not everyone has them. What Mayer et al. describe is not a security problem. It is a coordination and control problem inside a platform ecosystem.

I think AISPs map directly onto this framework. An AISP is a boundary resource that an organization, now operating as something structurally close to a platform, uses to govern how AI interacts with its infrastructure. But here is the important point. The AISP is not governing external actors. It is governing internal ones. The same 80% stat tells us that the complementors in this case are the organization's own employees, who are adopting AI tools the way platform complementors adopt new features: speed first, governance later. The validation problem from Mayer et al. applies directly: every employee GenAI interaction produces output that may or may not comply with organizational policy, and somebody has to check. The standardization problem applies: different teams use different AI tools in different ways, and the organization tries to align them with stable rules. The skill problem applies: employees do not necessarily know what they are authorized to do with AI, or even that the question of authorization exists.

This is where shadow AI enters the picture. I wrote about workarounds and shadow IT separately, framing them as evidence of system-task misfit rather than user failure. Shadow AI is the same phenomenon accelerated. Employees are not adopting unapproved AI tools because they are careless. They are doing it because the official process for getting an AI tool approved takes too long, or the official tool is not good enough, or they simply did not know they needed approval. The 80% internal policy violation rate is not a failure of security awareness. It is a failure of governance. The organization did not provide a boundary resource that made the authorized path easier than the unauthorized one. The AISP closes that gap by encoding policy into the interaction point itself.

Mohlmann, Gregory, and Henfridsson (2025) add the stakeholder side. They show that algorithms on content platforms govern stakeholder interactions and conflicts. Different groups have different goals: visibility, safety, monetization, fairness. Algorithmic governance manages those tensions through rules, ranking, moderation, and design. An AISP does exactly this for AI use inside an organization. It ranks requests by risk level. It moderates inputs that contain sensitive data. It enforces rules about which models can be used for which tasks. It mediates between the employee's goal for productivity and the organization's goal for compliance. The AISP is not a security tool that also does governance. It is a governance tool that looks like a security product because that is how the market buys it.

This reframing changes how we should evaluate AISPs. If you evaluate one as a security product, you ask: does it detect threats, does it integrate with the SIEM, does it scale to enterprise traffic. Those questions are not wrong but they miss the point. If you evaluate an AISP as a governance product, you ask different questions: does it reduce the effort of the authorized path compared with the unauthorized one, does it make policy visible to employees rather than hiding it in a document nobody reads, does it adapt to the fact that different teams have different legitimate AI needs. The evaluation criteria follow from what the product actually is.

I think prompt injection makes this concrete. Most security coverage treats prompt injection as a vulnerability, like SQL injection. Fix the input sanitization, patch the model, add a web application firewall rule. That framing is not wrong at the technical level. But it misses that prompt injection is so effective because there is no shared governance structure between the user, the model, and the organization. The organization has no boundary resource that tells the model what the user is authorized to do. The model does not know what policies apply. The user may not either. The prompt injection succeeded not because the security controls failed but because the governance structure was absent. When the AISP enforces policy at the point of interaction, the prompt injection becomes a governance violation before it becomes a security incident. That ordering matters.

The IS field's platform governance research predicted this years ago. The boundary resource literature has always been about how platform owners coordinate complementors while keeping control. What changed is that the complementors are now your own employees, and the boundary resource is an AI security platform. The theory was already there. The market just caught up.