Privacy & data handling

This page is a product-specific supplement to InPolicy’s main Privacy Policy. Everything here is within the commitments made there; where there’s any apparent conflict, the Privacy Policy governs.

Short answer: we store nothing about the conversation content itself, and no end-user identifiers.

Terminology

The main Privacy Policy defines a handful of terms that apply directly to this product. Using them here for consistency:

• Content: input (user messages, tool returns, agent drafts processed through the Service) plus output (policy decisions returned). InPolicy does not store Content. It’s processed transiently and discarded when the request completes.
• Customer Data: account and organizational data, including the policies you author.
• Usage Data: aggregated, anonymized metrics about API usage. No Content, no end-user identifiers.
• Policy State Summary: a system-generated record of which policies are currently applicable to a conversation. Contains policy IDs, a turn counter, and binding-event timestamps. Contains no message text and no personal information. (Defined in Privacy Policy §1.)

What we store

In Redis (ephemeral):

Data	Type	Purpose	Retention
Caller-chosen sessionId	Opaque string	Cache key for Policy State Summary. Opaque to us.	With the state, up to 4h sliding / 7d hard cap (see below)
Your tenant id	Identifier	Multi-tenancy isolation.	Duration of customer relationship
Turn count (integer)	Counter	To number binding events by turn index.	Same as Policy State Summary
IDs of active policies	References	To compute the diff on the next turn.	Same as Policy State Summary
Binding event log: (turnIndex, policyId, event, ts)	Metadata	Returned on the state GET endpoint.	Same as Policy State Summary

Session-level retention. Conversation state expires after 4 hours of inactivity by default, with a hard 7-day cap. Customers can configure a tighter override per API key (down to 5 minutes). This is within the Privacy Policy’s “up to 30 days” envelope for Policy State Summaries; we’re deliberately more restrictive.

In PostgreSQL (durable):

Data	Purpose
API key metadata (bcrypt hash, scopes, settings)	Auth, rate-limit, feature gating. Plaintext is never stored.
Per-call Usage Events	Usage-based billing and rate-limit accounting. See below.

Usage Events contain: (timestamp, tenantId, apiKeyId, endpoint, latencyMs, statusCode, billableUnits). No sessionId, no policyId, no Content, no end-user identifiers. These are Usage Data under the Privacy Policy (§2.2).

What we NEVER store

• Content: the text of what your users or the AI said is used during the request and discarded. Per Privacy Policy §2.2.
• Content hashes. We don’t even store hashes.
• recentContext / priorHistory you pass on record_turn: request-scoped, discarded.
• endUserContext attributes. Used for policy matching in the single request; not persisted.
• Violation text from check_output / check_tool_call. Returned in the API response; not persisted.
• End-user identifiers. We don’t have a concept of “end user”. There’s only sessionId (caller-chosen, opaque) and your apiKeyId.

What this means for your integration

If you want durable audit trails of binding events or violations:

• Capture diff.bindingEvents on every recordTurn response.
• Capture violations on every postInference / checkToolCall response.
• Write these to your own logging system (Datadog, Splunk, S3, a dedicated Postgres table, whatever fits).

InPolicy doesn’t hold this data past the request. Retention post-delivery is your concern.

Caller responsibility

Two fields we treat as opaque. Don’t put personally identifiable information in them:

• sessionId: stored for the session lifetime. If you format it as user_123_conversation_456, that string sits in our Redis for up to 7 days.
• endUserContext.attributes: not stored, but transits our servers. Keep it non-identifying (tier: enterprise, not email: bob@example.com).

Data residency

All Personal Data is hosted on GCP in the United States. InPolicy does not transfer Personal Data outside the US. Per Privacy Policy §7. For GDPR customers transferring from the EEA, transfers are governed by the SCCs in our Data Processing Agreement.

Subprocessors

Full list is in Privacy Policy §4.1. For the governance API specifically:

• Google Cloud Platform (hosting, Redis, Postgres): holds Customer Data and Usage Data. United States.
• Google Cloud Vertex AI (LLM inference for policy retrieval and violation detection): handles transient Content only. Vertex does not store prompts or responses for InPolicy’s account.

We give 30 days’ notice before adding or replacing any subprocessor.

No training on Customer Data

Per Privacy Policy §3.3, InPolicy does not train any AI models using Content or Customer Data. This extends to all subprocessors. Your policies, your users’ messages, and your agents’ outputs are never used to train anyone’s model.

Security posture

InPolicy is in active preparation for SOC 2 Type I certification (Privacy Policy §6). Current security posture documentation available upon request at security@inpolicy.ai. Infrastructure summary:

• TLS in transit, everywhere.
• Access to production limited to authorized personnel with MFA.
• All internal access is logged and audited.
• Hosted on GCP, United States only.

Your rights

Full rights and request procedures are in Privacy Policy §8. For the governance API specifically, access/deletion/portability requests should go to privacy@inpolicy.ai. We respond within 30 days (EU/UK) or 45 days (California), with one possible extension.

Tenant Knowledge Base

InPolicy maintains a per-tenant knowledge base (product documentation, public filings, regulatory registers) used to disambiguate policy enforcement decisions. It contains no Content and no employee communications. Your organization can review and correct it at any time by contacting security@inpolicy.ai. See Privacy Policy §2.1.

Questions

For anything not covered here, the main Privacy Policy is authoritative. Direct questions to privacy@inpolicy.ai.