[Feature] Alice guardrail plugin

What Would You Like to See with the Gateway?

A guardrail plugin for Alice — alice.evaluate.

Plugin name: Alice

Description: Alice evaluates prompts and model responses against the policies an operator configures per application, and returns a verdict the Gateway enforces: allow the request, block it, mask the flagged spans before the model sees them, or record a detection and let it through. It screens both hooks — beforeRequestHook for the prompt and afterRequestHook for the completion.

Shape it follows:

• Credentials: apiKey (required, encrypted) and an optional apiBase for private deployments.
• One check, evaluate, on both hooks, with appId as a required parameter and an optional timeout.
• Verdicts: ALLOW proceeds · MASK substitutes at each returned index · BLOCK fails the check with the policy's own message · DETECT proceeds carrying a correlation id · anything unrecognized is reported as a check error, never as a pass.

Two things are worth flagging up front, since they are the parts that differ from the other guardrail plugins:

The application is a parameter, not a credential. Alice configures policies per application and a project usually holds several, so one API key fronts all of them — the application cannot be part of the credential. It is deliberately not read from context.metadata either: that comes from the caller's x-portkey-metadata header, so an application named there would let a caller point their own traffic at policies laxer than the ones configured for them. A check naming no application fails rather than being evaluated against a guess.

Credentials never leave the Gateway. context.request.headers carries the caller's Authorization and x-portkey-api-key in the clear, and a provider credential can ride along under a nested api_key or credentials. The plugin drops headers, credentials, api_key, apiKey, authorization and cookie by key name at every nesting depth while serializing the outbound copy, rather than by a fixed path list. Only that copy is affected — the real context continues down the pipeline untouched.

Every failure — transport, timeout, unreadable body, and a 4xx — is reported as a check error rather than as a pass, so failOnError is the single place that decides whether unscreened traffic proceeds.

Context for your Request

Alice customers fronting their apps with a Portkey AI Gateway currently have no way to run Alice's policy checks on that traffic — there is no alice guardrail today, so prompts and responses their policies would block or mask reach the model unscreened.

We have already done the equivalent integration for LiteLLM, which is merged: BerriAI/litellm#38898 (plugin) and BerriAI/litellm-docs#1088 (docs).

Both halves for Portkey are written and open as drafts, following plugins/Contributing.md:

• Plugin: #1791 — plugins/alice/{manifest.json,evaluate.ts,alice.test.ts} plus the plugins/index.ts registration. 35 tests, all mocked with no network; nothing outside plugins/ is touched and no dependency is added.
• Docs: Portkey-AI/docs-core#1056 — integrations/guardrails/alice.mdx, the docs.json nav entry, and a card in the partner list.

They are drafts for one reason, stated in both: the /v2/evaluate/portkey endpoint the plugin posts to is not publicly reachable yet, so a guardrail enabled against it today reports a check error on every request. That endpoint is built and going out on our side; we will mark both ready once it is live. Filing this per the contributing guide so the PRs have a proposal to reference — happy to take feedback on the shape in the meantime.

Contact Details

[email protected]