<a id="vs-security"></a>

# Vector Search Security

This page describes the security model for Vector Search in ScyllaDB Cloud,
including authentication, authorization, data privacy, and network security.

<a id="vs-security-overview"></a>

## Overview

Vector Search in ScyllaDB Cloud runs on dedicated vector nodes that are
separate from the core ScyllaDB storage nodes. The integration is fully
transparent — your application connects to ScyllaDB through the standard CQL
protocol and all vector search queries are handled automatically.

From a security perspective:

* **You use the same credentials and permissions** as for any other CQL
  operation. No separate authentication or configuration is required for
  vector search.
* **The vector store’s access to your data is secured internally** by
  ScyllaDB Cloud. The vector store nodes connect to ScyllaDB using a
  dedicated service account with restricted permissions, limited to reading
  only the data required for building and maintaining vector indexes.
  Communication between ScyllaDB nodes and vector store nodes is encrypted.

<a id="vs-security-authentication"></a>

## Authentication

Vector search queries use the same CQL authentication mechanism as regular
ScyllaDB queries. No separate credentials are needed for vector search
operations.

* **Authentication provider** — Connect using `PlainTextAuthProvider`
  (username/password), the same as for any CQL connection to ScyllaDB Cloud.
* **No separate credentials** — The same database users and credentials that
  access your ScyllaDB tables also have access to vector search operations
  on those tables.

Example connection with authentication:

```python
import ssl
from cassandra.cluster import Cluster
from cassandra.auth import PlainTextAuthProvider

auth = PlainTextAuthProvider(username='scylla', password='YOUR_PASSWORD')
ssl_context = ssl.create_default_context()
cluster = Cluster(
    contact_points=['node-0.your-cluster.cloud.scylladb.com'],
    port=9042,
    auth_provider=auth,
    ssl_context=ssl_context,
)
```

#### NOTE
If you access ScyllaDB through the Alternator (DynamoDB) API, connect with
your Alternator credentials (access key and secret key) instead of CQL
credentials. As with CQL, no separate credentials are required for vector
search operations. See
[Vector Search with Alternator](https://cloud.docs.scylladb.com/stable/vector-search/vector-search-alternator.md).

<a id="vs-security-authorization"></a>

## Authorization

CQL-level authorization (`GRANT` / `REVOKE` permissions) applies to
vector search operations. The standard ScyllaDB permission model determines
what each user can do:

| Operation                                          | Required Permission   |
|----------------------------------------------------|-----------------------|
| Create a vector index (`CREATE CUSTOM INDEX`)      | `ALTER` on the table  |
| Drop a vector index (`DROP INDEX`)                 | `ALTER` on the table  |
| Insert vector data (`INSERT`)                      | `MODIFY` on the table |
| Run ANN queries (`SELECT ... ORDER BY ... ANN OF`) | `SELECT` on the table |

Authorization is enforced at the CQL layer before the query reaches the
vector search nodes. This means:

* Users without `SELECT` permission on a table cannot run similarity
  queries against that table’s vector indexes.
* Users without `ALTER` permission cannot create or drop vector indexes.
* The same role-based access control (RBAC) you use for regular CQL
  operations applies to vector search.

Example:

```cql
-- Allow the 'analyst' role to query vectors but not modify data
GRANT SELECT ON myapp.comments TO analyst;

-- Allow the 'admin' role to create/drop indexes and modify data
GRANT ALTER ON myapp.comments TO admin;
GRANT MODIFY ON myapp.comments TO admin;
```

<a id="vs-security-data-privacy"></a>

## Data Privacy

Vector store nodes need access to a subset of your data (the vector columns
and primary key columns) to build and maintain in-memory indexes. ScyllaDB
Cloud secures this access as follows:

* **Dedicated service account** — The vector store authenticates to ScyllaDB
  using a dedicated role with restricted permissions, managed automatically
  by ScyllaDB Cloud. This role can only read data required for vector
  indexing and cannot modify your data.
* **Dedicated service level** — The vector store’s database operations run
  under a separate service level, isolating its resource consumption from
  your application’s workloads. This ensures that index building and
  maintenance do not compete with your queries.
* **Encrypted communication** — Communication between ScyllaDB nodes and
  vector store nodes uses TLS encryption, protecting data in transit within
  the cluster.

<a id="vs-security-service-level"></a>

## Service-Level Isolation

The vector store operates as a **separate service** on dedicated nodes,
distinct from the core ScyllaDB storage nodes. This means:

* **Independent availability** — Vector search node failures do not affect
  read/write operations on the storage nodes. Regular CQL queries continue
  to function even if vector search nodes are temporarily unavailable.
* **Separate resources** — Vector search nodes have their own
  CPU, memory, and network resources. Memory-intensive vector indexes do not
  compete with storage workloads.
* **Fault domain isolation** — Vector search nodes and storage nodes
  can fail independently. ScyllaDB Cloud deploys vector search nodes across
  Availability Zones to provide redundancy.

The service-level separation is transparent to your application — CQL queries
that include `ANN OF` clauses are automatically routed to the vector search
nodes, while standard queries go to the storage nodes.

<a id="vs-security-network"></a>

## Network Isolation

ScyllaDB Cloud provides network-level isolation between services:

* **VPC isolation** — Vector search nodes run within the same VPC as your
  ScyllaDB cluster, with network access restricted to authorized endpoints.
* **No public exposure** — Vector search nodes are not directly accessible
  from the public internet. All access goes through the CQL protocol and
  the cluster’s connection endpoints.
* **VPC peering and Transit Gateway** — If you use
  [VPC peering](https://cloud.docs.scylladb.com/stable/cluster-connections/aws-vpc-peering.md) or
  [Transit Gateway](https://cloud.docs.scylladb.com/stable/cluster-connections/aws-tgw-vpc-attachment.md),
  the same network controls apply to vector search traffic.

<a id="vs-security-best-practices"></a>

## Best Practices

* **Use role-based access control** — Create separate database roles for
  applications that only need to query vectors (`SELECT`) vs. those that
  need to manage indexes (`ALTER`) or insert data (`MODIFY`).
* **Rotate credentials regularly** — Follow your organization’s credential
  rotation policy for database users.
* **Restrict network access** — Use VPC peering or Transit Gateway to avoid
  exposing your cluster to the public internet.
* **Monitor access** — Review cluster access logs for unexpected
  authentication failures or unauthorized query patterns.

## What’s Next

* [Working with Vector Search](https://cloud.docs.scylladb.com/stable/vector-search/work-with-vector-search.md) —
  CQL syntax for vector tables, indexes, and ANN queries.
* [Vector Search Concepts](https://cloud.docs.scylladb.com/stable/vector-search/vector-search-concepts.md) —
  architecture and design principles.
* [Security Concepts](https://cloud.docs.scylladb.com/stable/security/concepts.md) —
  general database security in ScyllaDB Cloud.