Automation Accounts

Automation accounts are non-human identities that interact with systems on behalf of the organization. They include mailbox-backed bots, service accounts, CI runners, and integration accounts.

What Counts as an Automation Account

• A Google Workspace user that runs scheduled jobs or integrations
• A GCP service account with Domain-Wide Delegation (DWD)
• A CI/CD runner identity
• A webhook relay or integration bot
• Any non-human identity that touches org data

Naming

Mailbox Accounts

prv-{owner}-auto-{system}-{purpose}@{primary_domain}

Example	Purpose
prv-plt-auto-wks-sync	Workspace directory sync bot
prv-eng-auto-gl-ci-runner	GitLab CI runner account
prv-plt-auto-tf-plan	Terraform plan executor
prv-sec-auto-op-rotation	1Password credential rotation

GCP Service Accounts

prv-{owner}-auto-{system}-{purpose}@{project}.iam.gserviceaccount.com

Display Name

[ PRV ] AUTO – {System} – {Purpose}

The bracket prefix makes automation accounts visually distinct from human accounts in directories and audit logs.

Helper Groups

Two helper groups support automation governance:

Group	Pattern	Purpose
Owner group	prv-{owner}-auto-owners-{system}	Humans who own/manage automation for a system
Global alerts	prv-org-auto-alerts	On-call for all automation failures

OU Placement

Mailbox-backed automation accounts live in:

/automation-accounts/automation-accounts-active      ← active bots
/automation-accounts/automation-accounts-disabled     ← retired bots

Baseline Posture

• Workspace apps: OFF by default. Enable only what’s needed.
• Gmail: OFF unless justified. IMAP/POP off. No auto-forward. DLP on.
• OAuth: Allowlist only. Least-privilege scopes.
• Sessions: 4h max. No self-reset.
• Shared Drives: Access via groups only. Never file owner.
• SSO: SSO-only authentication.

Access Model

Automation accounts never own content. They act on behalf of humans through scoped delegation.

• All drive access via group membership (not individual ACLs).
• DWD scopes documented and attested quarterly.
• No broad * scopes. Enumerate exactly what’s needed.

Secrets & Keys

• API keys, webhooks, and service account keys stored in vault/secret manager (never in Drive or repos).
• Key rotation: at least annually, or on personnel change.
• Webhook URLs treated as secrets. Stored in 1Password or equivalent.

Lifecycle

Create

1. Justify the need (ticket with purpose, scopes, owner).
2. Create the account in /automation-accounts-active.
3. Name per convention. Set display name with [ PRV ] AUTO prefix.
4. Apply baseline posture (apps off, minimal scopes).
5. Add to prv-org-ident-auto-active roster.
6. Add to owner group (prv-{owner}-auto-owners-{system}).
7. Document scopes, keys, and DWD grants.

Operate

• Quarterly: attestation of scopes, keys, and webhooks.
• Monitor: failures route to prv-org-auto-alerts.
• Audit: log all actions to evidence store.

Retire

1. Disable the account. Move to /automation-accounts-disabled.
2. Revoke all keys, tokens, and DWD grants.
3. Remove from all groups.
4. Move to prv-org-ident-auto-disabled roster.
5. Keep record for audit (1 year minimum).

DRI Checklist (Per Bot)

For each automation account, the DRI must maintain:

• Purpose and justification documented
• Scopes enumerated and minimal
• Keys/webhooks stored in vault
• Owner group has 2+ humans
• Quarterly attestation scheduled
• Failure alerts route to on-call
• No file ownership (access via groups only)

Guardrails

• Never give automation accounts owner role on any shared drive.
• Never store credentials in Google Drive or git repos.
• Never grant DWD scopes broader than what’s documented and approved.
• Automation accounts must not be members of human teams.
• All automation account activity must be logged and auditable.