Security & admin overview
The Wingman trust model in one page: what runs on your machines, what runs hosted, how identity flows through it all, and where the controls live.
Wingman is two execution worlds behind one sign-in. Chat is hosted: it answers, plans, and reviews with team knowledge. In a browser it has no route to your machine at all — the tools that could reach one stay switched off unless the desktop app is running and has an activated, online device connection. Agent Dev is the on-device agent in the desktop app: it edits files, runs terminals, and executes on the Axelera hardware in front of you. Every security question about Wingman starts by asking which side of that line you are on.
| Surface | Where it runs | What it can reach |
|---|---|---|
| Wingman Chat | Hosted deployment | Conversations, team knowledge, hosted tools. In a browser, nothing on your machine. Reaching your files, terminals, or an Axelera card needs the desktop app with an activated device connection — a browser session cannot turn that on. |
| Agent Dev | Your device, inside the desktop app | Workspace files, terminals, and Axelera hardware — governed by approval policies and a sandbox. |
| Local AI CLIs (Claude Code, Codex, Kimi) | Your device, using the CLI you installed and signed in | What the CLI can reach, plus Wingman tools over an authenticated MCP connection. |
Workspace administration requests
Workspace administration on hosted Wingman Chat — user management, content requests, and policy changes — is handled by Axelera. Contact your Axelera representative with administrative requests.
One session everywhere
Identity is one session, not many. You sign in once — Axelera employees with Microsoft Entra SSO, customer deployments with their own identity provider — and the desktop app, Chat, the dashboard panels, and local CLI connections all ride that session. Opening Chat from the desktop app hands the session over server-side; no tokens travel in URLs. Signing out tears the whole thing down, including CLI connections on shared machines.
Guarded agent execution
Agent execution is guarded by default. Every Agent Dev run has an approval policy (when the agent must ask you) and a sandbox (what it may write). The one gate that can switch those guards off — Full access and the Claude Vibe launch — is itself controlled by an application policy that administrators can lock.
Where the controls live
- Agent safety: Approval policies, sandbox levels, and the dangerous-bypass policy gate. Read this before allowing Full access anywhere.
- Identity & SSO: How enforced SSO works across desktop, chat, and CLI handoff — and what it deliberately disables.
- Data, privacy & telemetry: What data goes where: telemetry switches, the cookie banner, and what a feedback report actually contains.
- Deployment, fleets & self-hosting: Connect your own Supabase backend, split consumer installs from IT deployments, and pin versions at fleet scale.