← Blog

Credal alternatives: where the portal pattern stops working

Credal gives employees a sanctioned internal AI portal. The pattern works when employee AI usage is the entire scope. The pattern stops working when machine-to-machine, agent-driven, or vendor-embedded AI traffic must be covered by the same policy and the same audit trail. This piece walks through where the portal stops and what fills the gap.

ByParminder Singh· Founder & CEO, DeepInspect Inc.
Comparisons & Alternativesalternativescredalai-portalai-gatewayenforcement

Credal works as a sanctioned internal AI portal. The product is a corporate UI that employees use to query LLMs against approved corporate documents. The controls evaluate at the portal layer: who can use which model, with which documents, under which policy. For the population of employees that uses the portal, the controls hold. The pattern stops working when the AI traffic that needs to be covered exceeds what employees do in the portal.

I want to walk through three failure modes of the portal pattern, then the alternatives that pick up where the portal stops.

Failure mode one: developer and machine-to-machine traffic

The first place the portal pattern breaks is the developer team and the automation pipelines. Engineers call OpenAI from a Python script on a build server. CI pipelines run agentic workflows that call Anthropic. Scheduled jobs hit Bedrock for nightly summarization. The portal is not in any of those paths because the request never went through a browser.

The portal's audit log records portal sessions. Machine-to-machine calls do not produce portal sessions. The log shows nothing because nothing happened on the portal layer.

For a deployer under EU AI Act Article 12 (lifetime logging of all AI requests touching a high-risk decision), the audit population includes machine-to-machine. The regulator does not exclude "automation" from the high-risk classification because automation produces no employee session.

Failure mode two: agent and tool-use traffic

The second failure mode is the agentic AI surface. The team builds a customer-support agent that calls three tools: a knowledge base, a CRM, and a refund API. The agent runs as a backend service. Every tool call is an AI-initiated request.

The portal does not see the agent. The agent identity is a service account, not a portal user. The policy that should govern "the agent can read CRM data but cannot trigger a refund above $500" lives outside the portal because the portal is not in the agent's request path.

Per the OWASP Top 10 for Agentic Applications 2026, the agentic-skills layer is a new vulnerable component. The control point for that layer is the request path the agent uses, not an employee chat portal.

Failure mode three: vendor-embedded AI

The third failure mode is vendor SaaS that calls LLMs under the hood. The customer-service platform summarizes tickets with a model. The fraud tool ranks transactions with a model. The pricing engine scores risk. The customer never sees the prompt or the response because the LLM is inside the vendor's product.

The deployer obligation under Article 12 applies anyway. The lender owns the disclosure obligation regardless of where the AI ran. The portal does not cover vendor-embedded usage because the vendor is not calling the customer's portal.

What an alternative needs

The alternative to the portal pattern, when the AI surface exceeds employee chat, is a gateway in the HTTP path between any authenticated user or agent and any LLM. The five properties that matter:

  1. Coverage of machine-to-machine, agent-driven, browser-mediated, scheduled, and vendor-embedded traffic from one control point.
  2. Identity at the request layer for users, agents, and service accounts.
  3. Per-decision audit log, append-only and signed, retained per the deployer's regulatory profile.
  4. Policy that covers identity-bound access, data classification, redaction, tool-use, and response treatment.
  5. Sub-100ms overhead so the gateway is viable for latency-sensitive deployments.

DeepInspect

DeepInspect is a stateless policy gateway for any LLM. The deployment pattern is a proxy or sidecar in the request path. Identity travels with the request through OAuth, SSO, or signed agent identities. 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.

DeepInspect can sit in front of Credal. The portal continues to give employees a sanctioned UI. The gateway becomes the system of record across all AI traffic. The two products solve different problems and combine.

DeepInspect is the right alternative when the obligation is to produce a single per-decision audit trail across all AI traffic.

Other portal-pattern products

A few products share Credal's portal architecture:

  • Glean Assistant focuses on enterprise search plus AI chat against indexed corporate documents. The portal pattern applies. Coverage stops at non-portal traffic.
  • Writer Enterprise focuses on generative writing for marketing and sales teams. Controls evaluate inside the Writer product. Same portal-boundary limitation.
  • Internal ChatGPT Enterprise / Microsoft Copilot deployments offer corporate-controlled chat surfaces. Coverage stops at the chat product's boundary.

Each is a coherent purchase for the use case it serves. None substitutes for a request-layer gateway when the audit population includes machine-to-machine and vendor-embedded traffic.

Detection-layer alternatives

A different category of tool sits as a side-call from the application: Lakera, Aporia, Protect AI. The integration pattern is application-mediated. Every AI request site in code has to call the detection layer. Coverage of identity at the request layer and per-decision audit logging is application-side, not gateway-side.

Detection layers fit teams with a small number of model call sites and the engineering capacity to integrate the detection model at each one. Detection layers do not fit teams whose audit obligation extends to call sites they do not own (vendor-embedded, agent-driven, scheduled jobs).

Evaluation checklist

When evaluating Credal alternatives against a true compliance-grade requirement:

  1. Can the alternative produce a per-decision audit record for an OpenAI direct call from a developer's Python script?
  2. Can the alternative resolve an agent identity in a CI workflow and enforce policy?
  3. Can the alternative intercept a vendor SaaS call that uses the customer's API keys?
  4. Can the alternative block a tool call from an agent that violates policy?
  5. Can the alternative export, on regulator demand, every AI decision touching PHI in the last 90 days?

A portal answers none. A gateway answers all five.

Where DeepInspect fits

If your evaluation of Credal surfaced the question "what about the AI traffic outside the portal," DeepInspect is the answer. The gateway sits in the request path. Identity attaches at the gateway. Policy evaluates at the gateway. The audit log is per-decision and signed.

For a deployer chasing the EU AI Act August 2 deadline whose AI surface includes more than employee chat, let's talk today.

Frequently asked questions

Can Credal and DeepInspect run together?

Yes. Credal continues as the employee portal. DeepInspect sits in front of all AI traffic, including the portal's outbound model calls. The audit log lives in DeepInspect; the user experience lives in Credal.

Is the portal pattern wrong?

No. The portal is a coherent product for sanctioned employee AI usage. The pattern stops working when the audit obligation extends past employee chat. The fix is to add a gateway, not to drop the portal.

What is the lift to deploy a gateway?

The gateway terminates the model call. Existing applications point their OpenAI / Anthropic / Bedrock client at the gateway URL. Identity flows through the existing OAuth or SSO setup. Initial coverage is typically days, not months.

Which alternative fits a regulated industry?

For financial services under DORA, healthcare under HIPAA, or any deployer of a high-risk system under the EU AI Act, the per-decision audit log is the artifact the regulator expects. A gateway-pattern alternative produces that artifact across al