Appropriate vs. Inappropriate Use — Quick Test
The test: does a human with real authority review the decision before it takes effect on a person? Not "is this technical" or "does this sound risky."
| Appropriate (human-in-the-loop) | Inappropriate (fully autonomous) |
|---|---|
| Claude summarizes resumes + flags for a recruiter who decides | Claude auto-rejects applicants below a score threshold, no review |
| Claude flags suspicious transactions for an analyst to approve/deny/escalate | Claude approves/denies loans end-to-end, no analyst review |
| Reviewer has authority + context to overrule Claude, before the decision takes effect | Supervisor spot-checks 5% of notices already sent (after the fact) |
- Three things must hold together: a human with real authority reviews it, review happens *before* the decision takes effect, and the review is substantive — not a rubber stamp.
- Timing is the trap: review *after* the affected person has already been notified is quality assurance, not oversight.
Ethical Implications: Fairness & Transparency
Adding a human reviewer doesn't automatically make a use case ethically sound. Two more things matter:
- Fairness — an AI-assisted process at scale can encode bias a purely human, case-by-case process would have caught. A reviewer who just glances and clicks approve isn't providing real oversight.
- Transparency — if AI involvement is material to how someone would understand or contest a decision about them, concealing it is an ethical problem on its own, independent of whether the decision was accurate.
Console Roles at a Glance
| Role | Grants | Excludes |
|---|---|---|
| Claude Code User | Workbench, org's Claude Code workspace (build/experiment) | API key management, webhook configuration |
| Billing | Payment methods, org-wide usage/cost monitoring | Workbench, Claude Code workspace, API keys, webhooks |
Match the role to the described job need, not the job title — two people with the same title at different companies can need different roles.
Least Privilege & Blast Radius
Least privilege: grant the minimum access a job actually requires, no more. Blast radius: the damage a mistake or compromised account can cause is bounded by what its role permits.
- A compromised Billing-role account can view spend and payment methods — but cannot mint an API key, redirect a webhook, or touch production.
- Role assignment is an ongoing habit, not a one-time setup step: narrow it again when a contractor's engagement ends, someone switches teams, or a pilot wraps up.
- Over-provisioning is wrong even when the broader role 'would technically work.'
Project Sharing: Bulk vs. Scoped
Enterprise admins can bulk-add an entire department to a Project in one action — a real, built-in Team/Enterprise feature, not a workaround like a shared login.
A feature being available isn't the same as it being the policy-compliant choice. Whether to use it depends on the Project's sensitivity and the org's own AI governance policy.
| Project sensitivity | Sharing approach |
|---|---|
| Low sensitivity, wide legitimate need (e.g. help-center drafting) | Bulk department sharing is reasonable |
| Sensitive (draft contracts, unreleased pricing, personnel data) | Restrict to the roles/groups the policy names (e.g. Sales leadership + Legal); no bulk add |
Data Residency: Inference vs. Storage
| Control | Scope | Example requirement |
|---|---|---|
| Inference location | Per-request — where one request's model computation runs | EU customer needs one request's inference on US infra; storage stays unchanged |
| Storage location (data at rest) | Org/workspace-wide, standing config | Blanket rule: all customer data stored within a specific region |
Classification comes first. Determine data sensitivity before applying either control — some data needs exclusion or special handling regardless of residency setting. De-identification reduces risk but doesn't remove the need to classify.
Trap: a scenario that says storage should stay unchanged is pointing you at the inference control, not an org-wide storage setting (and vice versa).
Activity Feed vs. Transparency Hub — Who's It For?
| Capability | Records / publishes | Audience | Retention |
|---|---|---|---|
| Activity Feed | An org's own admin + usage activity | That org's compliance/audit team | 6 years |
| Transparency Hub | Anthropic's own safety-practice & enforcement reports | General public | Periodic public reports |
Multi-year lookback for compliance or incident review → Activity Feed, not a standard usage dashboard (which only covers recent activity) and not the Transparency Hub (which is Anthropic's own public reporting, not your org's internal log).