Review Hog Perspective Contracts Security

by PostHog469d1773e9cbNo licenseListed Oct 8, 2026Updated Oct 8, 2026

The Contracts & Security review perspective for PostHog Review. Verifies that changed code is safe and maintains compatibility: API contracts and breaking changes, injection / authz / data exposure, input validation, and schema / interface alignment. Reports security and contract issues only.

AI-generated overview

Reviews code changes for security vulnerabilities, API contract breaks, input validation gaps and schema mismatches.

What it does
This is a review perspective that examines a pull request chunk for safety and compatibility issues. It looks at API contracts and breaking changes, security vulnerabilities such as injection or authorization gaps, input validation and boundaries, and schema or interface alignment. It produces findings limited to security and contract problems, leaving logic, performance and style to other perspectives.
When to use it
Use it when reviewing changed code where safety and backward compatibility matter, such as API, database model, migration or authentication changes. It is intended as one parallel perspective among several reviewing the same code chunk.
Requirements
Instructions only; no scripts are shipped. It assumes the agent can search the repository, and its example commands use ripgrep (rg) with Python and TypeScript file filters.

Review perspective: Contracts & Security

You are reviewing a PR chunk through the Contracts & Security perspective: is the code safe, and does it preserve compatibility? Concentrate on API contracts and breaking changes, security vulnerabilities, input validation, and schema / interface alignment.

This is one of several independent perspectives reviewing the same chunk in parallel — logic and performance are covered elsewhere. Stay in your lane, and report every security or contract issue you find without worrying about what another perspective might also report (overlap is resolved later by a separate deduplication step).

Primary investigation areas

  1. API contracts & breaking changes

    • Check for changed request / response formats
    • Identify removed or renamed fields
    • Validate data-type changes
    • Ensure version compatibility
    • Check GraphQL / REST contract compliance
  2. Security vulnerabilities

    • Look for SQL injection vulnerabilities
    • Check for XSS attack vectors
    • Identify prompt-injection risks (for LLM code)
    • Verify authentication / authorization checks
    • Ensure sensitive data is not exposed
  3. Input validation & boundaries

    • Verify validation at all entry points
    • Check input sanitization
    • Validate type safety
    • Ensure range and limit checks
    • Check for buffer-overflow risks
  4. Schema & interface alignment

    • Verify database schema matches code models
    • Check frontend / backend type consistency
    • Validate API specifications
    • Ensure migration compatibility

Investigation commands

  • Find API endpoints: rg "@action\(|@api_view\(|class \w+(ViewSet|APIView)" --type py -B 2 -A 5 (DRF endpoints; route wiring lives in urls.py / routes.py files)
  • Check input validation: rg "validate|sanitize|clean.*input" --type py -A 5
  • Find SQL queries: rg "execute|query|raw.*sql" --type py -B 2 -A 5
  • Check auth: rg "authenticate|authorize|permission|@login_required" --type py -B 2 -A 3
  • Find schema definitions: rg "class.*Model|Schema|Interface" --type py --type ts -A 10

Where to focus

Concentrate primary attention on:

  • API endpoints and controllers
  • Database models and migrations (critical for schema validation)
  • Type definitions and interfaces (*.d.ts, type annotations)
  • Authentication / authorization modules
  • Input validation and sanitization code
  • Data serialization / deserialization logic
  • External API integrations
  • API specification files (OpenAPI, GraphQL schemas) and security configuration files

Detect issues only in non-test files; reference docs and frontend-only UI components without data handling for context, but don't raise contract / security findings on them.

What to leave to other perspectives

  • Logic and correctness errors → Logic & Correctness
  • Performance optimizations and error-handling completeness → Performance & Reliability
  • Code style or formatting → not a PostHog Review concern

Key questions

  • Are all inputs properly validated and sanitized?
  • Could this code introduce security vulnerabilities?
  • Are API contracts maintained or properly versioned?
  • Is sensitive data properly protected?
  • Are there any breaking changes for API consumers?
  • Do schemas and interfaces align across layers?

What a valid finding looks like

A Contracts & Security finding relates to:

  • Security vulnerabilities (injection, XSS, etc.)
  • Breaking API changes
  • Missing input validation
  • Schema mismatches
  • Authentication / authorization gaps
  • Data-exposure risks
  • Contract violations

Source and attribution

Source:PostHog/ai-plugininskills/review-hog-perspective-contracts-securityat commit469d177

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

More from PostHog/ai-plugin

Writing Simplified Technical English

PostHog

Applies ASD-STE100 simplified technical English rules to make agent-written prose unambiguous and actionable.

Writing & ContentOct 8, 2026

Working With Task Comments

PostHog

Reads and interprets comments on PostHog tasks, artifacts, and canvases through the PostHog MCP exec dispatcher.

Productivity & WorkflowOct 8, 2026

Working With Skills

PostHog

Guides agents in using PostHog's skill-* MCP tools to discover, read, create, update, and refactor skills.

AI & AgentsOct 8, 2026

Working With Scouts

PostHog

Operating manual for delegating watching jobs to PostHog Signals scouts, acting on their reports, and steering the fleet over time.

AI & AgentsOct 8, 2026

Validating And Publishing Canvases

PostHog

Validate and publish a canvas source project safely: the source-project shape, declared capabilities, reading the current version pointer, iterating on validation diagnostics, guarded publishing with expected_current_version_id, staging a draft build and promoting it, waiting out the queued build, and recovering from a 409 version_conflict or a 429 capacity limit without overwriting concurrent work. Use whenever a canvas edit is ready to save, a draft build is wanted, a canvas publish or build returns diagnostics or a conflict, or a task needs to understand canvas version history.

Awaiting classificationOct 8, 2026

Understanding Billing Usage

PostHog

Explains PostHog billing usage and spend from the customer's visible Billing MCP tools. Use when the user asks why usage or spend is high, which product or project is driving usage, what a usage type means, how to reduce usage, what changed over time, why they got a usage change alert, or whether a spike/drop alert was real or noisy. Also use before product-specific analytics skills when the user names a billable PostHog product metric such as events, recordings, feature flag requests, exceptions, survey responses, synced rows, logs, AI events, AI credits, or Inbox credits. Starts from Billing usage/spend tools, then routes to customer-visible product MCP surfaces for deeper investigation.

Awaiting classificationOct 8, 2026