# Connect Amazon Bedrock Knowledge Base to Google Drive

Amazon Bedrock Knowledge Base Google Drive integration connects foundation models to corporate documents, but native vector ingestion requires managing recurring sync delays, document permissions, and persistent OpenSearch Serverless compute costs. An alternative architecture syncs Google Drive folders into Fast.io workspaces, providing pre-indexed hybrid search and direct Model Context Protocol retrieval without dedicated vector infrastructure.

Source: https://fast.io/resources/bedrock-knowledge-base-google-drive/
Author: [Derek Labian](https://fast.io/authors/derek-labian/)
Last reviewed: 2026-10-25

## Why Cloud Storage Architecture Dictates Enterprise Foundation Model Performance

Pointing a foundation model at Google Drive sounds simple until an enterprise security team asks who can see what, how quickly modified documents update, and how much it costs to keep an idle vector database online. In a standard enterprise architecture, files live in cloud storage, but foundation models cannot read raw directory trees at inference time. Every Retrieval-Augmented Generation system requires an ingestion bridge: a mechanism that extracts text from slides, sheets, and documents, chunks passages into retrievable fragments, generates high-dimensional embeddings, and indexes them for similarity search.

Amazon Bedrock Knowledge Base Google Drive integration connects foundation models to cloud documents, allowing enterprise agents to retrieve factual context from shared corporate drives. Rather than building custom extractors with AWS Lambda, Amazon Textract, and self-hosted vector databases, developers can point [Amazon Bedrock Knowledge Bases](https://aws.amazon.com/bedrock/knowledge-bases/) directly at a cloud repository. The managed service crawls document hierarchies, computes embeddings using models like Amazon Titan Text Embeddings or Cohere Embed, and populates vector indices in Amazon OpenSearch Serverless, Pinecone, or Amazon Aurora PostgreSQL.

Yet connecting enterprise storage directly to a managed RAG pipeline exposes fundamental engineering tradeoffs across synchronization latency, credential delegation, and infrastructure expense. Knowledge bases require periodic synchronization to remain accurate. When files change in Google Drive, the pipeline must detect modifications, re-extract text, recalculate vector embeddings, and update indices without blowing past API rate limits or ballooning vector infrastructure bills. Google Workspace access controls also do not automatically translate into vector search filters unless the integration is configured with domain-wide service account delegation.

Developers evaluating this integration face a choice between two distinct architectures:

1. **Native Managed Vector Pipelines:** Ingesting Google Drive folders directly into AWS Bedrock Knowledge Bases, storing vector representations in a dedicated vector index, and managing recurring synchronization jobs.
2. **Workspace-Mediated Retrieval:** Syncing active Google Drive folders into an intelligent workspace layer like [Fast.io workspaces](/product/workspaces/), where documents are automatically indexed for hybrid keyword and semantic search, and querying them on demand through the Model Context Protocol (MCP).

Understanding how the native AWS Bedrock Google Drive connector operates, where operational friction emerges, and how workspace architectures compare is essential for building responsive agent workflows.

### Why Enterprise Context Lives in Cloud Storage

Corporate documentation rarely lives in clean, structured databases. Project charters, vendor contracts, architecture decision records, customer briefs, and product specifications accumulate across Google Drive, Microsoft OneDrive, Dropbox, and Box. For AI agents to answer employee inquiries or automate research, they must access these files where teams actually collaborate.

Traditional custom ingestion pipelines broke frequently: Google Drive API rate limits halted batch jobs, file format revisions corrupted chunking logic, and document permission changes failed to propagate to the retrieval layer. The native AWS Bedrock data source connector standardizes this pattern by abstracting document parsing and chunking for Google Drive, Microsoft OneDrive, Confluence, and Salesforce. However, managing this connector requires careful preparation across identity systems, secret management, and vector storage sizing.

### Ingestion Pipelines Versus On-Demand Context Retrieval

A critical distinction in enterprise agent design is the difference between a dedicated ingestion pipeline and an on-demand retrieval interface. A dedicated ingestion pipeline copies, chunks, and embeds your entire document repository into an external vector database, duplicating every document as high-dimensional vectors in AWS infrastructure.

By contrast, on-demand retrieval interfaces allow agents to search, browse, and read documents directly from an indexed workspace via standard tool protocols. When an agent needs context, it executes a targeted search across file metadata, full text, and semantic passages, pulling only the relevant excerpts into its context window. This architectural difference determines your monthly AWS cloud bill, how quickly agents see file updates, and how easily teams can review which files have changed.

## How to Connect Bedrock Knowledge Base to Google Drive

Configuring the native Google Drive connector in Amazon Bedrock Knowledge Bases requires coordination between Google Cloud Platform (GCP), Google Workspace Admin, and AWS Secrets Manager. Before Amazon Bedrock can crawl any file, it must be granted explicit authorization to read drive hierarchies and impersonate organizational identities.

Amazon Bedrock supports two distinct authentication methods for Google Drive:

* **Service Account Authentication (`SERVICE_ACCOUNT`):** Recommended by AWS for enterprise deployments. A Google Cloud service account configured with domain-wide delegation authenticates using a private key and impersonates a designated Google Workspace admin user. This setup allows the connector to crawl personal drives, shared drives, and files shared across the entire domain. Crucially, this is the only authentication method that supports document-level access control (ACLs).
* **OAuth 2.0 Authentication (`OAUTH2`):** Uses an OAuth client ID, client secret, and a refresh token generated from an individual user's sign-in. The connector can only access files and folders that specific user has permission to view. While OAuth 2.0 does not support document-level ACLs, it is the only method that allows granular folder ID and file ID filtering during data source creation.

The following steps walk through configuring the recommended service account path.

### Step 1: Google Cloud Project and Service Account Configuration

To begin, create or select a dedicated Google Cloud project in the Google Cloud Console.

1. **Enable Required APIs:** In the GCP Console, open APIs and Services, go to the Library, and enable three APIs:
   * Google Drive API
   * Google Drive Activity API
   * Admin SDK API (required for reading user directories and group memberships for ACL filtering)

2. **Create a Service Account:** Go to Credentials and select Create Credentials, then Service Account. Assign a name such as `bedrock-knowledge-base-crawler` and click Create and Continue. Note the service account Unique ID (OAuth 2 Client ID); you will need it in Google Workspace.

3. **Generate a Private Key:** Open the newly created service account, select the Keys tab, click Add Key, select Create new key, and choose JSON. Download the JSON key file and store it securely.

4. **Configure Domain-Wide Delegation in Google Workspace:** Sign in to the Google Workspace Admin Console using an administrator account. Go to Security, then Access and data control, then API controls, and open Manage Domain Wide Delegation. Click Add new, paste the service account Unique ID into the Client ID field, and enter the following OAuth scopes:
   * `https://www.googleapis.com/auth/drive.readonly`
   * `https://www.googleapis.com/auth/admin.directory.user.readonly`
   * `https://www.googleapis.com/auth/admin.directory.group.readonly`

Click Authorize to save the delegation settings.

### Step 2: Storing Credentials in AWS Secrets Manager

Amazon Bedrock does not accept plaintext credentials. You must store the Google service account details in AWS Secrets Manager within the same AWS Region where your Knowledge Base resides.

Create a new secret in AWS Secrets Manager using the AWS Management Console or the AWS CLI:

```bash
aws secretsmanager create-secret     --name "bedrock/googledrive/credentials"     --description "Credentials for Bedrock Google Drive Data Source"     --secret-string file://gcp-service-account-secret.json
```

The secret string must be formatted as a JSON object containing the private key details and the delegated admin user email:

```json
{
  "web": {
    "type": "service_account",
    "project_id": "your-gcp-project-id",
    "private_key_id": "key-id",
    "private_key": "<your-private-key>",
    "client_email": "bedrock-crawler@your-gcp-project.iam.gserviceaccount.com",
    "admin_email": "admin@yourcompany.com"
  }
}
```

Copy the Amazon Resource Name (ARN) of the secret. Your Amazon Bedrock execution role must have IAM permission to access this secret:

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:bedrock/googledrive/credentials-*"
    }
  ]
}
```

### Step 3: Creating and Synchronizing the Data Source

With authentication established, create the data source in Amazon Bedrock.

In the Amazon Bedrock console, go to Knowledge Bases and select your Knowledge Base. Under the Data sources panel, select Add data source and choose Google Drive.

Provide the following settings:

* **Data source name:** A recognizable label such as `corporate-google-drive`.
* **Secrets Manager ARN:** The ARN of the secret created in Step 2.
* **Content filters:** Specify Shared Drive IDs to include or exclude, and select MIME types to crawl. You can exclude spreadsheets or media files if you only need text documentation.
* **Chunking strategy:** Choose your text splitting parameters. Default chunking splits text into fixed-size token segments with boundary overlap. Hierarchical chunking breaks text into parent and child chunks for multi-level context. Semantic chunking evaluates semantic boundaries using foundation models.
* **Parsing strategy:** Standard parsing extracts raw text from common document formats. Advanced parsing routes images, diagrams, and scanned pages through multimodal foundation models for higher fidelity.

Once saved, trigger the initial synchronization by selecting the data source and clicking Sync, or run the ingestion job via the AWS CLI:

```bash
aws bedrock-agent start-ingestion-job     --knowledge-base-id "KB12345678"     --data-source-id "DS12345678"     --description "Initial sync of corporate Google Drive"
```

The crawler traverses the configured folders, reads files, computes vector embeddings, and writes the resulting vectors to your underlying OpenSearch Serverless collection.

### Connecting Microsoft OneDrive as an Alternative Data Source

Teams managing multi-cloud environments often run Microsoft 365 alongside or in place of Google Workspace. Amazon Bedrock Knowledge Bases provides a dedicated Microsoft OneDrive data source connector that functions under a similar managed model.

Connecting OneDrive for Business requires registering an application in Microsoft Entra ID, configuring Microsoft Graph API application permissions (`Files.Read.All`, `User.Read.All`, and `GroupMember.Read.All`), and generating a client secret. The client secret, client ID, and Azure tenant ID are stored in AWS Secrets Manager, allowing Bedrock to authenticate against your Microsoft 365 tenant.

While the Bedrock OneDrive connector crawls user personal drives across the tenant and detects document metadata fields, it shares similar constraints with Google Drive: synchronization runs on scheduled intervals rather than in real time, and certain file types such as Microsoft OneNote notebooks are not supported. Teams running both Google Drive and OneDrive must configure separate data sources, separate secret ARNs, and manage independent sync schedules for each cloud provider.

## Comparing Native Bedrock Vector Pipeline Costs with Operational Friction

While Amazon Bedrock Knowledge Bases simplifies the initial setup of cloud storage connectors, maintaining a native vector pipeline in production introduces persistent operational overhead. Competitor articles frequently praise managed RAG connectors without addressing the recurring infrastructure costs, crawling latency, and API rate limits that emerge as document libraries expand. When evaluation shifts from a single proof-of-concept folder to an entire corporate shared drive, engineering teams quickly discover that vector ingestion pipelines require continuous operational attention, manual credential rotation, and substantial baseline cloud budgets.

Understanding these friction points allows engineering leaders to evaluate whether a full vector ingestion pipeline is appropriate for their workload or if an indexed workspace layer is more practical. The primary operational challenges break down into vector compute commitments, crawling latency, format parsing errors, and permission drift across identity boundaries.

### Persistent Vector Storage and OpenSearch Serverless Expenses

The largest ongoing expense of an Amazon Bedrock Knowledge Base is not the Bedrock inference API itself, but the underlying vector database. When creating a managed knowledge base, AWS defaults to provisioning an Amazon OpenSearch Serverless vector search collection.

OpenSearch Serverless billing is metered in OpenSearch Compute Units (OCUs). A functional vector collection requires dedicated compute capacity:
* Dedicated compute units are allocated for indexing workloads (ingesting documents, calculating vector distances, updating indices).
* Dedicated compute units are allocated for search workloads (querying vectors during agent inference).

Even with zero incoming queries, OpenSearch Serverless maintains minimum baseline compute units to keep the collection available and responsive. Running a standard vector collection with minimum baseline units incurs hundreds of dollars every month in persistent infrastructure fees before accounting for storage volumes or embedding generation calls. For teams with moderate document volumes, this baseline cost runs constantly, even outside business hours.

### Sync Latency and the Stale Context Window

Enterprise files change continuously. Team members edit project briefs, update financial assumptions, and upload revised contract terms throughout the day.

Native AWS Bedrock connectors do not synchronize file changes instantly. The connector relies on batch ingestion jobs triggered either manually or through scheduled intervals (such as daily or weekly EventBridge rules). During the interval between sync jobs, your foundation models operate on stale vector representations. If an executive modifies an agreement in the morning and the scheduled sync does not execute until midnight, any AI agent querying the knowledge base during the workday will retrieve outdated information. Accelerating sync schedules increases costs because every ingestion run issues hundreds or thousands of Google Drive API calls, re-evaluates file hashes, and passes modified chunks through embedding models.

### Proprietary Format Conversion and API Rate Limits

Corporate drives contain more than standard PDF and text files. A large portion of Google Drive content exists as proprietary web formats: Google Docs, Google Sheets, and Google Slides.

To ingest these files into a vector store, the crawler must convert them on the fly. Google Docs are exported to plain text or PDF, Google Sheets are serialized into text representations, and Google Slides are rendered into slides or text blocks. Complex tabular data in Google Sheets frequently loses column relationships when flattened into linear text chunks, leading to degraded retrieval accuracy for financial and operational queries. Crawling large shared drives containing tens of thousands of items can also exhaust Google Drive API quotas, causing ingestion jobs to fail mid-crawl.

### Access Control Synchronization Drift

Although service account authentication supports document-level access control, maintaining authorization parity between Google Workspace and AWS Bedrock is difficult in practice.

When a document's permissions are updated in Google Drive (for example, removing an employee from a shared folder or altering group permissions), the change is not immediately reflected in OpenSearch vector metadata. The access control list stored with the document chunk remains static until the next ingestion job re-indexes the file. If an agent executes a query on behalf of a user whose access was recently revoked, the retrieval layer may inadvertently expose confidential text snippets.

## Workspace-Mediated Retrieval with Fast.io Cloud Sync and MCP

Rather than duplicating entire document corpuses into expensive, standalone vector databases, engineering teams are increasingly turning to intelligent workspace architectures. In this model, you keep your primary files where teams already collaborate, sync project folders into an intelligent workspace, and grant AI agents direct access via standard protocols.

Fast.io provides an intelligent workspace platform designed for agentic teams. Instead of requiring developers to provision vector clusters, configure embedding dimensions, and manage chunking pipelines, Fast.io incorporates search and indexing directly into the storage substrate.

Cloud Sync connects Google Drive, Dropbox, Box and OneDrive folders to a workspace, one-way or two-way, on a schedule or on demand. When files sync into a Fast.io workspace, they are immediately available for both human collaboration and autonomous agent operations.

### Zero-Pipeline Hybrid Search with Intelligence Mode

Fast.io eliminates the need to deploy and manage a standalone vector database. When Intelligence Mode is enabled on a workspace, incoming files are automatically indexed for hybrid search, combining full-text keyword matching, semantic embeddings, and metadata filtering.

Unlike native vector connectors that force developers to choose between fixed chunk sizes and complex hierarchical parsers, Fast.io handles document parsing, indexing, and retrieval internally. When an agent queries a workspace, the [hybrid search](/product/ai/) engine evaluates both lexical relevance and semantic meaning, returning precise document passages accompanied by verifiable file citations. Because search runs as an integrated workspace capability, teams avoid persistent baseline compute fees.

### Agent Connectivity Through the Model Context Protocol

Instead of siloing document retrieval behind proprietary cloud provider APIs, Fast.io exposes its workspace capabilities through the Model Context Protocol (MCP), the open standard for connecting AI models to tools and data.

Fast.io operates a remote MCP server hosted at `mcp.fast.io` over Streamable HTTP, providing tailored endpoints for different client environments:
* **Claude Apps and General Clients:** Connect at `https://mcp.fast.io/mcp/tools` with interactive OAuth sign-in. This endpoint serves Claude Desktop, Claude web and mobile apps, Claude Cowork, and autonomous agent runtimes.
* **ChatGPT and Codex:** Access through the curated Fastio plugin in the ChatGPT plugin directory, or configure a custom MCP server at `https://mcp.fast.io/mcp/operations`.
* **Coding Agents and IDEs:** Connect at `https://mcp.fast.io/mcp/code` for developer-focused agents including Claude Code, Cursor, Gemini CLI, Cline, and GitHub Copilot.

