Securing Claude with AiriaNewEnterprise

Claude reaches enterprise data through four distinct surfaces — the web browser, native apps, developer tools, and Cowork/agents. Each exposes a different interception hook, so each needs a different control point. This guide walks the build for all four, plus how to push every control down to the fleet via MDM.

The goal: define your DLP detectors, guardrails, and agent constraints once, then enforce them consistently at whichever layer each surface exposes.

The four surfaces

You shouldn't write four sets of rules for four surfaces. Define the policy once; apply it at each surface's interception point.

The sections below map onto these surfaces: §1 covers surfaces 02a + 03 + 04 (inference), §2 covers surface 01, §3 covers the tool side, §4 is the unifier that forces them onto the gateways from the device, and §5 covers surface 02b (mobile) out-of-band.

1 · AI Gateway — route the Claude app and Claude Code through Airia

Claude Code and the Claude desktop app both support a custom API base URL. Point them at the Airia AI Gateway and every prompt, completion, and tool call passes through Airia on the wire: DLP, prompt-injection defense, model allowlist, budgets, audit.

In the desktop app this covers all three of its surfaces: Chat, Cowork, and Code, so everyday chat is governed on the same terms as developer traffic.

Chat · Cowork · Code  →  Airia AI Gateway  →  Anthropic Claude
                              ↓  DLP · Prompt-injection · Agent constraints · Routing · Audit

A · Build the gateway (Airia side)

Choose how Claude usage is billed

Choose OAuth Passthrough when your developers already sign in to Claude Code with their own Claude plan and you want Airia governance on that traffic without a second API bill. Each developer stays signed in to Claude Code (/login), and the client sets only the x-airia-key header:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://<your-gateway-url>/anthropic",
    "ANTHROPIC_CUSTOM_HEADERS": "x-airia-key: <agk-user-key>"
  }
}

With OAuth Passthrough, leave ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN, and apiKeyHelper unset in every settings file, so Claude Code sends the user's own sign-in.

B · Wire the client — the Claude desktop app

Prerequisite: Claude desktop app version 1.13576.0 or newer, which adds the Allow Chat control, and a gateway configuration that uses the Airia Model Library or Use Customer's Anthropic Key (see Choose how Claude usage is billed).

C · Find your gateway base URL

Use this …/anthropic value everywhere a Claude client asks for a base URL: Gateway Base URL in Claude Desktop and ANTHROPIC_BASE_URL in Claude Code. Claude Code also accepts the value with a trailing slash (…/anthropic/), which is the form the Automate Setup script writes. In Claude Desktop, enter it without the trailing slash.

D · Push it down to the fleet (MDM)

Two surfaces, two managed-config mechanisms — deploy whichever your users run, or both.

2 · Browser extension — govern claude.ai in the browser

The Claude desktop app now routes Chat, Cowork, and Code through the gateway, but users can still open claude.ai in a browser tab, and that surface is not routable through the AI Gateway. The Airia Browser Extension is the control point: it's the one place Airia can intervene before the prompt leaves the device. It checks each prompt against your guardrail before the prompt leaves the device, and applies your domain rules to every AI site.

A · Check prompts before they're sent

Apply a guardrail to the Browser Extension and the extension checks each prompt against it before it's sent. The check runs on ChatGPT, Claude, Gemini, and Perplexity. Every other AI site is governed by the domain rules in step B.

Start the guardrail's filters in Audit so findings are recorded in Audit → Violations without interrupting anyone, then move individual filters to Block once you've reviewed them.

B · Set domain rules for every AI site

Go to Discover → Connect and click the Browser Extension tile to open the Browser Extension Policies. Each policy applies to the users and groups on its Assignment tab. Set a behavior per domain on the Domain Rules tab:

To send prompt bodies to Airia for analysis alongside your gateway traffic, turn on request body capture on the policy's Data Capture Settings tab. The extension redacts sensitive fields on the device before the body is sent.

C · Push the extension to devices

The extension is deployed like any managed browser extension — force-installed so users can't remove it:

The email address is a per-user value, so push it through a user-scoped policy rather than the device-wide one. On Windows, write it for each signed-in user, including people who sign in with an on-premises Active Directory account on hybrid-joined PCs.

For full force-install and managed-storage configuration steps across Chrome, Edge, Firefox, and JAMF Pro (macOS), see the Browser Extension MDM Deployment Guide.

