Overview
Vectara’s security overview gives a clear, high-level look at how the platform protects data and user access across every layer. It outlines our approach to compliance, encryption, data storage, data privacy, platform infrastructure, and access control. The goal is to provide a straightforward summary of the controls, safeguards, and operational practices that keep customer data protected across all deployments.
Deployment Modes
The Vectara platform can be used in a variety of deployment modes. All of the core platform security features, such as access controls, encryption, and observability, are available across all three modes.
But the modes differ in terms of additional layers of security that are available.
- SaaS - Platform software and infrastructure run within Vectara’s cloud infrastructure. Tenants can run on logically isolated partitions within shared resources, or they can run on dedicated infrastructure.
- VPC - Platform software and infrastructure stack run within the customer’s cloud environment. No data ever leaves the customer’s VPC. Can run in an airgapped configuration or can leverage cloud services (e.g. integrate with the customer’s DataDog for monitoring).
- On-Premise - Platform software and infrastructure stack run within the customer’s data center, in an airgapped manner. No data ever leaves the customer’s network.
Security and Compliance
Vectara maintains a comprehensive security and compliance framework designed to protect customer data across every layer of its platform. We are certified in SOC 2 Type II, demonstrating adherence to stringent controls in security, availability, and processing integrity, and are also HIPAA certified, ensuring compliance with standards governing sensitive healthcare information. Vectara’s cloud infrastructure is deployed in isolated Virtual Private Cloud (VPC) environments, ensuring strong network segmentation and separation of customer workloads. These environments inherit industry standard physical and infrastructure security controls such as; ISO/IEC 27001, ISO/IEC 27017, SOC 1–3, PCI DSS, HIPAA, and CSA STAR. These facilities implement restricted physical access, biometric and badge-controlled entry, 24/7 surveillance, intrusion detection, and strict personnel authorization policies.
What are the data protection standards Vectara has attained (SSAE-16, FISMA etc.)?
Vectara's attained data protection standards include: SOC 2 Type II: This widely recognized compliance standard demonstrates that Vectara has established and followed robust controls for security, availability, and processing integrity over an extended period. HIPAA: Vectara is also HIPAA certified, ensuring compliance with the Health Insurance Portability and Accountability Act which protects sensitive patient health information. Vectara’s SOC 2 Type II certification demonstrates a strong commitment to data protection that may encompass many aspects of other standards.
For Cloud infrastructure: Vectara's cloud infrastructure is hosted on AWS and GCP, both of which have achieved a wide range of certifications including ISO/IEC 27001, ISO/IEC 27017, SOC-1, SOC-2, SOC-3, PCI DSS, HIPAA, CSA Star. This provides a comprehensive approach to data protection at the infrastructure level.
Does Vectara have SAML-based SSO support?
Yes, Vectara supports SAML 2.0-based Single Sign-On (SSO) for customer user access.
- Customers can set up SSO federation to a SAML 2.0-based identity provider.
- Already authenticated users will be automatically logged into the Vectara AI platform.
- Unauthenticated users are redirected to their Identity Provider's (IdP) login portal.
- Features like password policies and multi-factor authentication are enforced by the IdP. Vectara permissions are mapped from groups or claims associated with the user’s IdP identity.
What physical security measures are in place at the data processing facility?
When deploying Vectara as a cloud-based GenAI platform, Vectara utilizes infrastructure provided by AWS and GCP. Therefore, the physical security measures in place at the data processing facilities where customer data is stored are those implemented by these cloud providers. These measures generally align with industry standards and certifications like ISO/IEC 27001, SOC-1, SOC-2, SOC-3, PCI DSS, HIPAA, CSA Star, and FedRAMP. While specific details may vary depending on the chosen region and provider, some examples of physical security measures include:
Restricting Physical Access:
- Limited physical access to data centers and facilities to only authorized personnel.
- Implementation of physical barriers like fences, gates, and locks at entry points.
- Controlled entry and exit through designated access points, potentially utilizing access cards or biometric controls.
Monitoring and Surveillance:
- Surveillance cameras within and around the premises to monitor and record activity.
- Perimeter monitoring, motion detection, and intrusion alarms.
Employee Control:
- Strict control over who has access to sensitive areas, including role- and responsibility-based access.
Do you regularly perform vulnerability threat assessments, penetration testing and code reviews? And which ones are performed by an independent 3rd party?
Vectara employs regular security scans and penetration testing. Vectara has a documented software lifecycle development process that includes code review for security vulnerabilities and regular updates.
- Vectara engages with Tenax Solutions to perform an annual Penetration Test. Our most recent Pen Test results are provided.
- Vectara uses Amazon ECR to scan base images and Amazon Inspector for vulnerability management.
- No code can be pushed to production without a code review by a designated security expert engineer.
Are you certified for compliance with any regulatory standards like SOX, ISO 27001, etc?
Vectara is SOC 2 Type 2 and HIPAA certified.
Encryption
Vectara employs a multi-layered encryption framework to ensure data protection at all times. All data is encrypted in transit using TLS 1.3 and encrypted at rest using AES-256 symmetric encryption, with Vectara also implementing GCM (Galois/Counter Mode) for stronger security guarantees. Each corpus within the platform is encrypted with its own unique symmetric key, ensuring strict data isolation. The account-level master key is stored on FIPS 140-2 compliant hardware and used to control access to the corpus-level keys. Vectara also supports ECC (Elliptic Curve Cryptography) for modern, high-assurance cryptographic compatibility. Data backups follow the exact same security model as primary storage: AES-256 encryption at rest, TLS 1.3 in transit, and hierarchical key management governed by either Vectara-managed or customer-managed keys.
How is the data going to be encrypted at rest? What type of encryption is used? How are the encryption keys managed?
For encryption at rest:
- Vectara uses AES 256-bit symmetric key encryption to protect user data (text and metadata) stored on disk.
- Each corpus (a collection of documents) within Vectara is encrypted with a distinct symmetric key, further enhancing data isolation.
- Access to these keys is controlled through an account master key managed on FIPS 140-2 compliant hardware.
- Customer-managed keys: Users can opt to use their own AWS KMS (Key Management Service) encryption keys, providing them with full control over the encryption process.
- Caution: Disabling or removing a customer-managed KMS key will render the corresponding Vectara corpora inaccessible and unrecoverable.
Are data backups encrypted? What technology is used to encrypt data backups and how are those keys managed?
Yes, Vectara encrypts data backups the same way it encrypts all other customer data.
Does Vectara avoid using CBC cipher mode for data encryption?
Yes, Vectara avoids it, we use GCM (Galois/Counter Mode).
Does Vectara support ECC (Elliptic Curve Cryptography) encryption?
Yes, Vectara supports ECC.
Data Storage
Vectara’s data storage architecture is designed to ensure efficient retrieval, strong data isolation, and high availability across all deployments. In the SaaS deployment, all document data, embeddings, and metadata are stored within AWS in the us-west-2 region. For VPC deployments, the entire software stack runs in the customer’s cloud region, determined by customer requirements and available GPU capacity.
Vectara stores multiple categories of data, including tenant metadata, document content, and telemetry, each backed up according to schedules that VPC customers can customize to meet disaster recovery needs. By default, a production installation replicates all data three times within the same data center for durability. At the same time, backups are transmitted to the cloud provider’s object storage in another region with geographically and logically separated replication. During runtime, only the index, raw text, and metadata are accessed and cached in memory; Vectara never stores original documents and therefore never accessed or temporarily cached at any stage.
Is retrieval done directly from the vector index, or does the system also fetch or reference the original source documents during response generation?
At query time, retrieval is done directly from this persisted data: i.e. the index, raw text, and metadata. Vectara does not fetch or otherwise access the original source documents at query time. If there are metadata fields that reference the original source documents (e.g. “url”, or “title”, or “document_name”) then those can be used to reference or link to the original source documents, but this is optional.
Where are the documents and embeddings physically stored (region and cloud provider)?
When using the SaaS offering, the entire storage tier (vectors, extracted raw text, metadata) resides within AWS, in the us-west-2 region. When using the VPC offering, the entire software stack runs in the customer’s cloud region, the cloud provider can be either AWS or GCP, and the region is decided by the customer (provided there are adequate compute services and inventory, such as compute nodes with the required GPUs). When using the on-premise offering, the entire software stack run on infrastructure within the customer’s data center.
How is the data backed up so that you offer high availability?
The Vectara platform uses multiple data stores to store the different types of data it manages. It has metadata about its users, the actual document data that has been indexed, and telemetry data for user workloads. In a VPC install, each of these backup schedules can be specified by the customer to suit their disaster recovery requirements. All backups get sent to the cloud provider's object store in another region, which is highly replicated onto geographically and logically separated storage.
How many copies of the data are stored, and where are they stored?
The customer and their cost requirements can specify the replication count. The basic production install replicates all data 3 times, within the same data center. Backups will replicate that data on a schedule to a separate data center/region.
If the original documents are accessed, where are they stored and how is that access secured?
The original documents are not stored at index time, and therefore cannot be accessed at retrieval time.
If documents are accessed during runtime, are they cached or temporarily stored?
During runtime the only data that is accessed is the index, extracted raw text, and metadata. This data is cached in memory within query serving nodes. The original documents are not accessed during runtime.
Data Privacy
Vectara AI models never train on company data. Vectara’s data privacy model is built on strict isolation, controlled access, and secure retrieval architecture that ensures customer information remains protected throughout the search and query lifecycle. When data is ingested, Vectara does not store original documents; instead, it persists only vectors, lexical indexes, extracted raw text/tables/images, and metadata, using these elements exclusively for retrieval, filtering, and summarization rather than as a document repository. All customer data is housed within a secure, multi-tenant storage and query system, with strong tenant-level isolation that prevents any cross-account access.
Isolation is further strengthened within the VPC deployment model, where all compute and storage reside entirely in the customer’s cloud account, and can also be enhanced in the SaaS offering through dedicated tenant infrastructure. Access to data is rigorously governed by a combination of Role-Based Access Control, allowing customers to assign permissions across Owner, Account Admin, Billing Admin, Corpus Administrator, and corpus-level roles. Vectara personnel may only access customer data when explicitly authorized and strictly necessary for maintenance or support, and any sub-processors engaged are contractually bound to confidentiality with access limited to essential processing activities. If legally compelled to disclose customer data, Vectara provides notice unless prohibited, and may only use aggregated, anonymized data for product improvement without identifying any customer or individual.
Do Vectara's custom models train on my data?
Vectara never trains any models on customer data.
How does Vectara retrieve or access our document data at query time?
When data is ingested into Vectara, the original source documents are not stored within Vectara. Only the index (vectors and lexical indexes), the extracted raw text/tables, and the metadata are persisted within Vectara. The index is used for retrieval matching; the extracted raw text/tables are returned in search results (i.e., to show to the user) and is passed into the LLM for response summarization; and the metadata is used for filtering and reranking. It acts as a semantic search and response engine and not as a document repository.
Vectara accesses this data through a secure, multi-tenant storage and query system with the following key characteristics:
- Customer data is stored with strict isolation between tenants, making it impossible for one account holder to access another's data.
- Within the VPC offering, there is an almost absolute level of tenant isolation, because all compute and storage reside within the customer’s cloud account.
- Within the SaaS offering, it is possible to run a customer’s tenant on dedicated infrastructure, for a stronger level of tenant isolation.
- Role-Based Access Control determines user permissions for accessing, reading, and writing to indexes (referred to as corpora).
- Attribute-Based Access Control allows data to be tagged with attributes for granular access control at both document and text section levels.
Who can see or have access to our company's data?
In the Vectara platform, access to customer data is governed by a combination of roles, permissions, and security measures designed to restrict access to only those authorized and necessary individuals or systems.
Here's a breakdown of who can access customer data:
- Customer-assigned roles and permissions: Customers themselves define and control access to their data within the Vectara platform through roles like Owner, Account Admin, Billing Admin, Corpus Administrator, and Corpus-level roles (QRY, IDX, ADM).
- Vectara personnel with strict authorization: Vectara personnel have restricted access to customer data and are only allowed to access it when explicitly authorized and deemed necessary to maintain or provide services as outlined in the Vectara Security Standards.
- Sub-processors: Vectara may engage sub-processors to perform specific processing activities. These sub-processors' access is limited to what is essential for the service, and they are contractually bound by confidentiality and data protection obligations.
- Law enforcement/government authorities: Vectara states that if compelled by law to disclose customer data, they will provide reasonable notice to the customer, unless legally prohibited from doing so.
- Vectara personnel for data aggregation and analysis (anonymized): Vectara has the right to collect and analyze customer data and other performance-related information in an aggregated and anonymized format that does not identify the customer or any individual, which they can use for product improvement.
How is the data purged so that the data is deleted completely, and there are no remnants of deleted data, therefore, not subject to attack or e-discovery?
The Vectara platform will delete documents logically from all of its stores using the operating system provided features to delete data. Our data stores periodically run jobs to flush all deleted data from disk completely. Then the infrastructure provider must ensure their storage/disk fully deletes the data, which happens automatically when running in SaaS or VPC mode.
Observability
What type of workload observability is provided?
Vectara captures detailed telemetry on user workloads, including information such as user input, system output, and metadata explaining what was done during execution. This telemetry data can be exported into external tools for analysis and troubleshooting.
What type of monitoring data is collected?
The Vectara platform produces logs covering platform operations as well as user events. It also generates metrics and traces. In the VPC and on premise deployment modes this log data can be integrated into external tools, such as a monitoring or alerting system, a SIEM tool, or an analytics platforms.
Platform Infrastructure
What process is used to securely index customer data?
Vectara’s platform infrastructure is designed to securely support diverse enterprise content formats while ensuring consistent ingestion, parsing, and indexing across all data sources.
The platform’s indexing pipeline is built to handle both files and raw text through Vectara’s indexing APIs. When a supported file is submitted, the system parses the document to extract text and tables, divides the parsed output into structured chunks, and applies vectorization to each chunk using partial overlaps so that contextual information from surrounding text is preserved. These vectors are then securely stored in the vector database, while the corresponding raw text or table data for each chunk is stored in the document database. The process mirrors this workflow for raw text ingestion, with the added option for users to submit text that has already been chunked, bypassing the platform’s parsing and chunking steps entirely. Together, these components form a consistent, secure infrastructure for ingesting, transforming, and indexing content across varied enterprise environments.
What safeguards are in place to minimize impact of malicious user inputs?
Vectara applies guardrails, input sanitization, and prompts engineered with security in mind to protect against prompt injection attacks. This minimizes the opportunities that malicious users have in any attempt to misuse the system or the underlying LLMs.
Vectara allows users to provide additional instructions to the system to ensure that the conversational AI remains on topic, stays compliant with policy, and prevents the usage of inappropriate language.
In cases where the developers provide custom code snippets to be executed (e.g. custom prompts, user-defined function reranker, lambda tools) this code is executed in a restricted, sandboxed compute instance. This limits the ability of malicious developers and minimizes the blast radius in the event that there is a compromise.
Access Control
Vectara’s role-based access controls are engineered to enforce strict, claim-driven authorization across both data sources and granular data attributes, ensuring that users and applications interact only with the content they are explicitly permitted to access. Authorization begins at query time by converting token claims into precise access-control configurations. The first layer determines which data sources a user may search: all ingested content is stored in corpora aligned with its originating source, and if a user lacks the corresponding claim, that corpus is automatically excluded from the query.Even when access to a source is granted, a second layer of authorization applies attribute-based filtering, where indexed data is tagged with attributes (e.g., has_pii). Filter expressions are automatically applied to remove any data whose attributes do not align with the user’s claims. This structure enables customers to implement a strict principle of least privilege across administrator and developer roles, as well as for API Keys and OAuth 2.0–based access for client applications, with all credentials rotatable within the platform.
Vectara’s broader access management relies on a robust authentication and authorization model rooted in Role-Based Access Control, defining clear permission scopes across account-level roles, Owner, Account Admin, and Billing Admin, and corpus-level roles including read (i.e. execute query), write (i.e. add data to index), and admin (i.e. full control). For programmatic access, Vectara uses scoped API Keys and OAuth 2.0 tokens, including Personal, Query, and Index API Keys, offering controlled, corpus-specific permissions and enhanced security for production environments.
How can Vectara's access controls be configured?
Vectara’s access controls can be set up in a way that a principle of least privilege can be followed. This applies to administrator and developer roles (for people who access the Vectara platform directly) as well as to API Keys and OAuth2.0 (for client application access to the Vectara APIs).
How is access management set up? How is the identity and access management (IAM) solution monitored? Do you support SAML-based SSO for customer user access?
User authentication for Vectara is implemented via either basic username/password authentication, or SAML-based SSO. In the SaaS offering the SSO integration is Google SSO. In the VPC or on premise offerings the SSO integration can be done with any compliant IdP (e.g. Okta).
Account Level Roles:
- Owner: Has unrestricted control, including account deletion.
- Account Admin: Manages corpora and users (excluding billing).
- Billing Admin: Focuses solely on billing tasks.
Corpus Level Roles:
- QRY: Provides read-only access for searching a specific corpus.
- IDX: Allows both writing and querying for a specific corpus.
- ADM: Grants full control over a specific corpus.
- API Keys & OAuth Tokens: Used to authenticate API requests and are scoped to individual corpora or the account level.
- Personal API Key: Inherits the permissions of the associated user account for administrative tasks or prototyping.
- Query API Key: Provides read-only search operations for a specific corpus, typically for front-end applications.
- Index API Key: Allows both read and write access (indexing and querying) for a specific corpus, often used for server-side operations.
- OAuth 2.0 Token: Recommended for production applications, offering enhanced security and flexibility, according to Vectara.