Through these endpoints, agents dynamically search workspaces, inspect folder trees, and read document content. Developer setup guides are available at [https://mcp.fast.io/docs](https://mcp.fast.io/docs), and agent tooling guidelines are documented in [https://mcp.fast.io/skill.md](https://mcp.fast.io/skill.md).

In published connector benchmarks comparing native cloud storage connectors in Claude Cowork (available at [https://fast.io/benchmarks/](https://fast.io/benchmarks/)), Fast.io was measured the fastest and the lowest cost of the providers tested. Accuracy was parity across the evaluated providers.

### Structured Document Extraction with Metadata Views

RAG systems often struggle when agents need structured answers from large document sets, such as extracting expiration dates from vendor contracts or comparing pricing tiers across customer agreements.

Fast.io addresses this with [Metadata Views](/product/document-data-extraction/). Metadata Views turn unstructured documents into live, queryable spreadsheets without requiring custom OCR templates or regex extraction scripts. Users describe the fields they want in natural language, and Fast.io extracts typed values (Text, Integer, Decimal, Boolean, URL, JSON, Date and Time) across PDFs, Word documents, spreadsheets, and scanned files. Agents can query Metadata Views directly through the Fast.io MCP server, retrieving structured data instantly.

## Steps to Connect AI Agents to Cloud Storage via Fast.io MCP

Deploying an intelligent workspace for your Google Drive files requires four straightforward steps: configuring folder synchronization, enabling workspace intelligence, connecting your AI agents over MCP, and establishing organizational governance. Teams evaluating [alternatives to Google Drive](/alternatives/google-drive/) find that maintaining files in existing storage while exposing them through an intelligent workspace gives them the benefits of agentic automation without migrating their core document repository.

This approach gives agents on-demand search capabilities across project documents while maintaining human oversight, a detailed activity log of changes, and per-file version history. Rather than maintaining custom crawling pipelines, developers can establish a complete connection in minutes without managing separate vector pipelines. The following instructions guide you through linking storage, activating search indexing, configuring client applications, and establishing collaborative controls across team members and agents.

### Step 1: Configure Cloud Sync for Google Drive

Sign in to Fast.io and create a new workspace dedicated to your project or team.

1. In workspace settings, select **Cloud Sync** and choose **Google Drive**. (Fast.io also supports Dropbox, Box, and OneDrive for work or school).
2. Authenticate your Google account using standard OAuth.
3. Select the specific Google Drive folder you wish to link. Rather than indexing an entire corporate drive, you can target the exact folders relevant to your agents.
4. Select your sync direction:
   * **One-Way Sync:** Pulls changes from Google Drive into Fast.io without modifying your original files.
   * **Two-Way Sync:** Synchronizes edits and new files bidirectionally between Google Drive and Fast.io.
5. Select your sync schedule: choose periodic scheduled intervals or trigger synchronization on demand.

Cloud Sync transfers data directly between cloud storage providers without consuming local disk space or network bandwidth.

### Step 2: Enable Intelligence Mode for Instant Search

Once your workspace is created, open **Workspace Settings** and toggle **Intelligence Mode** to active.

Fast.io automatically indexes incoming files for hybrid search. As Cloud Sync pulls documents from Google Drive, the platform extracts text, generates search tokens, and builds semantic indices in the background.

Unlike AWS Bedrock Knowledge Bases, which requires creating an Amazon OpenSearch Serverless collection and configuring vector index mappings, Fast.io prepares the search index automatically. You do not need to configure embedding models, vector dimensions, or distance metrics.

### Step 3: Connect AI Clients via the Fast.io MCP Server

AI agents can connect to your workspace using the remote Fast.io MCP server over Streamable HTTP. Teams can explore setup details and documentation at [storage for agents](/storage-for-agents/).

For Claude (web, desktop, mobile): open Customize, then Connectors; add a custom connector and paste `https://mcp.fast.io/mcp/tools`; select Connect and sign in to Fastio in the window that opens; in a chat, turn Fastio on from the + menu under Connectors.

For autonomous agent scripts, backend services, or CI/CD pipelines, configure your agent to connect over Streamable HTTP using a scoped Fast.io API key passed in the authorization header:

```http
POST /mcp/tools HTTP/1.1
Host: mcp.fast.io
Authorization: Bearer YOUR_FASTIO_API_KEY
Content-Type: application/json
Accept: application/json, text/event-stream
Mcp-Session-Id: session-12345
MCP-Protocol-Version: 2024-11-05

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "storage",
    "arguments": {
      "action": "search",
      "query": "cloud infrastructure SLA commitments",
      "workspace_id": "ws_12345678"
    }
  }
}
```

The MCP server executes a hybrid search across the workspace and returns the most relevant document passages along with exact file citations. Agents can use these citations to cite their sources directly in customer-facing responses.

### Step 4: Multi-Agent Governance and File Versioning

When multiple agents and team members collaborate within a shared workspace, preventing accidental overwrites and tracking changes is critical.

Fast.io includes governance features built specifically for collaborative agent environments:
* **Role-Based Permissions:** Permissions are configured per organization, workspace, and share. Every workspace member reaches content according to their assigned role. When you need to share specific files or an individual folder with an external partner or agent, you can create a dedicated share link with custom access rules.
* **Per-File Version History:** Every edit or upload creates a new version while preserving complete prior revisions. If an agent writes an erroneous summary or overwrites a document, humans can review and restore any previous version instantly.
* **Detailed Activity Log:** Fast.io maintains a detailed activity log of changes across the organization. The log records file uploads, modifications, moves, deletions, membership updates, and share creation, providing full visibility into what humans and agents changed.
* **Advisory File Locks:** For concurrent multi-agent workflows, agents can acquire temporary advisory file locks via MCP actions (`lock-acquire` and `lock-release` on the `storage_manage` tool) to signal that a file is actively being modified, preventing race conditions.

Monthly plans start with a 14-day free trial that requires a credit card. Review [Fast.io pricing](/pricing/) for plan options: Starter at `$9.99/mo` (`3 seats`, `250 GB` storage, `5 workspaces`, `100,000 credits` a month), Business at `$49.99/mo` (`10 seats`, `5 TB` storage, `50 workspaces`, `600,000 credits` a month), and Enterprise at `$199.99/mo` (`30 seats` included, `25 TB` storage, `200 workspaces`, `3,000,000 credits` a month). Annual plan pricing options are available at `$99`, `$499`, and `$1,999` per year. Credits meter AI operations, and credit overage is billed at `$10` per `100,000 credits`.

## Frequently asked questions

### Can Amazon Bedrock Knowledge Base connect to Google Drive?

Yes. Amazon Bedrock Knowledge Bases provides a native Google Drive connector that crawls personal drives, shared drives, and files shared across a domain. It supports service account authentication with domain-wide delegation for document-level access control, as well as OAuth 2.0 authentication for single-user access.

### How do I sync Google Drive files to AWS Bedrock?

To sync Google Drive files to Amazon Bedrock, store your Google Cloud service account key or OAuth credentials in AWS Secrets Manager, create a Google Drive data source in your Bedrock Knowledge Base pointing to the secret ARN, and trigger an ingestion job via the AWS Console or the StartIngestionJob API. Bedrock crawls the drive, extracts text, computes embeddings, and updates your vector database.

### What are the limitations of Bedrock Knowledge Base Google Drive connector?

Key limitations include lack of real-time synchronization, ongoing infrastructure costs for dedicated vector databases like Amazon OpenSearch Serverless, potential Google Drive API rate limits during bulk crawls, and loss of tabular formatting when exporting proprietary Google Sheets and Docs into plain text.

### Can Amazon Bedrock Knowledge Base connect to Microsoft OneDrive?

Yes. Amazon Bedrock Knowledge Bases supports Microsoft OneDrive for Business as a native data source. It uses Microsoft Entra ID app credentials stored in AWS Secrets Manager to crawl the personal drives of users across a Microsoft 365 tenant, though OneNote notebooks are not supported.

### How does Fast.io Cloud Sync differ from native Bedrock data source ingestion?

Native Bedrock ingestion crawls cloud drives, generates vector embeddings, and stores them in a standalone vector database that incurs persistent monthly compute charges. Fast.io Cloud Sync synchronizes folders into an intelligent workspace where files are automatically indexed for hybrid search, allowing agents to query context on demand via the Model Context Protocol without managing vector infrastructure.

### Does Fast.io sync with Google Drive?

Yes. Fast.io Cloud Sync connects Google Drive, Dropbox, Box and OneDrive folders to a workspace, one-way or two-way, on a schedule or on demand. Files sync directly between cloud services without local disk input or output.

## Sources

- [Amazon Web Services: Amazon Bedrock User Guide](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-ds-googledrive.html): Service account authentication with domain-wide delegation allows Amazon Bedrock to access Google Drive content across a domain and supports document-level access control.
- [Amazon Web Services: Amazon Bedrock User Guide](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-ds-onedrive.html): Amazon Bedrock Knowledge Bases supports connecting OneDrive for Business instances to crawl the personal drives of users across a Microsoft 365 tenant.

## About Fast.io

Fast.io provides shared workspaces where people and AI agents work on the same files, with built-in semantic search and citation-backed chat over what they hold. Agents reach it through a remote MCP server, a REST API at https://api.fast.io/current/, and a command line client published on npm as @vividengine/fastio-cli. MCP setup is at https://mcp.fast.io/docs: Claude and most MCP clients connect to https://mcp.fast.io/mcp/tools, ChatGPT to https://mcp.fast.io/mcp/operations, and coding agents to https://mcp.fast.io/mcp/code.