Perplexity Policy & Guardrails

VerifiedSafe

Implements ESLint rules, pre-commit hooks, and CI policy checks to enforce Perplexity best practices (API key handling, error handling, strict typing). Useful when setting up code quality controls for Perplexity integrations.

Sby Skills Guide Bot
SecurityIntermediate
806/2/2026
CursorWindsurf
#perplexity#lint#guardrails#policy

Recommended for

Our review

Sets up custom ESLint rules, pre-commit hooks, and CI checks to enforce security and best practices for Perplexity integrations.

Strengths

  • Automatically detects hardcoded API keys
  • Validates configuration via ESLint and pre-commit
  • Integrates with OPA policies for business rules
  • Enforces strict TypeScript typing for Perplexity clients

Limitations

  • Requires existing ESLint and pre-commit setup
  • May produce false positives on non-production keys
  • Perplexity-specific, does not cover other APIs
When to use it

For collaborative projects using Perplexity where code security and consistency are critical.

When not to use it

For personal projects without security constraints or when not using Perplexity.

Security analysis

Safe
Quality score92/100

The skill provides code templates and instructions for setting up lint rules, pre-commit hooks, and CI checks. It does not contain any destructive, obfuscated, or data-exfiltrating commands. The allowed Bash usage is limited to standard development tools (npx, grep, eslint) and the skill itself proposes security measures like secret detection.

No concerns found

Examples

Set up Perplexity ESLint rules
Set up perplexity eslint rules for my project to enforce best practices like no hardcoded keys and typed clients.
Implement Perplexity pre-commit hooks
Add perplexity guardrails with pre-commit hooks to check for hardcoded API keys and validate configuration.
Configure CI policy checks
Configure perplexity best practices check in our CI pipeline using OPA policy to deny production keys in non-prod environments.

name: perplexity-policy-guardrails description: | Implement Perplexity lint rules, policy enforcement, and automated guardrails. Use when setting up code quality rules for Perplexity integrations, implementing pre-commit hooks, or configuring CI policy checks for Perplexity best practices. Trigger with phrases like "perplexity policy", "perplexity lint", "perplexity guardrails", "perplexity best practices check", "perplexity eslint". allowed-tools: Read, Write, Edit, Bash(npx:*) version: 1.0.0 license: MIT author: Jeremy Longshore jeremy@intentsolutions.io

Perplexity Policy & Guardrails

Overview

Automated policy enforcement and guardrails for Perplexity integrations.

Prerequisites

  • ESLint configured in project
  • Pre-commit hooks infrastructure
  • CI/CD pipeline with policy checks
  • TypeScript for type enforcement

ESLint Rules

Custom Perplexity Plugin

// eslint-plugin-perplexity/rules/no-hardcoded-keys.js
module.exports = {
  meta: {
    type: 'problem',
    docs: {
      description: 'Disallow hardcoded Perplexity API keys',
    },
    fixable: 'code',
  },
  create(context) {
    return {
      Literal(node) {
        if (typeof node.value === 'string') {
          if (node.value.match(/^sk_(live|test)_[a-zA-Z0-9]{24,}/)) {
            context.report({
              node,
              message: 'Hardcoded Perplexity API key detected',
            });
          }
        }
      },
    };
  },
};

ESLint Configuration

// .eslintrc.js
module.exports = {
  plugins: ['perplexity'],
  rules: {
    'perplexity/no-hardcoded-keys': 'error',
    'perplexity/require-error-handling': 'warn',
    'perplexity/use-typed-client': 'warn',
  },
};

Pre-Commit Hooks

# .pre-commit-config.yaml
repos:
  - repo: local
    hooks:
      - id: perplexity-secrets-check
        name: Check for Perplexity secrets
        entry: bash -c 'git diff --cached --name-only | xargs grep -l "sk_live_" && exit 1 || exit 0'
        language: system
        pass_filenames: false

      - id: perplexity-config-validate
        name: Validate Perplexity configuration
        entry: node scripts/validate-perplexity-config.js
        language: node
        files: '\.perplexity\.json$'

TypeScript Strict Patterns

