← 15.315.5 →
1965 words Slides

15.4 Identity and Access Management

Course: Claude Code - Enterprise Development Section: 15 - Enterprise Deployment Video Length: 4-5 minutes Presenter: Daniel Treasure

Opening Hook

"We've locked down the network. Now we're locking down identity. Who's running Claude Code? Are they who they say they are? And what exactly are they allowed to do? Today—authentication, authorization, role-based access control, and how every action gets audited."

Key Talking Points

1. Authentication: Proving Identity

What to say: - "Authentication answers: 'Who are you?' Claude Code doesn't just run as 'anyone.' It integrates with your identity provider—Okta, Azure Entra ID, Google Workspace, or LDAP." - "When someone starts a Claude Code session, they prove they're an employee via SSO. Their token gets verified. If they've been fired or their access revoked, the token is invalid—they're locked out immediately." - "No more 'find all the machines where Bob has access.' One identity provider, one source of truth."

What to show on screen: - SSO flow diagram: Claude Code → Identity Provider → Verify Token → Access Granted/Denied - Example: "Bob logs in via Okta. Okta issues a token valid for 8 hours. Claude Code checks the token with every session." - Token example (JWT or SAML): eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJib2JAY29tcGFueS5jb20iLCJyb2xlcyI6WyJiYWNrZW5kLWVuZ2luZWVyIiwiY2ktY2QiXX0.sig Decoded: user, roles, expiration, signature.

2. Authorization: Scoped Access Control

What to say: - "Authentication proves who you are. Authorization says what you can do. It's not enough that you're Bob—are you Bob the backend engineer, or Bob from HR?" - "Claude Code supports role-based access control. You define roles: 'backend-engineer,' 'data-analyst,' 'security-engineer.' Each role has specific permissions." - "Within each role, you can scope further: 'backend-engineer can read prod repo, write to dev tests, but not deploy.' Scoping happens per project, per environment, per tool."

What to show on screen: - RBAC hierarchy diagram: Organization └── Team: Backend ├── Role: Backend Engineer │ └── Permissions: read:repo, write:tests, call:testing-tools └── Role: Backend Lead └── Permissions: read:repo, write:code, call:all-tools, approve:deployments - Example permission matrix table (4x4 grid): - Columns: File Read, File Write, Repo Push, Deploy - Rows: Backend Eng, Data Analyst, DevOps, HR - Grid filled with checkmarks/X marks

3. Access Controls: Tools, Integrations & Limits

What to say: - "Within a role, you control what agents can access. 'Backend engineers get GitHub and testing tools, but not Slack API or financial systems.'" - "Tool allowlists are managed centrally. Your org says: 'Claude Code can call these 12 tools,' and everyone respects that list." - "You also set limits. Rate limits per user (500 requests/hour), token budgets (max 10M tokens/month), tool call quotas."

What to show on screen: - Tool allowlist in managed config: json { "allowedTools": [ "github-api", "git-clone", "run-tests", "compile-code" ], "deniedTools": [ "slack-api", "salesforce", "stripe", "banking-system" ], "toolLimits": { "github-api": { "callsPerHour": 1000, "callsPerDay": 5000 }, "run-tests": { "maxDuration": 3600 } } } - Quota dashboard: token usage per team, per user, alerts when approaching limits

4. Service Identities: Automation & Scoped Credentials

What to say: - "Not everything runs as a human. CI/CD pipelines run as service accounts. These are 'bot' identities with their own credentials and permissions." - "Each service account is scoped narrowly. The CI/CD bot can only call the tools needed for CI/CD. The monitoring bot can only read metrics, not write code." - "Service accounts rotate their credentials regularly—weekly, daily even. Old credentials are revoked automatically."

What to show on screen: - Service account examples: - ci-cd-bot: read:repo, write:tests, call:github-actions - monitoring-bot: read:metrics, read:logs, call:alerting - audit-bot: read:logs, read:audit-trail, generate:reports - Credential rotation example: Time 00:00 - ci-cd-bot gets API key-1 Time 12:00 - ci-cd-bot issued API key-2 (key-1 still works) Time 24:00 - API key-1 revoked, ci-cd-bot uses key-2 only Time 36:00 - ci-cd-bot issued API key-3 (key-2 still works)

5. Auditing: What Happened & When

