Veriprompt Docs

Appearance

CISO & DPO Guide ​

This guide is for Chief Information Security Officers, Data Protection Officers, and similar security or privacy leaders who need to define guardrails, reduce exposure to third-party AI providers, and maintain oversight across AI usage in the organization.

What you can control directly ​

VeriPrompt gives security leadership several practical control points instead of relying on informal prompt-writing discipline alone.

1. Routing policies ​

Routing policies let you define where requests are allowed to go and under which constraints.

You can configure:

  • provider selection strategy
  • provider allow and deny boundaries
  • geofencing by region and country
  • compliance constraints
  • fallback behavior
  • provider groups for approved provider pools

Use routing policies when you want to answer questions such as:

  • Which providers are allowed for regulated workloads?
  • Which countries or regions may process prompt data?
  • Which internal tools may use which provider pool?

See:

2. PII sanitization policy ​

Routing policies can now also define how sanitization behaves before a request reaches an external model.

Available modes:

  • disabled
  • automatic
  • manual

In manual mode, you can restrict which trigger sources are permitted:

  • prompt
  • api
  • user_action

This is useful if you want automatic sanitization for certain workloads, but only allow selective sanitization in lower-risk or exploratory workflows.

See:

3. Execution governance ​

For sensitive workflows, you can use execution modes to change how the gateway behaves:

  • AUTONOMOUS for normal execution
  • DRY_RUN to inspect routing and enforcement without calling a provider
  • SUPERVISED to require human approval before a response is released

This gives you a practical approval layer for high-risk use cases such as legal, HR, M&A, regulated customer communication, or privileged internal analysis.

See:

4. Security scanning and compliance checks ​

VeriPrompt can apply security and compliance controls before a request executes.

These include:

  • prompt injection detection
  • compliance checking
  • blacklist and keyword-based enforcement in chat workflows
  • PII detection and sanitization for sensitive content

See:

5. Provider boundary and credential model ​

If your policy requires stronger tenant control, you can combine routing policies with BYOK and service configuration choices.

This supports goals such as:

  • using only customer-approved providers
  • ensuring internal platform services use approved provider/model combinations
  • separating experimental from production-grade provider paths

See:

How VeriPrompt protects your organization ​

VeriPrompt is designed so that the gateway, not the end user, is the policy enforcement point.

Policy enforcement happens at execution time ​

The important control is not whether a user selected the right provider manually. The important control is that the gateway enforces routing policy, geofencing, and related restrictions when the request is actually executed.

That means:

  • stored prompts stay inside policy boundaries
  • interactive chat stays inside policy boundaries
  • internal services such as Guru and other platform execution paths stay inside policy boundaries

PII can be removed before provider dispatch ​

When sanitization is enabled by policy or explicit trigger, VeriPrompt sanitizes detected sensitive information before the provider sees the request, then restores the mapped values on the way back.

This reduces third-party exposure for:

  • names and contact data
  • contractual identifiers
  • customer references
  • internal organization identifiers when matched by configured detection rules

Human review can be required ​

If a workflow is too sensitive for fully automatic release, supervised execution gives you a hold-and-approve step rather than relying on post-facto review.

Provider risk can be constrained geographically and contractually ​

Geofencing and provider restriction controls let you narrow execution to approved regions and providers, which matters for GDPR, localization, procurement, and internal risk committee requirements.

Encryption and auditability are built into the platform ​

VeriPrompt documentation already covers:

  • encryption at rest for stored PII
  • encrypted provider credentials
  • audit logging for security-relevant operations
  • logged prompt metadata for usage and investigation

See:

How to stay on top of operations ​

Security and privacy oversight depends on having the right monitoring surfaces, not just policy configuration.

Audit logs ​

Use audit logs for control-plane oversight.

They help answer:

  • who changed permissions or roles
  • who created or deleted API keys
  • who exported data
  • who performed high-risk administrative actions

See:

Security governance console ​

Use the security governance console for company-scoped operational oversight.

It consolidates:

  • execution governance events
  • sanitization evidence
  • policy change history
  • provider boundary analytics
  • anomaly alerts
  • security heatmaps and timeline views

Use it when you need to understand whether policy is actually being enforced in day-to-day execution, not just configured on paper.

It now supports investigation drill-downs that preserve the active review window:

  • policy changes open filtered audit logs with the routing policy and date window preselected
  • governance and sanitization events open filtered prompt-log or audit-log views with matching provider, policy, project, geography, and timeframe when those identifiers are available
  • routing policy changes can be reviewed in a structured before/after diff instead of raw JSON only
  • anomaly alerts now open preset-aware investigation views with interpretation assistance for provider shifts, actor or API-key token spikes, blacklist repeat offenders, and governed-flow failures

