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 03 + 04 (inference), §2 covers surface 01, §3 covers the tool side of 03 + 04, §4 is the unifier that forces 03 + 04 onto the gateways from the device, and §5 covers surface 02 (native + mobile) out-of-band.

1 · AI Gateway — route Cowork & Claude Code through Airia

Anthropic's developer surfaces (Claude Code, and Claude Desktop / Cowork via Third-Party Inference) all 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.

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

A · Build the gateway (Airia side)

B · Wire the client — Claude Desktop / Cowork

C · Regional gateway base URLs

Append /anthropic to your tenant's regional endpoint. Confirm the exact endpoint for your tenant with your Airia representative before rolling out.

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 app is now locked to Cowork + Code, 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.

A · Configure the policy

Flip captureRequestBody: true to ship the prompt body to Airia so the same DLP filters that run on your gateways apply to claude.ai traffic. The extension runs client-side PII scrubbing first ("N sensitive fields were redacted before truncation") — a clean privacy story.

UI: Secure → Runtime Security → Browser Extension Policies. Scope per group via groupIds.

B · Push the extension to devices

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

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

C · 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 · Native apps & mobile — see what you can't proxy

Claude iOS / Android, and any Claude Desktop chat you didn't lock to 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.

Claude iOS · Android · Desktop chat  →  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.

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.
• ④ Cowork "3P" Skills drop-out. Routing Cowork through a gateway puts it in Cowork-on-3P mode — no Anthropic account, so users lose personal Skills, history, memory, connectors. Working-as-designed, not user-fixable. Provision Skills as MDM-pushed files.
• ⑤ 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.