IEXDG × Google Cloud
API Reference

The 403 that triggered this doc

On 2026-05-26, an attempt to authenticate dovewebconsulting@gmail.com against the IEXDG OAuth client failed with Google's terse Error 403: org_internal. That single error revealed an architecture decision that had been silently bleeding tokens, capping accounts, and queueing future surprises across every IEXDG automation. This document captures the root cause, the fix, and the broader posture that prevents the next failure of the same class.

What is actually running

A precise inventory of the GCP projects, OAuth clients, tokens, and services in use across the IEXDG stack, as of 2026-05-26. Every entry is verified against disk or live API, not inferred from memory.

GCP projects in scope

OAuth tokens on disk

VM runtime · brain.iexdg.com

The 2-project topology

Two GCP projects. One operator identity bridging them. Five OAuth pickles, three already dead. The picture below is what 18 months of incremental glue actually looks like on disk and in the Cloud Console, and why the 2026-05-26 403 was inevitable the moment the second project went Internal-only.

The Internal / External / Testing / Published lattice

Google's OAuth posture has four states. Each one trades convenience for blast radius. The combination IEXDG sits in matters because every wrong move either (a) blocks operator accounts at the door or (b) issues short-lived tokens that silently rot.

Scope sensitivity tiers (what triggers verification)

Click-path to fix Internal → External

# 1. Sign in as a Workspace admin of iexdg.com (robert.dove@iexdg.com)
# 2. Open in browser:
https://console.cloud.google.com/apis/credentials/consent?project=iexdg-automation

# 3. On the OAuth consent screen (or Google Auth Platform > Audience):
User type:      Internal → "MAKE EXTERNAL"
Publishing:     leave on "Testing"

# 4. Add test users:
+ ADD USERS → dovewebconsulting@gmail.com → SAVE

# 5. SAFETY NOTE
# Internal → External is non-destructive (no tokens revoked).
# External → Internal IS destructive (invalidates external tokens).
# Never reverse this once it's live.

The OAuth lifecycle flywheel

External-Testing OAuth apps issue refresh tokens that expire in 7 days unless they are exercised. A healthy IEXDG token spends its life in a 5-step closed loop. If the loop breaks at step 3, the token drops to the failure branch and forces a fresh user consent. The cron we will build keeps the loop closed.

A healthy token cycles Use → Day 7 decay → Health cron → Refresh → Use indefinitely and never falls off the wheel. A neglected token reaches Day 7 with no refresh, drops to the red Revoked chip, and forces a fresh consent screen. Every IEXDG pickle holding Gmail, Drive, Sheets, or Calendar scopes lives on this wheel until iexdg-automation is pushed to Published (which requires a CASA assessment for the Restricted scopes we hold).

Which account does which job

IEXDG operates across multiple Google identities deliberately. Each has a defined lane. Crossing lanes is the bug that produced the 2026-05-15 sender violation (memory: feedback_iexdg_email_from_dwc_gmail.md) and the 2026-05-26 OAuth project mismatch.

Drive folder share, GCS bucket, or both

For the brand-canon and visual-reference flow (Dr. DNicole drops files, the brain reads them, content_drop_v3 honors them), three architectures are on the table. The 403 we just hit is a strong signal one of them carries a recurring tax.

Comparison across 10 axes

Fortress security proof

Plain English answer to one plain English question: is the brand brain at brain.iexdg.com actually safe? Yes, and the picture below shows why. Five independent layers of defense surround the brain, with security cameras watching every move. An attacker would have to defeat ALL five at once. The picture reads outside in: outer ring is the first wall a stranger meets, inner ring is the last vault.

Q9 keystone win + DWD rollback postmortem

Two GCP events on 2026-05-27. One unlocked the brain bucket and Secret Manager in 30 seconds of downtime. One was created and rolled back inside the same session because the underlying need had already evaporated. The third card locks the rule that prevents the second event from repeating.

The GCP fuckup chronicle

