Choose a workforce AI product mode, see how it runs, and understand which security control points can reach it. Open detailed research for comparisons, public vendor claims, pilot questions, and sources.
Simple overview
Choose one documented product mode
The diagram and security control table update together. Comparisons and vendor research stay in Detailed research.
Showing OpenAI workforce AI — ChatGPT Work — desktop
OpenAI
OpenAI workforce AI
ChatGPT Work — desktop
Available
Cloud work can use local files and applications through the desktop client with permission. The desktop connection creates a important local point where security controls can act even though model execution remains provider-managed.
01Managed endpointChatGPT desktop runs under device and application policy.
02Permissioned local accessThe user can grant access to local files and applications.
03OpenAI cloudThe provider processes the task and returns results.
Security control points at a glance
What each control point can—and cannot—see
Security control point
Can observe
Public sources do not prove
Where work runsHow the product runs
The desktop client provides controlled local file and application access to cloud work.
A product name alone does not establish where every step executes.
What the device permitsDevice and application controls
Client execution plus file, application, process, and network activity visible on the device.
Device controls do not inspect the provider-managed model or every server-side action.
What the provider governsProduct administration controls
Workspace settings, app permissions, identity, and user grants to local resources.
Provider controls do not establish independent endpoint, data, or security operations center (SOC) coverage.
What the AI is doingAI activity controls
Desktop AI use, prompts, local files, applications, destinations, and resulting actions.
Generic AI coverage claims do not prove inspection or enforcement for this execution mode.
What needs verificationLogging and response
OpenAI records correlated with endpoint, application-control, identity, and data events.
Available logs can still omit action detail or fail to join provider and endpoint events.
Five questions to validate in a pilotOpen the concise buyer checklistShowHide
01
Product-mode inventory and attribution
Identify the exact product mode, where it runs, the user or agent identity, device, connector, Model Context Protocol (MCP) server, and tool for every synthetic test session.
02
Control reach and enforcement
Prove which file, process, browser, network, connector, and tool actions each control can observe, allow, deny, or revoke without broad endpoint exceptions.
03
Sensitive and regulated data
Block or redact synthetic sensitive data and confirm eligibility, contract, retention, residency, and subprocessor scope for every service or feature that can receive it.
04
End-to-end investigation
Correlate provider, endpoint, browser, identity, data, connector, and AI-aware events into one defensible timeline.
05
Coexistence and residual protection
Run the workflow with required application control, endpoint detection and response (EDR), unified endpoint management (UEM), browser policy, and AI controls active; document every exception and the protection retained or restored.
Need more detail?
Compare product modes and review the supporting research
Detailed research adds an optional comparison, questions for each security control point, public vendor claims, pilot evidence requirements, and the complete source list.