// Enforce typed configuration
interface PerplexityStrictConfig {
  apiKey: string;  // Required
  environment: 'development' | 'staging' | 'production';  // Enum
  timeout: number;  // Required number, not optional
  retries: number;
}

// Disallow any in Perplexity code
// @ts-expect-error - Using any is forbidden
const client = new Client({ apiKey: any });

// Prefer this
const client = new PerplexityClient(config satisfies PerplexityStrictConfig);

Architecture Decision Records

ADR Template

# ADR-001: Perplexity Client Initialization

## Status
Accepted

## Context
We need to decide how to initialize the Perplexity client across our application.

## Decision
We will use the singleton pattern with lazy initialization.

## Consequences
- Pro: Single client instance, connection reuse
- Pro: Easy to mock in tests
- Con: Global state requires careful lifecycle management

## Enforcement
- ESLint rule: perplexity/use-singleton-client
- CI check: grep for "new PerplexityClient(" outside allowed files

Policy-as-Code (OPA)

# perplexity-policy.rego
package perplexity

# Deny production API keys in non-production environments
deny[msg] {
  input.environment != "production"
  startswith(input.apiKey, "sk_live_")
  msg := "Production API keys not allowed in non-production environment"
}

# Require minimum timeout
deny[msg] {
  input.timeout < 10000
  msg := sprintf("Timeout too low: %d < 10000ms minimum", [input.timeout])
}

# Require retry configuration
deny[msg] {
  not input.retries
  msg := "Retry configuration is required"
}

CI Policy Checks

# .github/workflows/perplexity-policy.yml
name: Perplexity Policy Check

on: [push, pull_request]

jobs:
  policy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Check for hardcoded secrets
        run: |
          if grep -rE "sk_(live|test)_[a-zA-Z0-9]{24,}" --include="*.ts" --include="*.js" .; then
            echo "ERROR: Hardcoded Perplexity keys found"
            exit 1
          fi

      - name: Validate configuration schema
        run: |
          npx ajv validate -s perplexity-config.schema.json -d config/perplexity/*.json

      - name: Run ESLint Perplexity rules
        run: npx eslint --plugin perplexity --rule 'perplexity/no-hardcoded-keys: error' src/

Runtime Guardrails

// Prevent dangerous operations in production
const BLOCKED_IN_PROD = ['deleteAll', 'resetData', 'migrateDown'];

function guardPerplexityOperation(operation: string): void {
  const isProd = process.env.NODE_ENV === 'production';

  if (isProd && BLOCKED_IN_PROD.includes(operation)) {
    throw new Error(`Operation '${operation}' blocked in production`);
  }
}

// Rate limit protection
function guardRateLimits(requestsInWindow: number): void {
  const limit = parseInt(process.env.PERPLEXITY_RATE_LIMIT || '100');

  if (requestsInWindow > limit * 0.9) {
    console.warn('Approaching Perplexity rate limit');
  }

  if (requestsInWindow >= limit) {
    throw new Error('Perplexity rate limit exceeded - request blocked');
  }
}

Instructions

Step 1: Create ESLint Rules

Implement custom lint rules for Perplexity patterns.

Step 2: Configure Pre-Commit Hooks

Set up hooks to catch issues before commit.

Step 3: Add CI Policy Checks

Implement policy-as-code in CI pipeline.

Step 4: Enable Runtime Guardrails

Add production safeguards for dangerous operations.

Output

  • ESLint plugin with Perplexity rules
  • Pre-commit hooks blocking secrets
  • CI policy checks passing
  • Runtime guardrails active

Error Handling

| Issue | Cause | Solution | |-------|-------|----------| | ESLint rule not firing | Wrong config | Check plugin registration | | Pre-commit skipped | --no-verify | Enforce in CI | | Policy false positive | Regex too broad | Narrow pattern match | | Guardrail triggered | Actual issue | Fix or whitelist |

Examples

Quick ESLint Check

npx eslint --plugin perplexity --rule 'perplexity/no-hardcoded-keys: error' src/

Resources

Next Steps

For architecture blueprints, see perplexity-architecture-variants.

Related skills