Skip to main content

Configure Policies for IDE Traffic

IDE assistant requests can include code context and must have low latency. Use a short policy chain as a baseline. Protect sensitive text before the editor sends it. Add only runtime features that you can validate.

Start with this baseline​

This config applies a short policy chain to risks that occur frequently.

pack:
  name: ide-baseline
  version: 1.0.0
  enabled: true

providers:
  targets:
    - id: openai-ide
      provider: openai
      model: your-model-id
      secret_key_ref:
        env: VERDICTAN_OPENAI_API_KEY

policies:
  chain:
    - prompt-injection
    - pii-detector
    - audit-logger

policy:
  prompt-injection:
    attack_patterns:
      - ignore.*previous.*instructions
      - reveal.*system.*prompt
    response:
      action: block

  pii-detector:
    action: redact
    pci_mode: true
    redaction:
      marker_format: label

  audit-logger: {}

Replace your-model-id with an ID supported by the provider. After the gateway starts, query authenticated GET /v1/models to verify the available IDs.

Baseline effects​

Keep the request chain short​

Inline completions are latency-sensitive. Start with:

  • prompt-injection rejects known jailbreak and instruction-override attempts.
  • pii-detector redacts sensitive identifiers in prompts, pasted logs, comments, and literals.
  • audit-logger marks audit logging as active in the policy result. It does not configure persistence or retention by itself. Review the resulting evidence with verdictan events tail or GET /v1/events?since=10m. When applicable, use Trail and capture-enabled History.

After you verify that their latency does not exceed the approved limit for the editor workflow, add buffered-output controls.

Add user rate limits only at a trusted identity boundary​

IDE extensions can retry frequently or send the same completion call many times while a developer types. user_rate_limit gives a stable per-user limit to requests with a configured, nonempty identity header. It does not put these requests in one shared bucket. Requests without that header bypass the per-user limiter.

Use only a header that a trusted authenticated proxy sets. The proxy must remove all values supplied by the IDE before it sets the authenticated identity. Do not trust a caller-controlled x-user-id value.

Use Rate Limits Configuration for a larger window or the Chat Completions token limiter. It also gives information about the global request counter for multiple gateway instances.

Enable response caching only after a data review​

Configure the public runtime cache in top-level cache:. It applies only to non-streaming Chat Completions or Responses requests that are read-only. Streaming completion traffic bypasses the cache. The exact mode matches the same request body.

IDE requests can contain source code, credentials, logs, and customer data. Keep caching off unless the approved design defines tenant and key isolation, retention, encryption, deletion, and allowed source-code handling. Test the selected backend before you enable cache.default_on.

Use Runtime Configuration for semantic cache options, backend selection, and cache environment variables.

Add more controls​

Add more controls only for a clear product cause:

  • Add dlp-filter for proprietary-data checks that are broader than pii-detector.
  • If provider retention or training metadata controls the destination for IDE traffic, add data-routing-policy.
  • After you measure the latency from buffered output checks, add quality-scorer.
  • If Chat Completions and Responses must use different policy enforcement, add route-specific chains with Routes and Consumer Groups. Routes do not select upstream providers.

Before rollout, validate​

Run the config through the same public validation flow that you use for all gateway traffic:

verdictan policy lint
verdictan policy test --json
verdictan gateway run --agent ide-gateway --policy-config policy-config.yaml
verdictan events tail --since 10m --follow

While the gateway runs, trigger completions from the IDE. Make sure that these results occur:

  • the event tail shows requests
  • the event shows the specified token identity or user header
  • prompt-injection or redaction verdicts occur when you test a known policy violation
  • latency does not exceed the approved limit for the editor workflow

What not to do​

  • Do not add unverified or unpublished policy types.
  • If secret_key_ref can reference provider secrets, do not embed them in YAML.
  • Do not trust an identity header that the IDE can set.
  • Do not cache source-code prompts without an approved data-handling design.
  • Until you measure the latency change, do not use chat-oriented policy chains for inline completion traffic.

Next steps​