Cloud Drives

Connect a cloud drive once and reuse it across your agents — read and write its files from a workflow, let a model browse it during a tool loop, ingest a folder into a knowledge base, or run an agent automatically whenever a file changes. Dropbox and Google Drive are supported today; the same vendor-neutral integration will cover more providers as they ship.

What a connection powers

A cloud-drive connection is set up once under Integrations → Cloud Drives and is shared across your account. Once connected, it drives four things — each with its full field reference on its own page:

Cloud-drive steps — List Cloud Drive Folder, Read Cloud Drive File, and Write Cloud Drive File operate on a connection on demand inside a workflow.
A cloud-drive tool on a prompt_call step, so the model itself can browse, read, and (optionally) write files during a tool loop — scoped to one connection and bounded by per-run caps.
A cloud-drive content source — ingest a folder into a knowledge base, kept in sync as files are added or updated.
Cloud file triggers — run an agent automatically when a file is added or updated, passing the changed file as the run input.

Steps bind a connection via their Cloud Drive Connection field, and paths and content support string substitutions — so a run can read {{metadata.file_path}} from a trigger or write to /reports/{{datetime UTC}}.txt.

Connecting a drive

Go to Integrations → Cloud Drives and add a connection, choosing Dropbox or Google Drive.
Pick an Access level:
- Read and write (default) — agents can read files and, via the write-file step or the write_drive_file tool, create and update them.
- Read only — agents can read, download and export files but can never modify the drive. Every write step and tool is refused outright, before the drive is even contacted. Choose this whenever an agent only needs to consume documents; it is the safest option and removes an entire class of prompt-injection risk.
Authorize access when redirected. The connection stays on your account and is reusable across agents, tools, sources, and triggers.
Name it and choose what to watch. You land back on the connection with a configuration step open, because this is the first point at which the folder list can be read — before authorizing there is nothing to browse. Pick the Drive (My Drive, or one of your shared drives) and the folder, using Browse… rather than typing a path. Until a folder is chosen the connection watches the whole drive, and the page says so.
Reference it from a step's Cloud Drive Connection picker, a prompt_call cloud-drive tool, a content source, or a cloud file trigger.

If a drive later needs re-authorization, the connection is marked Error and the connection page shows a Reconnect required banner — reconnect it there.

The access level is fixed at the moment you authorize, because it is what the provider granted the token. The connection page shows the current one under Access, with a one-click action to switch — that re-runs the authorization with the other level.

The connection page also shows how changes reach Seclai:

Real-time — the drive notifies Seclai as files change, so agents run within seconds.
Scheduled (hourly) — change notifications aren't currently active, so changes are picked up on the hourly sweep instead. Nothing is lost, it's just slower, and it normally recovers on its own.

If a connection stays on Scheduled for more than a few hours, reconnect it.

Changing the connected account

To point a connection at a different account, disconnecting and reconnecting in Seclai isn't enough on its own: the provider remembers that you already authorized Seclai for the account you're signed into and will silently re-issue access to that same account — so the reconnect can complete without ever showing a sign‑in screen. To switch accounts:

