← Blog

DeepInspect vs Credal: gateway architecture versus internal-AI portal

DeepInspect is a stateless policy gateway in front of any LLM. Credal is an internal AI assistant portal with controls bolted in around the portal product. The two get categorized together, but the enforcement boundary and the audit artifact are structurally different. This comparison walks through where each tool fits, what the per-decision log looks like, and which deployer profile each one serves.

ByParminder Singh· Founder & CEO, DeepInspect Inc.
Comparisons & Alternativescomparisoncredalai-gatewayai-securityenforcementaudit

The DeepInspect-Credal comparison comes up in two buying contexts. The first is a security leader looking for a tool to control AI usage across the enterprise. The second is a platform team looking to give employees a sanctioned internal AI app while keeping data inside the perimeter. The same word ("AI security") gets applied to both, but the two product categories sit on opposite sides of the enforcement boundary. I want to walk through where each one operates, what it produces as an audit record, and which deployer profile each one fits.

Enforcement boundary

DeepInspect sits in the HTTP path between any authenticated user or agent and any LLM. Coverage is universal because the gateway intercepts the model call regardless of which client originated it: a developer's Python script, a CI job, a customer-support agent's browser, a back-end automation, a vendor SaaS round-tripping through an embedded LLM. The gateway enforces identity-bound policy on every call.

Credal is, at its core, an internal AI portal. The product is the front door employees use to query LLMs through a corporate UI that Credal hosts. Controls are evaluated at the portal layer. The architecture is closer to "secure ChatGPT for the enterprise" than to "policy enforcement across the AI request layer."

The implication is structural. Anything that goes through the Credal portal can be controlled at the portal. Anything that does not go through the Credal portal sits outside Credal's enforcement boundary. Developer API calls to OpenAI, agentic workflows hitting Anthropic, vendor SaaS calling Bedrock with the customer's keys, scheduled jobs on a build server: none of that traffic touches the portal.

What the policy actually evaluates

DeepInspect evaluates policies at the request layer. The policy inputs include the resolved identity (human user, agent identity, or service account), the model and endpoint, the prompt content after data classification, the response after policy treatment, the data destination, and the policy version that governed the decision. Each request gets the same evaluation regardless of which client made it.

Credal's policy evaluates the user action inside the portal. Did this user have permission to query this model with this document attached? The model identity, the user identity, and the document inventory live inside the portal. Outside the portal, the policy does not apply because there is no portal control point on those requests.

Identity context

EU AI Act Article 19 requires identification of natural persons involved in result verification. DeepInspect resolves identity at the gateway through SSO, OAuth tokens, or signed agent identities. The principal attached to the audit record is a known human, agent, or service account.

Credal resolves identity inside the portal through corporate SSO. For portal traffic, the principal is clean. For non-portal traffic, Credal does not see the request and cannot identify the principal.

This is the gap that breaks regulatory coverage. A regulator will not accept "the employees we know about used the portal" as the evidence of a covered system. The regulator will ask which requests touched the high-risk system. That population includes everything outside the portal too.

Audit log granularity

DeepInspect writes a per-decision record for every AI request that crosses the gateway. The record includes the principal, model, endpoint, redacted prompt, response treatment, policy version, decision outcome, and timestamp. The log is append-only and signed. Six-month minimum retention satisfies Article 19; financial-services and healthcare retention requirements stack on top.

Credal logs portal interactions. Each conversation in the portal produces a usage record. The record is structured around the user session, not the per-request gateway decision. For portal-mediated traffic it is detailed. For non-portal traffic the log does not exist because the traffic did not pass through Credal.

Vendor and embedded AI

A material share of AI usage in enterprises flows through vendor SaaS tools that embed LLM calls under the hood. The customer-service platform summarizes tickets with a model. The pricing engine scores risk with an LLM. The fraud tool ranks transactions with a model. The enterprise's environment never sees the prompt or the response. The deployer obligation applies anyway.

DeepInspect can be placed in front of vendor egress, in front of the vendor's API, or at the inference path where vendors call models on the customer's behalf with the customer's keys. The coverage extends to traffic that the user never directly initiated.

Credal does not cover vendor-embedded AI usage. The vendor is not calling Credal's portal. The portal is not in the path.

Coverage profile

For an organization that wants employees to have a sanctioned AI app and is comfortable with the constraint that controlled AI usage equals portal usage, Credal is a coherent product. The buying logic is "give people a place to go so they stop using random tools." That works when the population is bounded and the buyer can enforce portal-only usage by policy.

For an organization that has to produce an immutable per-decision audit record across all AI traffic, that must cover machine-to-machine and vendor-embedded usage, and that has regulatory exposure (EU AI Act, HIPAA, DORA, Fannie Mae LL-2026-04), the portal is not the answer. The gateway is.

DeepInspect

DeepInspect is the gateway in front of any LLM. The deployment pattern is a proxy or sidecar at the request layer. Identity travels with the call. Policy evaluates at the gateway. Decisions write to a per-decision audit log that is append-only and signed. End-to-end overhead measures under 50ms in production tests.

For a deployer chasing the EU AI Act August 2 deadline, a healthcare provider running clinical LLMs, or a bank that needs to satisfy DORA's third-party AI register requirement, DeepInspect is the architecture the regulation expects. The portal is a sub-case the gateway can sit in front of.

If you are evaluating Credal as your AI control surface and your obligations extend past the portal, let's talk today.

Frequently asked questions

Can DeepInspect sit in front of Credal?

Yes. Credal can run as one of the model clients the gateway covers. The portal continues to give employees a sanctioned UI; the gateway becomes the system of record across all AI traffic. This pattern is common in pilots where the portal is already live.

Does Credal log AI usage outside the portal?

No. Credal's audit and reporting cover portal sessions. Traffic that does not pass through the portal does not appear in Credal's records.

Which tool does a HIPAA-covered hospital need?

For clinical AI under HIPAA, the per-decision audit record is the artifact OCR will ask for during a complaint review. DeepInspect produces that record across portal, EHR-integrated, vendor-embedded, and direct API usage. Credal covers the portal slice.

Can we use both?

Common pattern: Credal for the sanctioned employee portal, DeepInspect as the gateway sitting in front of all model traffic. The combination keeps the user experience of an internal AI app and gets a single per-decision audit trail across the whole AI surface.