Detection rules › Panther

Anthropic Role Granted

Severity
informational
Group by
actor.email_address
Log types
Anthropic.Activity
Tags
Anthropic, Access Control
Source
github.com/panther-labs/panther-analysis

Tracks all role grants in the Anthropic organization. Currently used to build visibility into the role taxonomy as the log source matures. Once sufficient data is collected on org-level vs project-level role patterns, this rule can be refined to alert at higher severity for elevated roles.

MITRE ATT&CK coverage

TacticTechniques
Privilege EscalationT1098 Account Manipulation

Rule body yaml

AnalysisType: rule
RuleID: Anthropic.Activity.Role.Granted
DisplayName: "Anthropic Role Granted"
Enabled: true
Filename: anthropic_role_granted.py
LogTypes:
  - Anthropic.Activity
Severity: Info
Description: >
  Tracks all role grants in the Anthropic organization. Currently used to
  build visibility into the role taxonomy as the log source matures. Once
  sufficient data is collected on org-level vs project-level role patterns,
  this rule can be refined to alert at higher severity for elevated roles.
Runbook: |
  1. Find all Anthropic.Activity events by actor:email_address in the 6 hours before and after the alert to determine if this is part of routine project creation or an isolated privilege grant
  2. Check if target_id has been granted other roles in the past 7 days to identify potential privilege accumulation
  3. Check if actor:ip_address is associated with known VPN/proxy services or matches previously seen IP addresses for this actor
Tags:
  - Anthropic
  - Access Control
Reports:
  MITRE ATT&CK:
    - TA0004:T1098  # Account Manipulation
Tests:
  - Name: Role granted
    ExpectedResult: true
    Log:
      {
        "id": "activity_01ABC123",
        "created_at": "2026-05-07T13:02:42Z",
        "organization_id": "org_01XYZ",
        "type": "role_assignment_granted",
        "target_id": "user_01DEF",
        "target_type": "organization_member",
        "role": "chat_project:viewer",
        "resource_type": "chat_project",
        "resource_id": "claude_proj_01ABC",
        "actor": {
          "type": "user_actor",
          "email_address": "admin@example.com",
          "user_id": "user_01ABC",
          "ip_address": "10.0.0.1",
          "user_agent": "Mozilla/5.0"
        }
      }
  - Name: Non-matching event type
    ExpectedResult: false
    Log:
      {
        "id": "activity_01DEF456",
        "created_at": "2026-05-07T13:02:42Z",
        "organization_id": "org_01XYZ",
        "type": "claude_chat_created",
        "actor": {
          "type": "user_actor",
          "email_address": "user@example.com",
          "user_id": "user_01DEF",
          "ip_address": "10.0.0.2"
        }
      }

Detection logic

Condition

type eq "role_assignment_granted"

Indicators

Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.

FieldKindValues
typeeq
  • role_assignment_granted

Output fields

Fields the rule emits when it matches. Chronicle authors list these in the outcome block; they appear on the detection and $risk_score drives alerting. Sentinel / Defender XDR rules build them up through project / summarize / extend stages. Sentinel maps these into alert fields via entityMappings and customDetails; Defender XDR custom detections surface them as alert fields directly.

FieldSource
event_typetype
actor_typeactor.type
actor_emailactor.email_address
actor_user_idactor.user_id
ip_addressactor.ip_address
user_agentactor.user_agent
api_key_idactor.api_key_id
organization_id
ipsp_any_ip_addresses
role
target_id