What to say: - "Every action is logged. Every authentication, every tool call, every permission check. Who did what, when, from where, with what result." - "Audit logs feed into your compliance system. They're immutable—can't be edited or deleted—and they're searchable for incidents." - "If there's a breach, you have a full trail. If there's a bug, you can replay it. If there's an audit, you have proof."

What to show on screen: - Sample audit log entries (table format): Timestamp User Action Resource Result Reason 2026-02-11 10:30 bob@company.com authenticate . PASS Valid Okta token 2026-02-11 10:31 bob@company.com read repo:backend/main PASS Role allows read 2026-02-11 10:32 bob@company.com call github-api:create-pr PASS Tool in allowlist 2026-02-11 10:33 bob@company.com write repo:backend/main FAIL Role allows write:tests only, not write:code - Audit dashboard: trends, anomalies, breach detection

Demo Plan

Setup (30 seconds)

  1. Open terminal
  2. Show current user context: whoami, id, groups
  3. Say: "This is the human identity. Claude Code will verify it with our identity provider."

Step 1: SSO Authentication (60 seconds)

  1. Start a Claude Code session: bash claude session start
  2. Show authentication flow: redirects to Okta/Entra/whatever
  3. Once authenticated, show the token that came back: bash echo $CLAUDE_CODE_AUTH_TOKEN | base64 -d | jq . (Decoded JWT shows user, roles, expiration)
  4. Show session info: bash claude session info Displays: authenticated user, token expiration, roles

Step 2: Check Role & Permissions (60 seconds)

  1. Show current user's role: bash claude role show # Output: backend-engineer in team:infrastructure
  2. Show available permissions: bash claude permissions list # Output: read:repo, write:tests, call:testing-tools, call:github
  3. Try a permitted action (should succeed): bash claude repo read main/README.md # Success
  4. Try a denied action (should fail): bash claude repo write main/README.md --content "hack" # Error: permission denied (role allows write:tests only, not write:code)

Step 3: Service Account Setup (60 seconds)

  1. Show org's service accounts: bash claude service-accounts list # ci-cd-bot, monitoring-bot, audit-bot
  2. Show details of one: bash claude service-accounts show ci-cd-bot # Roles: ci-cd-executor # Permissions: read:repo, write:tests, call:github-actions # Credential rotation: every 24 hours
  3. Simulate credential rotation: bash claude service-accounts rotate ci-cd-bot # New API key issued, old key revoked in 24 hours

Step 4: Audit Trail (60 seconds)

  1. Show audit logs: bash claude audit logs --filter user=bob@company.com --days=1
  2. Display a few entries (authenticate, read, write attempt, etc.)
  3. Filter for denied actions: bash claude audit logs --filter result=FAIL --days=1 # Shows all permission denials in last 24 hours
  4. Show a detailed entry: bash claude audit logs show AUDIT_ID_12345 # Full details: timestamp, user, action, resource, exact error

Step 5: Policy Review (30 seconds)

  1. Show the IAM policy file: bash cat /etc/claude-code/iam-policy.json | head -50
  2. Highlight role definitions and permissions
  3. Say: "This file is version-controlled and reviewed like code. Changes go through PR approval."

Wrap-up (30 seconds)

  • Recap: "SSO proves identity, roles define access, service accounts enable automation, audit logs prove compliance."
  • Preview: "Next video—monitoring and analytics. How to see what your Claude Code agents are actually doing."

Code Examples & Commands

Verify authentication

# Check current session
claude session info

# Get decoded JWT token
echo $CLAUDE_CODE_AUTH_TOKEN | base64 -d | jq .

# Re-authenticate
claude session restart

List and verify roles

# Show current user's role
claude role show

# Show all available roles (for org admin)
claude roles list

# Show specific role's permissions
claude role show backend-engineer

Check permissions before running action

# Dry-run with permission check
claude repo read --check-permission main/secrets.json

# List all permissions for current user
claude permissions list --detailed

# Show what a specific action requires
claude action explain "repo write main/src/api.js"

Manage service accounts (admin only)

# Create a service account
claude service-accounts create ci-cd-bot \
  --role ci-cd-executor \
  --expires-in 30d

# Rotate credentials
claude service-accounts rotate ci-cd-bot

# List all service accounts
claude service-accounts list

# Show service account details
claude service-accounts show ci-cd-bot

# Set rate limits
claude service-accounts set-limit ci-cd-bot \
  --requests-per-hour 500 \
  --tokens-per-month 10000000

