Elias Virtanen
October 16, 2026
8 min read
Developers work in Cursor, Claude Code, Codex, and other AI-assisted environments. Business teams experiment with app builders, automation tools, AI browsers, and copilots. Employees connect models to internal systems through MCP servers. Some of those tools run inside a browser, some operate as desktop applications, and others execute locally with access to files, credentials, terminals, and authenticated enterprise sessions.
Don’t miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
The CISO Approval Test for an AI Workspace
Before comparing vendors, it helps to define what “approved” should actually mean.
A security review should be able to answer questions like these:
A platform does not necessarily have to solve every AI security problem in the enterprise. It does need a clearly defined enforcement point.
6 AI Workspace Security Platforms CISOs Can Evaluate
1. Pluto Security
Pluto Security is purpose-built around the idea that AI has turned ordinary endpoints into programmable workspaces.
Instead of concentrating only on browser-based chatbot usage, Pluto focuses on the broader environment employees now build in, including AI coding tools, AI app builders, autonomous agents, local and remote MCP servers, extensions, applications, and the artifacts those systems create. The platform is designed to give security teams visibility into what is actually running on endpoints, how those components connect, what permissions they inherit, and what enterprise resources they can reach.
That endpoint emphasis matters because agentic tools frequently operate under a user’s existing security context. An AI agent may inherit SSO sessions, cached cloud credentials, Git access, local files, environment variables, or Kubernetes configuration without appearing to the identity system as a separate actor. Pluto’s security research highlights this authorization gap, where legitimate user credentials can effectively become the permissions available to an autonomous agent.
Pluto combines discovery with contextual risk and runtime enforcement. The goal is not simply to identify an unapproved AI tool but to understand whether that tool, agent, integration, or artifact creates meaningful exposure and apply controls when the risk appears. The platform can also bring supported enterprise AI activity, including Claude Enterprise usage, into common governance and audit workflows.
For a CISO, that creates a practical approval model: employees can continue using modern AI building tools while security retains visibility into the endpoint, the AI ecosystem around it, and the actions that conventional endpoint controls may not understand.
2. Harmonic Security
Harmonic Security is centered on governing how employees and agents interact with AI while preventing sensitive information from leaving the organization.
Its approach begins with AI usage intelligence. The platform can discover AI tools used across the workforce, including sanctioned products, unapproved applications, embedded AI functionality, and agentic workflows. Harmonic’s Explore product provides prompt-level visibility across more than 1,000 applications and adds risk information about individual tools, including how they handle customer data.
The platform’s main differentiator is contextual data protection. Rather than depending primarily on static patterns or regular expressions, Harmonic uses purpose-built models to interpret the meaning and intent of an interaction. That allows policies to differentiate between normal business content and information such as proprietaryd records before that information reaches an external AI service
3. LayerX
LayerX approaches AI workspace security from the interaction layer, with the browser and adjacent user workflows serving as a central enforcement point.
This is relevant because a large portion of enterprise AI adoption occurs inside ordinary work sessions. Employees use dedicated AI websites, AI capabilities embedded inside SaaS platforms, browser extensions, copilots, and increasingly browser-based agents. LayerX provides visibility into those interactions and can enforce policy during the session rather than depending only on network-level controls.
Its 2026 AI usage data illustrates why this layer matters. LayerX reports that almost half of observed enterprise AI activity occurs outside corporate governance through personal identities, while AI browser extensions have become another importantsions, which can give them access to browser content, sessions, and other sensitive information
4. Grip Security
Grip Security approaches AI governance through the identity and SaaS layer.
Its SaaS Security Control Plane builds an inventory of applications and links those applications to the identities using them. The platform is designed to find managed and unmanaged SaaS, shadow AI, rogue cloud accounts, OAuth connections, and other identity relationships that may not appear in the organization’s formal application catalog.
This is particularly useful when the problem is not simply an employee visiting an AI website. Modern AI tools can be connected to enterprise systems through OAuth, service accounts, tokens, SaaS integrations, and non-human identities. A tool may appear harmless until it receives permission to access email, documents, CRM records, repositories, or another SaaS application.
Grip maps those relationships so security teams can evaluate AI usage in the context of identity and access. OAuth scopes can be categorized by risk, while policy-based automation can be used to revoke or reduce inappropriate access.
5. SentinelOne Prompt AI Security
SentinelOne’s Prompt AI Security capabilities are based on the technology acquired with Prompt Security and now form part of a wider strategy for securing generative and agentic AI.
The platform provides visibility into employee use of AI across browsers, desktop applications, IDEs, terminal-based assistants, APIs, and custom workflows. It can identify both approved AI tools and shadow usage while recording contextual information about prompts, responses, users, and the data involved.
That visibility is combined with inline policy controls. Organizations can redact or tokenize sensitive information, prevent certain prompts from being submitted, coach users toward approved behavior, and block interactions that create unacceptable risk. Runtime protections also target AI-specific attacks such as prompt injection, jailbreaks, malicious outputs, and prompt leakage.
6. Palo Alto Networks Prisma AIRS
Prisma AIRS is broader than a pure AI workspace security product, but its current architecture increasingly addresses the same enterprise control problem from an AI platform perspective.
The platform provides discovery across AI applications, agents, models, and related components, followed by posture assessment and runtime protection. Its AI Gateway creates a centralized enforcement point between models, AI applications, agents, MCP tools, and agent-to-agent interactions. Security teams can use it to understand which models, users, applications, and agents are active and enforce policies over model access, tool usage, prompts, responses, and sensitive information.
Agent identity is a particularly significant component. Prisma AIRS Agent Security is designed to verify agent identities and enforce fine-grained runtime controls, including least-privilege access and audit records for autonomous actions. This becomes useful as agents move beyond generating text and begin acting directly against enterprise data and systems.
A Practical Three-Level Approval Model
A useful AI governance program does not need to classify every tool as simply approved or prohibited.
It can use three operational levels.
Approved for General Use
These tools can be used broadly because their enterprise configuration, identity controls, data practices, and workspace permissions fall within established policy.
Typical restrictions might still prevent highly sensitive data or particular integrations, but ordinary usage does not require a security exception.
Approved With Workspace Controls
These products provide valuable capabilities but can create material exposure when connected to local files, repositories, MCP servers, external tools, or production systems.
Approval therefore depends on additional workspace security.
The organization might permit the core tool while monitoring extensions, constraining agent actions, validating MCP servers, preventing sensitive prompts, or restricting particular integration types.
Restricted to Controlled Environments
Some AI capabilities may require significant privileges or involve experimental tools whose behavior is not yet sufficiently understood.
Those tools can still be useful, but access may initially be limited to isolated development environments, defined datasets, non-production systems, or specific teams.
The purpose of this model is not to reduce AI adoption.
It is to avoid forcing security teams into a false choice between unrestricted access and a company-wide ban.
What Evidence Should Reach the CISO?
Security teams often spend significant effort evaluating an AI platform but provide leadership with a surprisingly weak approval packet.
A more useful decision package should contain evidence across several areas.
Inventory: Which tools, agents, extensions, MCP servers, and AI services are currently in use?
Ownership: Which employees or teams use them, and who is responsible for each approved deployment?
Permissions: Which files, SaaS applications, APIs, credentials, repositories, and enterprise systems can they reach?
Data exposure: What sensitive information has been observed moving into AI environments, and which policies prevent inappropriate transfer?
Agent activity: Which autonomous actions can occur, and can those actions be attributed separately from the human user?
Enforcement: Can security stop or modify a dangerous interaction in real time, or does the platform only alert after it occurs?
Auditability: Are there logs showing the tool, user, agent, data flow, policy decision, and outcome?
Change detection: Will security know when a new extension, integration, MCP server, permission, or AI capability changes the original risk assessment?
A CISO approving an AI workspace should not have to rely on the assumption that the environment will continue looking like it did on the day of the security review.
Static Approval Breaks Down Fast in AI Workspaces
Traditional business software tends to change in relatively predictable ways.
An AI workspace does not.
A user can install an MCP server in the morning, add another coding agent after lunch, connect a new SaaS tool later that day, and generate an internal application by the end of the week.
The security properties of the workspace may now be completely different even though the originally approved AI product has not changed.
This makes continuous discovery and enforcement particularly important.
Security teams need to know when:
- a new AI application appears;
- an employee switches from an enterprise account to a personal account;
- an AI browser extension gains powerful permissions;
- a new MCP server is installed;
- an agent receives access to additional tools;
- an internal application created through AI becomes externally accessible;
- sensitive information starts flowing into a previously low-risk tool;
- an employee-built automation remains active after its original owner leaves;
- agent behavior changes after a model or configuration update.
The approval therefore has to apply to a controlled workspace state, not permanently to a product name.
Where Existing Security Tools Still Fit
AI workspace security does not replace EDR, DLP, IAM, CASB, SSPM, SASE, or application security.
Each still covers important parts of the enterprise environment.
The difficulty is that AI combines those domains in new ways.
An agent may perform a legitimate process under a legitimate user identity while producing an outcome the user never explicitly requested. An MCP server can be ordinary local software while simultaneously acting as an interface between a model and enterprise credentials. Sensitive information can move through conversational context without matching a traditional DLP pattern.
Workspace security therefore works best as a contextual layer across existing controls.
IAM still establishes who the user is.
EDR still protects the endpoint against malware and known attacker behavior.
DLP still protects defined categories of sensitive information.
SaaS security still governs cloud identities and application configurations.
AI workspace security adds the missing questions: Which AI is acting, what does it understand, what can it reach, and should this specific action be allowed?
