The bottleneck after the thinking is done
Agencies run client operations through Google Workspace, Shared Drives, and project folders. Agents got good at the thinking part fast: strategy, captions, reports, creative instructions. Then the workflow hits the file system and stops. A human uploads the video, renames the thumbnails, moves the report into the client's folder, exports the deck. The agent wrote the caption; it couldn't move the file.
The blocker was never the model — it was access. Handing an agent a Drive OAuth token has the same problems as handing it any raw credential (the pillar guide covers why), plus a sharper one: files are the most client-identifiable material an agency touches, and a wrong-client mistake in a shared folder is immediately visible to the client.
What agents can do with approved Drive access
Under the authorized OAuth scope, the Drive API covers the full file lifecycle, and Outloop's
Google Drive + Shared Drives guide
documents it end to end — including a verified real write (copying a file into a team Shared Drive,
HTTP 200, secret_exposed: false):
Upload & update
Create files, upload content, and update existing files and metadata under the authorized scope.
Copy & move
Copy files — including into a Shared Drive, as verified — and move them between approved folders.
Rename & organize
Update names and metadata, and keep client folders organized inside the pinned boundary.
Download & export
Download file content and export Google Docs, Sheets, and Slides to standard formats.
Media assets — images, videos, thumbnails, captions, reports, client files — follow the same pattern when they sit inside approved Drive/Shared Drive boundaries or approved local media roots. The local-root media capability is proven in product testing; Drive and Shared Drive file work is documented and verified in the connector guide.
Scoped to the right client, by construction
- →Resource pins — each workspace can be pinned to one Shared Drive and, optionally, a folder inside it. Listing and new files stay inside the pin.
- →Access mode & capability flags — what kind of file work a workspace may do is an explicit grant, not a side effect of holding a token.
- →Connected identity & OAuth scopes — Google enforces Shared Drive membership on the connected account; Outloop requires a pin before broad scopes are usable.
- →Host allowlists, redaction & audit — every file action goes to the approved host, returns redacted, and is written to the local audit.
A file-action audit line carries the proof:
access_mode ·
capability ·
connected_identity ·
secret_exposed:false.
And the sharp edges stay off by default: public-link sharing, ownership transfer, and hard deletes are blocked by runtime policy regardless of scope. Sharing to specific people and groups works. If a client's agent tries to reach another client's drive, the request is denied before any call — the wrong-client mistake is blocked, not cleaned up after.
What happens when the agent requests a file action
- 01
Agent request
The agent asks for an approved action or alias — not a raw key.
- 02
Policy & tenant check
Outloop checks project, tenant identity, and runtime policy before anything runs.
- 03
Local broker
On approval, the local broker uses the credential on the wire to perform the call.
- 04
Redacted result
The agent receives a sanitized, non-secret result. Raw values never enter its context.
- 05
Audit log
Every attempt is written to a redacted local audit — decision, tenant, service.
The agent never sees the credential. A wrong-tenant request is denied at the policy check, before any backend call.
What Outloop is not
Outloop is not a file manager, a digital asset management tool, or a publishing platform — and it does not claim to work with every file system or to fully automate every publishing workflow. It is the runtime access layer underneath that work: the agent does the file work through approved access, and Outloop decides which client workspace may use it, keeps the credential hidden, and writes the audit.