# Revoke a service account
claude service-accounts revoke ci-cd-bot

Audit log queries

# Show all actions by a user
claude audit logs --user bob@company.com

# Show all denied actions
claude audit logs --result FAIL

# Show specific action type
claude audit logs --action call --resource github-api

# Export audit logs for compliance
claude audit logs export --start-date 2026-01-01 --format csv

# Real-time audit stream
claude audit logs stream --follow

# Show detailed entry
claude audit logs show ENTRY_ID_12345

# Search for breach indicators
claude audit logs search "unusual pattern:true"

IAM policy configuration (admin)

{
  "roles": {
    "backend-engineer": {
      "description": "Backend engineer role",
      "permissions": [
        "repo:read",
        "repo:write:tests",
        "tool:call:github",
        "tool:call:testing-tools",
        "ci:read"
      ]
    },
    "devops-engineer": {
      "description": "DevOps and deployment role",
      "permissions": [
        "repo:read",
        "repo:write",
        "deployment:read",
        "deployment:write",
        "secrets:read",
        "tool:call:all"
      ]
    }
  },
  "scopes": {
    "production": {
      "backend-engineer": {
        "permissions": [
          "repo:read",
          "ci:read"
        ]
      },
      "devops-engineer": {
        "permissions": [
          "repo:read",
          "deployment:read",
          "deployment:write",
          "tool:call:all"
        ]
      }
    }
  },
  "serviceAccounts": {
    "ci-cd-bot": {
      "role": "ci-cd-executor",
      "credentialRotationDays": 1,
      "rateLimit": { "requestsPerHour": 500 }
    }
  }
}

Gotchas & Tips

Gotcha: "Token expiration stops everything" - If a session token expires, Claude Code can't authenticate. The agent just stops. - Monitor token expiration, refresh before they expire.

Tip: "Scope service accounts as narrowly as possible" - If the CI/CD bot only needs to run tests, don't give it repo write access. - Minimize blast radius of a compromised credential.

Gotcha: "Audit logs don't capture everything" - Logs capture Claude Code actions, not what Claude Code does inside tools. - If Claude Code calls GitHub, the log says "called github-api," not "exactly what file changed." - That level of detail lives in the tool's own logs.

Tip: "Review IAM policies quarterly" - As teams change, as projects end, permissions accumulate. - Periodic access reviews (certifications) prevent permission drift.

Gotcha: "Role inheritance is not automatic" - A team lead doesn't automatically get all engineers' permissions. - Explicitly define lead roles with their own permissions.

Tip: "Use service account tokens for CI/CD, never personal tokens" - Personal tokens get revoked when someone leaves. - Service account tokens are managed independently and can't accidentally leak with a person's identity.

Lead-out

"Your agents are now authenticated, authorized, and audited. Every action logged, every permission verified, every credential rotated. Next video—seeing what they're actually doing. Monitoring, metrics, and dashboards for enterprise Claude Code."

Reference URLs

  • SSO & Authentication Guide: https://docs.anthropic.com/claude-code/sso-setup
  • RBAC Configuration: https://docs.anthropic.com/claude-code/rbac-guide
  • Service Accounts & Credentials: https://docs.anthropic.com/claude-code/service-accounts
  • Audit Logging & Compliance: https://docs.anthropic.com/claude-code/audit-guide
  • IAM Policy Best Practices: https://docs.anthropic.com/claude-code/iam-policies

Prep Reading

  • Your org: identity provider (Okta, Entra ID, etc.), current roles & permissions
  • NIST: Role-based access control (RBAC) standards
  • SOC 2: access control requirements
  • Your security team: credential rotation policies, audit log retention

Notes for Daniel

  • IAM can be dry. Keep it practical: "If Bob leaves, he's locked out immediately. If CI/CD breaks, we have a full audit trail."
  • Use real role names from your org. "Backend engineer" is more relatable than "role_003."
  • When explaining scopes, use a concrete example: "In production, even leads can't deploy without a second approval. In dev, they can."
  • The service account section is important for CI/CD automation. Spend time there—lots of teams mess this up.
  • Audit logs are compliance gold. Show real examples. "Here's an engineer trying to access the HR system—caught and logged."
  • Don't over-explain JWT. Just decode it and show the contents. Most people don't need the deep cryptography.
  • The demo should show both success and failure. Showing a permission denial (fail case) makes it clear the system is working.