Security & Infrastructure

PillarShield is a governance tool that handles your content at the publish boundary. This page documents how we protect audit data and the infrastructure behind it.

Encryption

At rest

All audit log data is stored in Google Cloud Firestore, which encrypts data at rest by default using AES-256. Encryption keys are managed by Google Cloud's Key Management Service. No action is required by you; your data is never stored unencrypted.

In transit

All communication between your CMS and PillarShield occurs over HTTPS (TLS 1.2+). Internal communication between PillarShield services and Firestore is also encrypted in transit via Google Cloud's internal transport layer. There is no unencrypted path.

Infrastructure

Hosting

PillarShield runs on Google Cloud Run Functions in the us-west2 (Los Angeles) region.

AI processing

LLM-assisted checks (tone, context) are processed via Google Vertex AI (Gemini 2.5 Flash). Content is sent transiently for evaluation and is not stored by the model provider or used for training.

Data storage

Audit logs are stored in Google Cloud Firestore with zone-level redundancy within us-west2. Firestore automatically replicates data across multiple availability zones, protecting against single-zone failures.

Cross-region backups are exported on a scheduled basis to a geographically separate Google Cloud Storage bucket for disaster recovery.

Timestamp accuracy

All timestamps in audit log entries are generated server-side on Google Cloud infrastructure, which synchronizes clocks via Google's internal time service (equivalent to NTP). Timestamps are accurate and consistent across all PillarShield services.

Audit log integrity

Immutability

Audit records are write-once from the customer's perspective. The product UI and API provide no mechanism for customers to modify, edit, or delete audit log entries. Every publish check — whether the decision is Allow, Warn, Block, or Error — produces a record that cannot be altered through the application layer. PillarShield infrastructure administrators retain access to the underlying data store for operational and legal purposes (e.g., data deletion upon contract termination or legal request).

Content hashing

Each log entry includes a SHA-256 hash of the evaluated content payload. This provides chain-of-custody proof: you can verify that the content recorded in the log is exactly what was checked at the time of the decision.

Hash-chained audit trail

Each audit log entry includes a cryptographic hash of the previous entry, forming a tamper-evident chain. If any record is modified or deleted, the chain breaks. Customers can verify the integrity of their complete audit chain at any time using the Verify Audit Chain button in the portal audit log view.

Unique transaction IDs

Every evaluation is assigned a unique Request ID, enabling precise correlation between a specific publish action and its audit record.

Data retention

Base retention periods are determined by your plan:

PlanRetention
Core15 days
Protect90 days
Managed365+ days

Compliance Packs extend retention for regulated industries:

PackRetentionFrameworks covered
HIPAA Compliance Pack6 yearsHIPAA Security Rule documentation requirements
Financial Services Compliance Pack7 yearsSOX, FINRA, SEC examination requirements

Compliance Packs are available as add-ons to Protect or Managed plans. Additional packs (CMMC, FedRAMP) are in development.

Data export

Audit logs can be exported monthly in CSV or JSON format. Both formats contain the same fields: decision, timestamp, actor, content reference, content hash, violations, and LLM proof (where applicable). Exports are available to all plans.

Data isolation

Each customer's audit data is logically isolated in Firestore. No customer can access another customer's logs, decisions, or configuration. Managed and Enterprise customers may opt for single-tenant deployment with full physical isolation.

Deployment models

PillarShield supports multiple deployment models. In every model, audit log data flows back to PillarShield's centralized Firestore infrastructure. This is by design.

SaaS (default)

Content is sent to PillarShield's cloud infrastructure for evaluation. AI checks run on Google Vertex AI. Audit logs are written to Firestore. This is the standard model for Core and Protect plans.

On-premises / hybrid

For organizations that cannot allow content to leave their network — common in defense, healthcare, and financial services — PillarShield can be deployed on the customer's own infrastructure using their own AI models.

In this model:

  • Content stays on the customer's network. Evaluation happens locally. No content is transmitted to PillarShield's cloud or any third-party AI provider.
  • AI models are customer-owned. The customer runs the model of their choice on their own hardware. PillarShield is model-agnostic and supports configurable timeout thresholds to accommodate varying model performance.
  • Audit logs are transmitted to PillarShield's Firestore. Only audit metadata is sent: decisions, actor IDs, roles, timestamps, content hashes, and violation details. No content, no PHI, no CUI, no cardholder data — only governance decisions and evidence.

This separation means:

Data typeWhere it livesWho controls it
Content being evaluatedCustomer's infrastructureCustomer
AI model and inferenceCustomer's infrastructureCustomer
Audit log entriesPillarShield FirestorePillarShield
Retention, export, Compliance PacksPillarShield FirestorePillarShield

Because audit logs never contain regulated content, the data returning to PillarShield's infrastructure does not carry PHI, CUI, or other protected classifications. Compliance Packs (retention, evidence export) function identically across all deployment models.

On-premises deployment is available on Managed and Enterprise plans. See the on-premises installation guide for setup instructions.

What PillarShield does not do

  • Does not store content. We evaluate content at the publish boundary and record the decision and a hash. We do not retain the full content body after evaluation.
  • Does not train on your data. Content is never used to train any AI model. Vertex AI API usage is transient and non-retaining.
  • Does not expose internal logic. Prompts, policy directives, and detection rules are never visible in the product UI or API responses.

Questions

If you have questions about PillarShield's security posture or need documentation for your own compliance process, contact us.