DeepInspect vs Arthur AI: Observability, Guardrails, and Identity-Bound Enforcement

Arthur watches AI systems in production. It began in model monitoring, tracking drift and performance for machine learning models, and grew into a platform for LLMs and agents: an Agent Discovery and Governance product launched in December 2025 that finds AI across an environment through OpenTelemetry streams, MCP servers, network-layer analysis, and platform APIs, plus runtime guardrails that check prompts and responses for PII, hallucination, and toxicity. The company says its deployments safeguarded more than a billion tokens in 2025, and it open-sourced its evaluation engine for teams that want to score models directly.

That is observability with a guardrail layer bolted on, and it is a mature version of that idea. Someone has to see what the AI is doing and catch unsafe content before it lands.

Teams comparing Arthur to DeepInspect are usually weighing a monitoring-and-guardrails platform against an identity-bound policy layer. Both reach into live AI traffic, which makes the comparison worth doing carefully. I want to walk what each one evaluates, then show where the overlap ends.

TL;DR

Arthur is an observability and guardrails platform: it discovers AI systems, monitors models and agents, and inspects content at runtime for PII, hallucination, and toxicity. DeepInspect sits inline between authenticated callers and model providers, decides whether each request proceeds based on identity and data, and commits a per-decision audit record. One tells you what your AI did and screens content for threats. The other authorizes the caller and records the ruling.

Arthur: discovery, monitoring, and content guardrails

Arthur's platform has two motions. Observability instruments the application through telemetry, tracking token counts, latency, retrieval performance, and quality signals, and its discovery product surfaces AI systems a team did not know were running. Guardrails run in the request and response path, screening for sensitive data, hallucination, and unsafe output, and can block or self-correct content that trips a check.

The discovery breadth is the property worth naming. Finding shadow agents across OpenTelemetry, MCP servers, and network traffic is real work, and for a team that cannot yet answer how many agents are running, that inventory is the first thing they need. The related discovery problem is covered in how to find shadow AI.

The guardrails inspect content. They read a prompt or a response and decide whether either carries a data-exposure or safety pattern. That is a content-quality question, and it is a different question from whether the specific caller was authorized to make the call.

Content quality versus caller authority

DeepInspect is a stateless proxy sitting between authenticated users or agents and any LLM endpoint. Every call traverses it, and the decision happens before the provider sees the request.

The primary key is the difference. Arthur's guardrails ask whether the content of an exchange is unsafe. DeepInspect asks whether this authenticated identity, holding this role, may send this class of data to this model. A prompt with clean content and no injection can still violate policy, because the caller had no entitlement to the data it carries, and that case sits outside content inspection. Identity-first decisions are described in identity-aware AI gateway architecture.

The record is the second difference. Observability produces telemetry for an engineering team to monitor and investigate, which has genuine forensic value and no ability to prevent a violation at machine speed, a distinction developed in why AI security must be inline. DeepInspect writes a structured decision record for every request, keyed to identity and committed to storage the application cannot alter, built for an auditor rather than an analyst. That contrast is the whole argument in signed audit logs for AI requests.

Feature comparison

| Capability | Arthur AI | DeepInspect | |---|---|---| | AI discovery across an environment | Yes, a core strength | No | | Model and agent observability | Yes, core | No | | Content guardrails (PII, hallucination) | Yes, core | Content checks available | | Open-source evaluation engine | Yes | No | | Identity-bound per-request policy | No | Core | | Decision keyed to role and data class | No | Core | | Application-independent audit record | Telemetry | Core, tamper-evident | | Inline blocking of a request | On content | On identity and policy | | Model-agnostic across HTTP LLM endpoints | Yes | Yes | | Primary buyer | ML and platform engineering | Security and compliance |

The honest reading is that both reach live traffic and split on what they evaluate. Arthur discovers, monitors, and screens content. DeepInspect authorizes by identity and produces the independent record.

Where Arthur is the better answer

If the requirement is seeing every model and agent in the environment, tracking quality and drift over time, and catching unsafe content in the response, Arthur has depth in discovery and monitoring I would not try to match with a policy proxy. For a team whose first problem is visibility into what AI is even running, that is the right starting point.

I will state the part a committee might cut: if you cannot yet answer how many agents are in production, buy the discovery and observability before you buy an enforcement layer, because you cannot write policy for systems you have not found.

Where the gap opens

Two requirements move a team past what observability and content guardrails cover.

The first is authorization on clean traffic. An authenticated employee sending regulated data into an approved model, with no injection and no unsafe content, passes a guardrail. An identity-bound layer refuses it, because the employee's role carries no entitlement to move that data. This is the post-authentication gap, and content inspection does not close it.

The second is evidence independence. Observability records what a monitor observed. A regulator under the EU AI Act asks for a per-decision record of who was authorized, under which policy, on storage the deploying application never controlled. The retention and independence requirements are in EU AI Act Article 19 logging.

Pick Arthur AI if

• Your first problem is discovering and monitoring the AI already running.
• You want drift, quality, and performance tracking across models and agents.
• Content guardrails for PII, hallucination, and toxicity are a stated need.
• An open-source evaluation engine fits how your ML team works.
• Per-decision authorization evidence is already handled elsewhere.

Pick DeepInspect if

• Your exposure includes who may call the model with which data.
• An auditor or enterprise customer wants per-decision records tied to an identity.
• You need audit evidence independent of the application that generated the traffic.
• Policy must differ by role and be enforced independently of application releases.
• You operate under the EU AI Act, DORA, HIPAA, or a comparable mandate.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline between your users or agents and the LLM APIs they call. For every request and response, it evaluates identity, data classification, model authorization, and organizational policy, then makes a pass or block decision before the traffic reaches the model.

The record is the second half of the product. Every decision writes a structured entry containing the authenticated identity, the resolved role, the data classes found in the prompt, the policy version in force, and the outcome. That entry commits before the response returns, on storage the application cannot write to, which is what lets it serve as evidence rather than as telemetry. Enforcement adds under 50 ms in internal testing against inference times of 500 ms to several seconds. An observability platform and an identity-bound enforcement layer address different exposures and can run on the same traffic.

If you are facing the August deadline, let's talk.