On the connection page, Disconnect (this revokes and deletes Seclai's stored tokens for this connection).
In your browser, sign out of the provider — or, better, remove Seclai from its connected-apps list: Dropbox → Settings → Connected apps, or myaccount.google.com/permissions for Google Drive. This clears the remembered grant so the next authorization starts fresh.
Sign into the account you want, then Reconnect. Seclai always requests the provider's approval screen on reconnect, so you can authorize with the intended account.

Google Drive specifics

Google Drive works like any other connection, with a few differences worth knowing.

Folder paths. Google Drive organizes files by folder rather than by path, so Seclai builds a path for each file from its folders — /Reports/2026/Q3.pdf. Content in a shared drive appears under /Shared drives/<drive name>/…, so you can scope an agent to one shared drive with a path prefix of, for example, /Shared drives/Finance. If two folders in the same place have the same name, Seclai asks you to rename one or reference the folder by id (id:<folderId>) rather than guess which you meant. Shortcuts are skipped.

Capitalization in folder names. Google Drive lets /Reports and /reports exist side by side as two genuinely different folders, so anywhere you name a folder — a watched folder, or a toolset path prefix — spell it exactly as it appears in Drive. A prefix of /reports will not reach a folder named Reports; the agent simply sees nothing there. Copying the name straight out of Drive is the reliable way to get it right. Dropbox treats capitalization as interchangeable, so this only affects Google Drive.

Path patterns are the exception: a path pattern (on a file trigger, a cloud-drive source, or the List folder step) ignores capitalization on every drive, so **/*.pdf also matches REPORT.PDF and /reports/* also matches /Reports/q3.pdf. That is intentional — file extensions arrive in whatever case the camera or scanner wrote them, and a pattern that quietly skipped them would be a poor filter. It is safe because a pattern only narrows what the folder you already chose contains: choosing the folder is what decides where an agent can reach, and that decision is still exact.

Google Docs, Sheets and Slides have no file to download, so Seclai exports them automatically and they arrive with a matching extension:

Google file	Exported as	Appears as
Docs	Plain text	`Q3 Report.txt`
Sheets	CSV	`Budget.csv`
Slides	PDF	`Deck.pdf`
Drawings	PNG	`Diagram.png`

Google limits exports to 10 MB. Forms, Sites and Apps Script files are skipped — they have no file content to work with.

Writing files. Seclai requests read/write access to your Drive, so write steps and tools can update any file the connected Google account can edit — not just files Seclai created. Google shows you exactly what is being granted on its consent screen. A write is still refused when the connected account itself only has view access to a file someone shared with it; the step then reports that the connection lacks permission to modify that file.

Replacing an existing file is the risky part, and it is off by default. A write step or tool replaces a file wholesale — it never edits one in place — so asking an agent to "update" a document means regenerating it and trusting the model to have carried everything over. That can look perfect across several test runs and still drop sections on the first input you did not try, and the output gives no sign it happened. Seclai keeps no copy of what was replaced; recovery is whatever version history the drive itself has. Both the overwrite field and the write_drive_file tool now default to off, so a name clash auto-renames instead of destroying anything. Prefer writing new files into a folder the agent owns — a dated path like /reports/{{datetime UTC}}.md never loses work, and the folder becomes the history. See Overwriting is not editing.

Deletions are not propagated. Adding or changing a file is picked up; deleting one is not. A deleted file stays in a knowledge base until you remove it there, and deleting a file never fires a file-change trigger. This is deliberate for now — Google reports a deletion without saying which folder the file was in, so Seclai cannot tell whether it was inside the folder you asked it to watch.

Renaming a Google Doc may trigger an agent once. Ordinary files are tracked by their content, so renaming or moving one changes nothing. Google Docs, Sheets and Slides expose no content fingerprint, so Seclai falls back to Google's version number — which Google also increments on a rename. The alternative (tracking by timestamp) would risk missing a real edit, so an occasional extra run is the safer trade.

Transcription (audio & video)

Wherever a cloud-drive file is ingested — a Read Cloud Drive File step or a content source — audio and video files are transcribed, and the transcript becomes the file's text. A downstream step (or a knowledge-base search) then works with the spoken content even though no model plays media natively.

Transcription is metered as TRANSCRIPTION credits by the media's audio duration, the same rate as knowledge-base ingestion. In a read step it degrades gracefully if unavailable — the file still attaches, it just carries no transcript.

Privacy: transcription sends the file's audio to Seclai's transcription subprocessor (the same one used for knowledge-base ingestion). Only audio and video are sent; text, images, and documents are handled without it.

Credits and limits

Step execution — listing, reading, and writing files make no model call, so the steps themselves consume no credits. A downstream prompt_call bills normally.
Transcription — audio/video is metered as TRANSCRIPTION credits by audio duration. Text/document extraction and OCR are not billed.
Size — reads and writes are bounded by max_file_mb (default: the 100 MB platform ceiling for steps). Oversized files are refused, not truncated.
Runs per sync — a burst of changes is capped so one bulk upload cannot drain your credit balance. Changes beyond the cap are dropped rather than queued, and recorded as flood in the skipped-files log below.

When a file doesn't trigger anything

A changed file can be skipped without failing anything — no agent run, no error, nothing in the trace list. Each skip is recorded against the connection with a reason, which is the first place to look when a file "didn't do anything":

Reason	What happened
`too_large`	The file exceeded the trigger's `drive_max_file_mb` or the platform ceiling.
`download_failed`	The provider would not serve the bytes (permissions, a restricted or DLP-protected file, an export that exceeded Google's 10 MB limit).
`flood`	The per-sync or hourly per-account run cap was reached, so the rest of that batch was dropped to protect your credits.

Files filtered out by your own path pattern or content types are not recorded here — they were excluded by configuration, not skipped by the system. If nothing appears in this log and the file still did nothing, check those two settings. Capitalization is never the cause: patterns ignore it on every drive (see Capitalization). A watched folder or a toolset path prefix that doesn't match the folder's real capitalization on Google Drive is a much more likely culprit, and it produces no log entry either — the file was never in scope to begin with.

Read the log via GET /api/cloud-drives/{id}/rejections or the list_cloud_drive_rejections MCP tool.

Prompt injection & security

Files and filenames pulled from a drive are untrusted external content, so the List folder and Read file steps are treated as taint sources: their output (including extracted text and transcripts) is prompt-injection scanned before any downstream prompt_call, extract_data, or other consuming step runs. If the content is flagged unsafe, the consuming step is blocked and the scan appears as an Output Scan pseudo-step in the agent trace.

If an agent only reads from a drive, connect it read only (Access level). That makes a poisoned document unable to cause a write no matter what it instructs, since the refusal happens on our side before the drive is contacted — a stronger guarantee than any prompt or folder restriction. When write access is genuinely needed, confine it with the toolset's path_prefix so the model can only change one folder.

Downloads run only against the provider's fixed API host (a file path is never treated as a URL) and are size-capped. See Safety & Oversight for the platform-wide model.