The security console also provides one-click review presets for:

  • unsanitized executions
  • blacklist enforcement events
  • high-severity protection findings
  • access-review follow-up

It now also includes richer visual review surfaces built from persisted governance data:

  • a policy coverage donut for automatic sanitization, manual sanitization, supervised, ungoverned, and plain autonomous execution paths
  • a Sankey flow from team to project to policy to provider to governed outcome
  • a top-risky-actors chart based on blacklist violations, blocked executions, export volume, and unusual provider switching
  • provider-boundary trends that show allowed, blocked, and fallback traffic over time
  • anomaly cards that now link directly into the supporting prompt-log or audit evidence
  • anomaly reporting panels that summarize which alert classes dominate the current review window and how severe they are
  • provider-health backfill from persisted prompt logs so drift analytics can be populated on an existing local deployment without waiting for fresh telemetry

Security access review ​

Use the access review screen to answer:

  • who can execute prompts
  • who can export prompts or analytics
  • which privileged users have gone dormant
  • which API keys are too broad or stale

This is the practical review surface for quarterly access reviews and internal security attestations.

The access review tables also support direct investigation pivots:

  • dormant privileged users link into the last 90 days of audit and prompt activity for that principal
  • export activity entries link into export-focused audit logs and the same user’s prompt activity
  • broad API keys link into API-key-specific audit history and the owning user’s audit trail

Prompt logs ​

Use prompt logs for execution-level oversight.

They let you analyze:

  • which providers and models are being used
  • which users or API keys are sending traffic
  • execution-linked prompt hashes
  • token usage and timing metadata
  • request patterns by sender, provider, or timeframe

This is useful for incident response, cost attribution, and unusual-pattern detection.

For governance follow-up, use the filtered prompt-log explorer rather than broad log scans. It supports review by:

  • actor ID
  • API key ID
  • routing policy ID
  • project ID
  • geo bucket
  • provider, model, sanitization state, governed-failure status group, and date range

The prompt-log explorer also exposes preset-specific interpretation banners so investigators know why a filtered slice matters before reading raw rows.

See:

Provider health and quality telemetry ​

Use provider health to track whether approved providers are still performing as expected.

You can review:

  • quality score
  • drift detection
  • stability
  • recovery and refusal behavior

If your company already has prompt traffic but few provider-health events, use the governance console's Backfill Health action. It derives provider-health sample, fallback, and error events from persisted prompt logs and execution outcomes, then aggregates them into snapshots for the drift radar.

This helps security and governance teams challenge the assumption that an approved provider remains acceptable indefinitely.

See:

Analytics and reporting ​

Use analytics to monitor macro-level usage and drift across teams and projects.

Key oversight questions:

  • Which teams are driving the highest cost?
  • Which providers are seeing rising latency or failure rates?
  • Which workflows changed materially after a prompt or provider update?

See:

Blacklist violation reports ​

If you use chat blacklists or restricted-term enforcement, review the violation reports regularly to detect:

  • attempted policy bypass
  • recurring user training gaps
  • internal teams handling disallowed data in the wrong workflow

See:

Synthetic testing and provider comparison ​

Use synthetic testing to validate whether a routing or security policy change had the desired operational effect.

This is especially useful for:

  • regression detection after policy changes
  • comparing providers inside an approved pool
  • tracking KPI compliance over time

See:

Event hooks and webhooks ​

If your organization runs a SIEM, workflow engine, or alerting pipeline, event hooks can push important platform events outward for centralized monitoring.

See:

Daily ​

  • review high-severity audit events
  • review blacklist violations and suspicious prompt patterns
  • watch provider health drift for approved providers

Weekly ​

  • review prompt-log trends by provider, team, and API key
  • review analytics for cost spikes, latency shifts, and failure-rate changes
  • sample sensitive workflows for supervised or sanitized execution coverage

Monthly ​

  • review routing policies against current approved-provider and region lists
  • confirm which packages and teams are allowed to use sanitization and advanced controls
  • review retention settings, exports, and security exceptions
  • run synthetic comparison checks for critical workflows

A practical policy model ​

Many organizations end up with a structure like this:

  • one company-wide baseline routing policy with strict provider and geo constraints
  • stricter prompt- or project-level policies for regulated workflows
  • automatic sanitization for customer, HR, legal, and compliance-heavy use cases
  • manual sanitization for exploratory knowledge work
  • supervised execution for high-impact release workflows

This combination usually gives better control than trying to solve everything with a single universal policy.