integration: add Singulr guardrail support

[aniket-kardile]

Description: (required)

• Adds a new Singulr guardrail plugin (plugins/singulr/scan.ts) that scans LLM request/response content via the Singulr API and can block traffic based on server-side configured policies
• Supports both beforeRequestHook (input) and afterRequestHook (output) scanning, with credentials for API key, guardrail ID, application/enforcement ID, and an optional custom base URL
• Registers the plugin in plugins/index.ts and defines its schema in plugins/singulr/manifest.json

Tests Run/Test cases added: (required)

• Credential validation (missing API key, missing guardrail/application ID, valid with only one of guardrail/application ID)
• No-content passthrough (skips the scan call when there's nothing to scan)
• Allow/block verdicts, including the descriptive block reason surfaced in data.explanation
• Request body construction (guard_input, metadata, headers, custom base URL, configurable timeout)
• Error handling — fail-open behavior verified for 401/403/5xx/timeout/generic/non-Error rejections
• All 25 test cases pass via npx jest plugins/singulr

Type of Change:

• New feature (non-breaking change which adds functionality)

[akhilmmenon]

Thanks for the contribution — overall shape looks good and closely follows the CrowdStrike AIDR partner pattern (full guard_input + metadata + fail-open).

Requesting a few changes before we can approve:

1. manifest.json: credentials.required lists SingulrGuardrailId AND SingulrApplicationId, but the handler/tests allow either. Please align (required: [SingulrApiKey] only, with clear OR/XOR docs).

2. Manifest says the plugin can "sanitize" content, and scan.ts imports getCurrentContentPart/setCurrentContentPart, but there is no transform path. Please either implement redact/transform (see crowdstrike-aidr) or remove the sanitize claim and unused imports.

3. Please move Guardrail ID / Application ID into function parameters (like f5-guardrails projectId / zscaler policyId), and keep credentials to API key + optional base URL. That lets one org integration drive multiple checks.

4. timeout is read from parameters but not declared in the function schema (manifest.json); peers usually expose it with a default (often 5000ms). Please add it and confirm whether 30000ms is intentional.

Nits: prefer camelCase credential keys (apiKey, baseUrl) for consistency with other partners; make empty-content checks target-aware for the active hook.

Also please confirm CI is green on this branch — no checks are currently reported on the PR. Confirm Prettier is green on the PR; we’ll comment run tests for the gateway suite after the review changes land.

[aniket-kardile]

Hi @akhilmmenon, thanks for the thorough review! Here's a summary of the changes:

• Credentials required list: Fixed — guardrailId/applicationId moved out of credentials entirely; credentials.required is now [singulrApiKey, singulrBaseUrl] only.
• "Sanitize" claim / unused imports: Removed sanitize wording from manifest description and dropped unused getCurrentContentPart/setCurrentContentPart imports; no transform path implemented since the Singulr response carries no redacted payload today.
• Guardrail ID / Application ID → function parameters: Done — both now live under functions[0].parameters, matching the f5-guardrails projectId pattern; one credential set can now drive multiple guardrail checks.
• timeout not in schema: Added to manifest with default: 5000; aligned DEFAULT_TIMEOUT in code from 30000 → 5000ms to match.
• camelCase credential keys: Renamed to singulrApiKey/singulrBaseUrl.
• Target-aware empty-content check: Now checks only context[target].json for the active hook direction, not both request and response unconditionally.
• CI / Prettier / tests: Prettier clean on all changed files; plugins/singulr/scan.test.ts passes 26/26; unrelated pre-existing failures seen elsewhere in test:plugins/test:gateway are environmental (live HTTP 500s, missing test fixture, tsconfig issue) and don't touch this plugin; pushing now for CI to report on the PR.

[akhilmmenon]

Thanks for the follow-up — the updated commit addresses the review points well:
credentials vs function params split, sanitize/imports cleanup, timeout in schema (5000ms), target-aware empty check, and camelCase keys.

I’m good to approve. Two soft nits (non-blocking):

1. Prefer apiKey/baseUrl naming to match other partners (optional).
2. Confirm Singulr’s API truly requires both guardrailId and applicationId (you tightened from OR → AND).

We’ll kick off the gateway test suite from our side next once you confirm the above points.

[aniket-kardile]

Thanks for the review! Updates on both points:

1. apiKey/baseUrl naming — done. Renamed singulrApiKey/singulrBaseUrl to apiKey/baseUrl in the credentials interface, manifest, and headers construction, matching the convention used by other partner plugins.

2. guardrailId AND applicationId — confirmed intentional. Singulr's /api/v1/ai-gateway/portkey endpoint requires both: guardrailId identifies which guardrail policy to apply, and applicationId (sent as enforcement_id/X-Singulr-Enforcement-Entity-Id) scopes enforcement to the calling application. Both are mandatory on our backend — a request with only one is rejected — so the tightened AND check is correct.

Ready for the test suite whenever you want to kick it off.

[akhilmmenon]

Thanks again for the updates — the latest changes look good (apiKey/baseUrl naming and confirming both guardrailId + applicationId are required).

Quick update on merge path: we’re consolidating partner guardrail enablement on our enterprise gateway (the open-source gateway path is effectively deprecated for new partner plugins). We’ve taken your contribution as the basis and are adding Singulr internally there.

We’ll keep you posted once it’s available for you to configure/test. Appreciate the collaboration and the clean plugin shape — it made the port straightforward.

[aniket-kardile]

Thanks for the update! Glad to hear the contribution helped make the port straightforward.

We appreciate you moving the Singulr integration forward on the enterprise gateway. Please keep us posted once it’s available for configuration and testing — we’ll be happy to validate the integration from our side.

[akhilmmenon]

@aniket-kardile We are currently testing the integration of Singulr AI plugin on our enterprise platform, but before the final integration, I would need to run a manual test with Singulr's actual API key, can you please help me with the procurement for the same?
You can share the details on the Pylon support ticket.

[aniket-kardile]

@akhilmmenon I have shared the required credentials on Pylon support ticket. Thanks !