Policy Testing Guide

This guide helps you validate that Capsule policies are working correctly by running controlled test scenarios with your coding agents. Each scenario triggers a specific policy, so you can confirm your organization's security monitoring is functioning as expected.

Capsule monitors coding agent sessions in real time, analyzing messages, tool invocations, and agent configuration against your defined policies. Policies define what to look for and how to respond when a violation is detected.

This guide provides ready-to-use test scenarios for each policy. Each scenario walks you through the exact steps to trigger a detection, what to expect in the portal, and how to verify the result.

Important: Some test scenarios involve prompts that reference destructive commands (such as file deletion, database drops, or infrastructure changes). Always run these tests in a sandbox or isolated test environment - never against production systems or agents with live credentials. Policies in Monitoring mode will log violations but will not block the action, so a destructive command could execute before the violation is recorded.

Before running test scenarios, make sure you have:

• A sandbox or test environment - do not run these scenarios against production systems or agents with live infrastructure credentials
• A Capsule Security account with access to the portal
• At least one coding agent integration deployed (for example, Claude Code or Cursor)
• At least one agent discovered in your Capsule portal (Inventory > Agents)
• Default policies enabled in Monitoring mode (enabled by default)

Capsule has two kinds of policies:

Some policies list more than one finding or detection type, for example Prompt Injection with Intent Misalignment. These policies trigger only when all listed types are present:

• Posture policies - every listed finding must be on the same resource
• Runtime policies - every listed detection must occur in the same session on the same agent

This is why combined policies carry a higher severity than their single-condition counterparts: the combination indicates a real attack chain, not an isolated signal.

A runtime policy scoped to Tool call activity can narrow its detections to calls whose input matches. Capsule evaluates the condition deterministically in the hook before the detector runs, so a call outside the condition is never sent to the model for that policy.

The condition lives on the Tool scope and compares the serialized tool call arguments against a list of values, case-insensitive:

• IS (contains): the input contains any of the values, for example rm -rf or git push --force
• IS NOT (does not contain): the input contains none of the values, which is how an allow list is expressed, for example acme.com

When both are set, both must hold. A call that carries no input never matches. Combine the condition with the other Tool scope fields (tool type, tool name) to limit it to the tools it applies to.

The policy still needs at least one detection type: a call is blocked, or a violation raised, only when its input matches and the detection is raised on that same call.

Each policy operates in one of three modes that determine how it responds to a violation:

When a policy triggers, Capsule takes the following actions:

• Creates a policy violation visible in the portal
• Blocks the action in real time (Prevention mode only)

Posture violations resolve automatically once the underlying finding is gone, for example after you remove a risky MCP server or fix an insecure setting.

All Capsule accounts come with pre-configured policies enabled in Monitoring mode. The tables below map each policy to the test scenario that validates it.

Violations appear on two pages in the Capsule portal, depending on the policy type:

• Posture - violations from configuration policies (agents, MCP servers, skills, tools, data sources)
• Runtime - violations from session policies (data exposure, prompt injection, operational safety)

After running any test scenario:

1. Open the Posture or Runtime page
2. Look for a new violation matching the scenario you tested
3. Click the violation to see:
   • Violation category - The specific violation category that was detected
   • Evidence - Quoted content from the session or configuration that triggered the detection
   • Policy - Which policy matched and its severity
   • Session - Link to the full agent session for context (runtime violations)

• Run one scenario at a time for clear results
• Allow some time after the agent session for analysis to complete
• Start a new agent session after a configuration change, so Capsule picks up the new setup
• Many detections are judged by an AI model against the full context, so a scenario that looks contrived may be classified differently from a realistic one. If a scenario doesn't trigger, make it more concrete rather than more extreme
• Start with Monitoring mode - switch to Prevention mode only after validating detections work
• Use a dedicated test environment or sandbox agent if available