Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.agno.com/llms.txt

Use this file to discover all available pages before exploring further.

Scout reads Drive as its own service account, not as you. You create the service account once, share folders with its email, and Scout can read exactly what you’ve granted it, nothing more. No browser consent. No OAuth tokens. No impersonation. The full setup, including the manual GCP Console path for orgs that block service-account keys, lives in the Scout repo: GDRIVE_CONNECT.md.

​
Prerequisites

  • Scout running locally (setup)
  • The gcloud CLI installed and authenticated (gcloud auth login)
  • A Google account with permission to create GCP projects

​
Step 1: Create the service account

./scripts/google_setup.sh
The script prompts for a project ID with a smart default derived from your gcloud account. Hit Enter to accept or type your own. The script:
  1. Creates the GCP project under your org.
  2. Enables the Google Drive API.
  3. Creates the scout-agent service account.
  4. Downloads a JSON key to <repo>/.scout/service-account.json (gitignored).
  5. Prints the service account email and copies it to your clipboard.
The script is idempotent. Re-running it reuses the project and service account, and writes a fresh key.
If your GCP org enforces constraints/iam.disableServiceAccountKeyCreation, the script tries to apply a project-scoped override automatically. If you don’t have roles/orgpolicy.policyAdmin, ask an admin to run the override command the script prints.

​
Step 2: Share folders with Scout

This is the one step only you can do. The service account has no way to grant itself access. For each folder Scout should see:
  1. Right-click the folder in Drive → Share.
  2. Paste Scout’s service account email (in your clipboard from Step 1).
  3. Role: Viewer.
  4. Uncheck Notify people. The service account has no inbox.
  5. Click Share.
Shared Drives work the same way. Share the Shared Drive root.

​
Step 3: Wire credentials and restart

Add to .env: 
GOOGLE_SERVICE_ACCOUNT_FILE=.scout/service-account.json
The relative path works on the host and inside the container (the repo root mounts at /app). If you stored the key elsewhere, use the absolute path and add a matching volume mount in compose.yaml. Restart: 
docker compose up -d

​
Verify

curl -sS http://localhost:8000/contexts | jq '.[] | select(.id == "gdrive")'
Expected: 
{ "id": "gdrive", "name": "Google Drive", "ok": true, "detail": "gdrive" }
Then ask Scout in chat:
“Search Drive for files with ‘roadmap’ in the name.”
Scout calls query_gdrive and returns matches with their webViewLinks.

​
Why Scout uses its own identity

Borrowing your credentials would collapse the audit trail. Everything Scout did would show up as something you did. With its own identity, actions stay attributable, multiple people can interact with the same agent safely, and access is scoped to exactly what’s been shared with the service account. The same pattern will apply when Gmail and Calendar providers ship. Scout will have its own mailbox and calendar seat.

​
Troubleshooting

SymptomLikely cause
/contexts shows ok: false, “service account file not found”The path in GOOGLE_SERVICE_ACCOUNT_FILE doesn’t resolve inside the container. Move the key under .scout/ or add a matching volume mount.
Queries return permission denied / 403The folder isn’t shared with the service account email.
Queries return no resultsYou shared individual files instead of the parent folder, or the JSON key is invalid. Validate with python -m json.tool .scout/service-account.json.
gcloud projects create fails with “project ID already in use”Project IDs collide globally across GCP. Type a different one at the prompt.
For more, see GDRIVE_CONNECT.md.

​
Next

Connect MCP servers →