D · Monitor claude.ai usage

Every request the extension sees on a matching domain emits a Shadow AI event — domain, method, actionTaken (MONITORED / WARNED / BLOCKED / REDIRECTED), redacted body, browser, user. Events from one tab session share a batchId. Surfaced in the Activity Monitor and the Shadow-AI events feed, alongside gateway violations — one feed across surfaces.

3 · MCP Gateway — govern the tool side

Routing inference through the AI Gateway doesn't govern the tools Claude calls. The MCP Gateway aggregates many MCP servers behind a single authenticated URL, manages all downstream credentials centrally, and gives IT one address to allowlist instead of dozens of local configs with plaintext keys.

Claude Code · Cowork · Cursor  →  Airia MCP Gateway  (one OAuth URL)
                                          ↓ manages all downstream auth
   [GitHub] [Atlassian] [Slack] [Snowflake] [Airia-hosted & remote servers]

A · Set it up

B · Push it down to clients

Distribute the gateway URL into managed client configs via the same MDM file drop as §1 — one MCP entry replaces every local server.

4 · Endpoint agent — force both gateways from the device

Pushing settings.json / config.toml per client works, but it's per-app and users with file write access can override it. The Airia endpoint agent (airiad) is the device-level unifier: deploy it once via MDM, and in enforce mode it rewrites both the LLM-client base URLs and the MCP server entries on the workstation to point at your Airia gateways — automatically, on every check-in.

A · Deploy via MDM

B · Observe vs Enforce

5 · Mobile & unenrolled devices — see what you can't proxy

Claude iOS / Android, and any desktop app you haven't enrolled in Third-Party Inference, do not honor a custom base URL. There is no inline interception hook short of TLS-inspecting SASE. So the play here is different: you can't block at the wire, so make every interaction visible, classify it, and remediate after the fact. Out-of-band: minutes, not days, but the detection (and deletion) is real.

For the desktop app this is a coverage question, not a product limit: an enrolled device routes Chat, Cowork, and Code through the gateway (§1). Use this section for the devices your MDM hasn't reached, and for mobile, where no enrollment path exists.

Claude iOS · Android · unenrolled desktop  →  Anthropic
                                  ↓ telemetry (out-of-band)
                              Airia → classify · detect · remediate (delete chat · alert · escalate)

A · Two ingestion paths — pick by Claude tier

Both feed the same Airia pipeline — capture → detect (PII patterns, "Confidential" markings, regulated data classes) → remediate (delete violating chat, notify the user, escalate to the AI governance committee). Configure both from one place: Audit → Usage → Claude Monitoring.

The same Claude Monitoring page also ingests OpenAI Codex CLI telemetry; see Monitoring Codex with Airia.

B · Turn it on

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/json",
    "OTEL_EXPORTER_OTLP_LOGS_ENDPOINT": "<tenant>/v1/ClaudeCodeOtelIngest/ingest",
    "OTEL_EXPORTER_OTLP_HEADERS": "X-API-Key=<otel-key>",
    "OTEL_LOG_USER_PROMPTS": "1",
    "OTEL_LOG_RAW_API_BODIES": "1"
  }
}

Closing the gaps

The build above covers all four surfaces. A few cross-cutting items still close real bypass paths.

• ① Block direct egress (critical). The gateway only enforces if users can't reach Anthropic directly. Block api.anthropic.com at the firewall / SASE layer — otherwise a developer unsets the env var and bypasses everything. A managed config file is the floor, not the ceiling.
• ② The Bash blindspot. Agent constraints intercept tool calls at the gateway — but Bash commands Claude Code runs locally never traverse it. Mitigate with Claude Code permission modes + ~/.claude/settings.json allowlist hooks. The on-device agent (§4) closes this at the OS layer.
• ③ Content DLP on claude.ai. The browser extension is domain-scoped. For real prompt-content visibility on claude.ai, turn on captureRequestBody and/or the Compliance API — that's where content-level DLP actually runs, post-submit.
• ④ Personal content in third-party mode. Provision the skills your users need as MDM-pushed files (see §1 B).
• ⑤ One policy library + weekly audit. Define DLP detectors and guardrails once and apply across all surfaces. Then audit the gateway feed weekly — any active developer with zero gateway traffic in a week is on PTO or bypassing.