Gray Swan Cygnal

​

What is Gray Swan Cygnal?

​

Key Features of Gray Swan 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 Gray Swan Cygnal

• Name: Enter a name for your guardrails group.
• Collaborators: Add collaborators who will have access to this group.
• Gray Swan Cygnal Config:
  • Name: Enter a name for the Gray Swan Cygnal configuration (e.g., grayswan).
  • Description (Optional): A description for the guardrail (e.g., “Gray Swan Cygnal for policy violation and content safety monitoring”).
  • Operation: The operation type for this guardrail. Gray Swan Cygnal guardrails can only be used for Validate — requests are validated against configured policies and rules.
• Gray Swan Cygnal Authentication Data:
  • API Key: The API key for Gray Swan Cygnal. This key is required to authenticate requests to the Cygnal monitoring API. You can obtain it from the Gray Swan portal. Ensure you keep this key secure, as it grants access to your Gray Swan 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 Gray Swan 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