Every Google Cloud and Workspace mistake on the IEXDG account, catalogued in one place. Honest, dated, scoped. The point is not self-flagellation. The point is that future GCP-domain problems land here on contact, every fix gets a postmortem entry, and the next architect inherits an audit trail instead of a guessing game.

Per-incident detail · eleven cards

Permanent lessons · three shields

How the May 27 fixes connect to Google Cloud + Workspace services

A topic-native map of every May 27 fix tied to the exact GCP or Workspace surface it touches. The diagram traces data flow from the VM compute substrate, through the GCP storage and proxy plane, out to the Workspace identity surfaces that the brain consumes. Status pills carry the truth of the day: LIVE where the fix is in place and verified, ROLLED BACK where we caught an obsolete scaffold and reversed it, REVOKED where today surfaced an identity break that needs user action.

The Drive to GCS hybrid data flow

Drive is the friendly front door for Dr. DNicole. GCS is the canonical brain store. M20 is the one-way watcher that copies between them every 15 minutes. Downstream, three brain surfaces read exclusively from GCS, so consent-screen failures stay isolated to the inbox side and never bleed into content generation or visual gating.

Minimum-viable bucket in 5 commands

Run as dovewebconsulting@gmail.com against project drdnicole-youtube-manager. Total elapsed time: under 60 seconds.

# 1. Point gcloud at the IEXDG project
gcloud config set project drdnicole-youtube-manager

# 2. Create the canon bucket (uniform IAM, soft-delete 10d)
gcloud storage buckets create gs://iexdg-brand-canon \
  --location=us-central1 \
  --default-storage-class=STANDARD \
  --uniform-bucket-level-access \
  --soft-delete-duration=10d

# 3. Grant Dr. DNicole direct CRUD on objects (Workspace identity)
gcloud storage buckets add-iam-policy-binding gs://iexdg-brand-canon \
  --member=user:drdnicole@iexdg-team.com \
  --role=roles/storage.objectUser

# 4. Grant the operator (Robert) full bucket admin
gcloud storage buckets add-iam-policy-binding gs://iexdg-brand-canon \
  --member=user:dovewebconsulting@gmail.com \
  --role=roles/storage.admin

# 5. First canonical upload
gcloud storage cp ./brand_canon_v1.md gs://iexdg-brand-canon/brand/brand_canon_v1.md

Optional · signed PUT URL for a no-Google-login upload

from google.cloud import storage
from datetime import timedelta

client = storage.Client(project='drdnicole-youtube-manager')
blob = client.bucket('iexdg-brand-canon').blob(f'inbox/{filename}')
url = blob.generate_signed_url(
    version='v4',
    expiration=timedelta(hours=24),
    method='PUT',
    content_type='application/octet-stream',
)
# Email `url` to Dr. DNicole. She PUTs from her browser. File lands in
# gs://iexdg-brand-canon/inbox/  with no Google consent screen on her side.

Lifecycle · auto-clean the inbox prefix

{
  "lifecycle": {
    "rule": [
      {
        "action": { "type": "Delete" },
        "condition": { "age": 30, "matchesPrefix": ["inbox/"] }
      }
    ]
  }
}

gcloud storage buckets update gs://iexdg-brand-canon \
  --lifecycle-file=./lifecycle.json

Drive to GCS · the five phases

A surgical sequence to move from the current Drive-only posture to the recommended hybrid. Each phase is reversible. Total elapsed wall-clock: about 60 minutes plus one short note to Dr. DNicole.

rclone copy \
  drive:'DNicole Brand Canon' \
  gcs:iexdg-brand-canon/brand/

gcloud storage objects \
  describe gs://iexdg-brand-canon/... \
  --format='value(md5Hash)'

export IEXDG_BRAND_CANON_SOURCE=gcs
# Then restart iexdg-api +
# iexdg-mcp services on VM

One-sentence note for Dr. DNicole (P4)

Open items + the broader hygiene queue

Items surfaced by the inventory that need explicit decisions, scheduling, or one-shot fixes. Each one carries an owner and an estimated time-to-close.