​Why AI Security Needs More Than One Control Plane

Ofer Klein is CEO and co-founder of Reco, a provider of enterprise ecosystem and AI agent security.

gettyWe often talk about enterprise AI security as if it were a single discipline. In practice, it spans distinct operating environments, each with its own failure mode, owner and business impact.

It shows up in the SaaS tools employees use to move work across the business, in the customer-facing systems that retrieve data and trigger product workflows, and in the engineering environments where models, datasets, pipelines and vector stores are built and operated.

That spread has created a control-plane security challenge because risk now moves through connections among identity, data, permissions, workflows and infrastructure, rather than remaining confined to a single model, application or environment.

Because it is embedded in tools employees already use, including collaboration platforms, productivity suites, CRM systems, workflow automation and AI-enabled SaaS applications, workforce AI operates below the waterline. We’ve seen the adoption pattern before. A team finds a tool that removes friction, connects it to the apps where work happens and expands usage before security has a full picture of the access path created.

Employees aren’t trying to bypass security, but the AI layer still changes how business data flows. Like when a finance user connects an assistant to spreadsheets, contracts and procurement records to summarize vendor obligations. Or a sales team uses an AI feature to generate account updates from CRM notes and call transcripts.

Each use case has a valid business purpose. The exposure comes from the bridge between identity, application, data and workflow. Even though the employee is authorized to access specific information, the AI tool that inherits that user’s privileges can process sensitive content and move it into a new context. Traditional access reviews may confirm that the user had permission while missing the AI connection, OAuth grant or agent workflow that changed the risk.

AI-assisted systems are exposed to external users through support bots, virtual assistants and customer portals that retrieve information or take action on a user’s behalf, changing the trust boundary.

This risk is more visible because the interaction happens outside the organization. A customer-facing AI system may answer questions, search documentation, call APIs, open support tickets, update records or recommend actions. Once it connects to internal systems or product workflows, it becomes part of the application attack surface.

But the failure modes differ from those of workforce AI. Prompt injection, jailbreaks, retrieval abuse, cross-tenant leakage, unsafe responses and tool-call manipulation can directly influence the system. A support assistant connected to account data can expose sensitive information. And a generative search feature tied to internal documentation can surface restricted material.

When technical teams build, train, deploy and operate AI systems, AI sits deeper in the stack. It lives in notebooks, training data, model registries, embeddings, vector databases, pipelines, AI coding assistants, deployment environments and model APIs.

The adoption pattern is familiar here too. A team accelerates development with coding assistants, connects pipelines to data sources, experiments in notebooks and moves models or AI features toward production.

Each activity is justified. The exposure comes from the connections between code, data, models, infrastructure and deployment. A notebook may contain credentials. A pipeline may pull sensitive data into the wrong environment, while an AI coding assistant may introduce insecure code, unapproved dependencies or context leakage into external services.

Engineering AI risk often surfaces downstream, after a weakness has already moved into a product, customer workflow or production environment. By then, the business impact can manifest as delayed releases, compliance exposure, application vulnerabilities, data leakage, incident response costs or loss of customer trust.

While these three pillars overlap, the differences matter most at the point of enforcement. Workforce AI requires control over how employees, identities, applications and data interact. Customer AI requires control over external-facing behavior, from prompts and retrieval to APIs and tool calls. Engineering AI requires control over the infrastructure that supports AI delivery, including models, datasets, pipelines, cloud environments and software supply chains.

A single AI security initiative can coordinate the work, but it cannot treat every AI risk as the same operating problem. Decision rights have to be clear before risk turns into an incident, from revoking access to business data to stopping unsafe customer-facing behavior or halting an AI pipeline before it reaches production.

Security leaders need governance that holds up during an incident, audit or customer escalation. This requires clear records of approved AI use, documented risk decisions, accountable owners, defined escalation paths and a way to verify that controls are working as intended. Without that discipline, an AI program looks complete in a planning meeting but breaks down during an incident, audit or customer escalation.

​A practical starting point is to focus AI governance where failure would carry real business consequences. Uses that touch regulated data, customer records, financial approvals, source code or production systems deserve closer review than low-risk productivity tasks. That focuses attention where AI can affect revenue, compliance, customer trust or operational continuity.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?