GraySwan Cygnal Integration

​

What is GraySwan Cygnal?

​

Key Features of GraySwan Cygnal

1. Policy-Based Content Monitoring: Customizable rules and policies to detect violations across multiple dimensions, with built-in policies like Basic Content Safety.
2. Multi-Policy Aggregation: Combine multiple policy IDs with custom rules for layered security. Earlier policies take precedence, and custom rules supplement the merged policy rules.
3. Configurable Reasoning Modes: Balance detection quality and latency with off, hybrid, and thinking reasoning modes.

​

Adding GraySwan Cygnal Integration

• Name: Enter a name for your guardrails group.
• Collaborators: Add collaborators who will have access to this group.
• GraySwan Cygnal Config:
  • Name: Enter a name for the GraySwan Cygnal configuration (e.g., grayswan).
  • Description (Optional): A description for the guardrail (e.g., “GraySwan Cygnal for policy violation and content safety monitoring”).
  • Operation: The operation type for this guardrail. GraySwan Cygnal guardrails can only be used for Validate — requests are validated against configured policies and rules.
• GraySwan Cygnal Authentication Data:
  • API Key: The API key for GraySwan Cygnal. This key is required to authenticate requests to the Cygnal monitoring API. You can obtain it from the GraySwan portal. Ensure you keep this key secure, as it grants access to your GraySwan Cygnal resources.
• Policy IDs (Optional): Custom policy IDs to use for monitoring. Rules from all policies are merged in order, with earlier policies taking precedence. If not provided, the default Basic Content Safety policy is applied. You can create and manage policies in the GraySwan portal.

• Enforcing Strategy: Strategy for enforcing this guardrail:
  • Enforce: Guardrail is applied. If a violation is detected or an error occurs during execution, the request is blocked.
  • Enforce But Ignore On Error: Guardrail is applied, but if an error occurs during execution, the guardrail is ignored and the request proceeds.
  • Audit: Request is never blocked. Violations are logged for review only.

• Rules (Optional): Custom rule definitions for monitoring. Each key is a rule name and its value is the rule description. For example:
  • financial_advice → “Flag content that provides specific financial recommendations”
  • inappropriate_language → “Detect profanity and offensive language”
• Reasoning Mode: Controls whether Cygnal uses internal reasoning steps before determining if content violates policy:
  • Off (default): Fastest and lowest latency. No additional reasoning tokens. Recommended for most production use.
  • Hybrid: Moderate latency increase. The model reasons as needed without a prescribed reasoning style. Good balance for higher-risk contexts.
  • Thinking: Highest latency and token usage. The model performs guided internal reasoning before classification. Use when detection quality matters more than speed (e.g., offline analysis, security reviews).

​

Response Structure

{
  "violation": 0.92,
  "violated_rules": [2, 3],
  "mutation": false,
  "ipi": true,
  "violated_rule_descriptions": [
    { "rule": 2, "name": "financial_advice", "description": "Flag content that provides specific financial recommendations" },
    { "rule": 3, "name": "inappropriate_language", "description": "Detect profanity and offensive language" }
  ]
}

{
  "violation": 0.005,
  "violated_rules": [],
  "mutation": false,
  "ipi": false,
  "violated_rule_descriptions": []
}

​

Validation Logic

• If the violation score is >= 0.5, the request is considered a policy violation — it will be blocked and a 400 error is returned.
• If the violation score is < 0.5, the request will be allowed to proceed.

​

Request Logs