orcasecurity

"O que é este alerta e devo me importar?"

Triagem inteligente de alertas que transforma alertas brutos do Orca em resumos amigáveis para analistas, com linhas do tempo comportamentais, avaliação de risco e divulgação progressiva. Suporta anomalias, vulnerabilidades, malware e configurações incorretas.

Recursos:

• Resumos com veredito em primeiro lugar e pontuação de confiança (Provavelmente Benigno, Ameaça Ativa, Risco Corrigível, etc.)
• Análise visual de linha do tempo mostrando o comportamento do alerta, mudanças de status e bloqueadores de remediação
• Cálculo de raio de impacto com correlação de ativos e alertas relacionados
• Investigação automatizada com prioridade no Orca — consulta CloudTrail, alertas relacionados e caminhos de ataque antes de sugerir etapas manuais
• Seletor de formato de remediação — escolha Terraform, CloudFormation, ARM/Bicep, Pulumi, CLI ou instruções passo a passo
• Saída de código gravada em arquivos automaticamente (ex.: remediate-orca-3456789.tf)

Uso:

# Triage an alert
/orca-alert-triage orca-1234567

# Or use natural language
triage alert orca-9012345
explain orca-2345678

Comandos de acompanhamento (digite após a triagem):

investigate    # Automated Orca-first investigation with manual steps only for gaps
evidence       # Detailed metadata, hashes, links, MITRE ATT&CK mappings
remediate      # Choose output format, then get remediation written to a file
correlate      # Related alerts and attack pattern analysis

Exemplo de saída:

═══════════════════════════════════════════════════════════════════
ANOMALY DETECTION: Unusual User Agent on EKS Node Role
═══════════════════════════════════════════════════════════════════

VERDICT: Likely Benign | CONFIDENCE: 90% | ACTION: Review & Close | TIMELINE: 48h

WHAT HAPPENED:
  EKS node role used a new AWS SDK version (boto3/1.35.x → 1.36.x)
  during routine cluster operations. Single occurrence, no recurrence.

WHY IT MATTERS:
  Risk Level: Low (Orca Score: 3.0)
  Same tool family, minor version bump, clean 30-day baseline.
═══════════════════════════════════════════════════════════════════

Documentação completa →

"Se eu corrigir isso, o que é resolvido — e o que quebra?"

Analisa o impacto completo da remediação ao corrigir um único alerta do Orca — tanto os ganhos de segurança (alertas fechados, caminhos de ataque quebrados, conformidade aprovada) QUANTO o risco operacional (fluxos de trabalho de produção, automações, serviços que podem quebrar).

Recursos:

• Análise de cascata — mapeia todos os alertas que compartilham a mesma causa raiz do alerta alvo
• Impacto no caminho de ataque — identifica cadeias de ataque que são quebradas quando o alerta é corrigido
• Mudança na pontuação de conformidade — mostra porcentagens de conformidade antes/depois por framework
• Visão de todo o ambiente — encontra o mesmo problema em outros ativos e contas
• Simulação de quebra — analisa eventos CloudTrail/CDR e permissões efetivas para identificar dependências de produção
• Veredito executivo — recomendação clara de CORRIGIR AGORA / CORRIGIR COM CUIDADO / PLANEJAR CORREÇÃO / ADIAR, equilibrando ganho de segurança vs. risco operacional
• Checklist de implantação segura — etapas para aplicar a correção sem quebrar a produção

Uso:

# Analyze impact of fixing an alert
/orca-impact-analysis orca-3456789

# Or use natural language
what's the impact of fixing orca-5678901?
if I fix orca-0123456, what else closes?

Exemplo de saída:

═══════════════════════════════════════════════════════════════════
IMPACT ANALYSIS — orca-3456789
Root Account Without MFA Enabled
"If I enable MFA on root, what closes — and what breaks?"
═══════════════════════════════════════════════════════════════════

┌─────────────────────────────────────────────────────────────────┐
│  VERDICT: FIX NOW                                               │
│                                                                 │
│  Security gain:   HIGH — 2 critical alerts, 3 attack paths      │
│  Breakage risk:   LOW — no automation uses root console login   │
│  Blast radius:    2 alerts, 3 attack paths, 8 frameworks        │
└─────────────────────────────────────────────────────────────────┘

REMEDIATION IMPACT SUMMARY:
  Alerts directly closed:    2 (including this one)
  Attack paths broken:       3
  Compliance frameworks:     8 frameworks improved

  COMPLIANCE SCORE CHANGE:
    Framework              Current    After Fix    Change
    ─────────────────────────────────────────────────────
    PCI DSS v4.0.1          87%   →    89%         +2%
    NIST 800-53             91%   →    93%         +2%

BREAKAGE RISK:
  [ok] EKS automation — uses access keys (MFA doesn't apply)
  [ok] Orca scanner — uses service role (not affected)
  [x]  Unknown Kali agent — SHOULD break (that's the goal)

BOTTOM LINE: High-leverage, low-risk fix. Apply immediately.
═══════════════════════════════════════════════════════════════════

Documentação completa →

"Quem fez isso, como foi implantado e o que introduziu o problema?"

Rastreia qualquer alerta do Orca — configuração incorreta, vulnerabilidade, dado sensível ou anomalia — de volta pelos logs de auditoria da nuvem, Orca CodeOrigins (Shift Left) e metadados de ativos para encontrar quem criou o recurso, qual ferramenta o implantou, o que introduziu o problema específico e uma linha do tempo completa desde a implantação até a detecção do alerta.

Recursos:

• Classificação por categoria de alerta — rastreia a origem de forma diferente para configurações incorretas (a configuração É a causa), vulnerabilidades (o pacote é a causa), dados sensíveis (imagem/script colocou o segredo) e anomalias (o ator É o achado)
• Integração CodeOrigins / Shift Left — extrai o código-fonte IaC exato (repositório, arquivo, números de linha, autor/commit do git blame)
• Rastreamento de logs de auditoria via Orca CDR (CloudTrail, Azure Activity Log, GCP Audit Log)
• Linha do tempo visual completa desde o commit do código IaC → criação do recurso → introdução do problema → detecção do alerta, com cálculo da janela de exposição
• Divisão de propriedade — distingue o proprietário do recurso (quem implantou) do proprietário do problema (quem deve corrigir)
• Detecção de drift de IaC — sinaliza recursos criados por IaC, mas modificados posteriormente via Console
• Roteamento de remediação ciente da categoria — informa ONDE aplicar a correção com base no tipo de alerta E no método de implantação

Uso:

# Trace origin of any alert
/orca-config-origin orca-3456789

# Or use natural language
who created this misconfiguration? orca-3456789
trace back orca-5678901
where did this config come from? orca-3364845

Exemplo de saída (alerta de vulnerabilidade):

═══════════════════════════════════════════════════════════════════
CONFIG ORIGIN — orca-4567890
Apache Log4j Remote Code Execution Vulnerability (CVE-2021-45046)
═══════════════════════════════════════════════════════════════════

ASSET: web-bastion-host (AwsEc2Instance) in 123456789012
ISSUE: log4j-core v2.3 installed — critically vulnerable to RCE

┌─────────────────────────────────────────────────────────────────┐
│  DEPLOYED BY: Terraform (module "ec2_unpatched")                │
│  OWNER:       Alex Chen (alex@example-corp.com)                       │
│  ROOT CAUSE:  user_data script installs log4j-core-2.3.jar     │
│  LAST CHANGE: 2025-12-01 (137 days ago)                         │
│  METHOD:      Terraform → module "ec2/unpatched_ubuntu"         │
└─────────────────────────────────────────────────────────────────┘

TIMELINE:
  2024-06-23  ● Terraform code committed                  Alex Chen
              │ file: ec2.tf:71-80, commit: abc1234
  2025-12-01  ● Instance created — user_data installs log4j 2.3
              │ ⚠ VULNERABILITY INTRODUCED HERE
  2025-12-01  ● Alert detected by Orca (73 min after creation)
  2026-04-17  ● Today — 137 days exposed, still open

REMEDIATION ROUTING:
  ⚠ The fix is NOT in ec2.tf — the Terraform deploys correctly.
  FIX IN: module.scripts.ec2_unpatched (the user_data script)
  → Update script to install log4j-core ≥ 2.16.0
═══════════════════════════════════════════════════════════════════

Documentação completa →

"O que aconteceu enquanto eu estava fora e o que precisa da minha atenção?"

Briefing diário de segurança das últimas 24-72 horas. Examina seu ambiente em busca de novos alertas críticos, achados escalados, mudanças em caminhos de ataque, drift de conformidade, mudanças de exposição, anomalias de atividade CDR, riscos em ativos valiosos e alertas críticos antigos sem ação — e apresenta tudo como um painel escaneável com seções detalháveis.

Recursos:

• Pulso do ambiente — avaliação rápida de saúde (estável, degradando, precisa de atenção)
• Novos alertas críticos/altos com classificação por prioridade
• Alertas escalados — aumentos de severidade e achados reabertos
• Drift de conformidade — pontuações de framework que caíram, com detalhamento por conta
• Visão geral da atividade CDR — volumes de eventos, atores incomuns, padrões suspeitos
• Risco em ativos valiosos — novos alertas nos seus ativos mais críticos
• Críticos antigos — alertas sem ação com status do ticket Jira
• Divulgação progressiva — painel primeiro (~20 linhas), detalhamento por palavra-chave
• Suporte a intervalo de tempo — 24h (diário), 72h (segunda de manhã), semana (retorno de férias)

Uso:

# Daily briefing (last 24 hours)
/orca-morning-briefing

# Monday morning (last 72 hours)
/orca-morning-briefing 72h

# Weekly review
/orca-morning-briefing week

Palavras-chave de detalhamento (digite após o briefing):

alerts         # Full list of new critical/high alerts
escalated      # Alerts that changed severity or reopened
attack paths   # New/worsened attack paths with stories
compliance     # Framework scores, trends, worst accounts
exposure       # Internet-facing assets with critical alerts
crown jewels   # New alerts on crown jewel assets
aging          # Unactioned critical alerts sorted by age
activity       # CDR event volumes, unusual actors
new types      # Alert types seen for the first time
trends         # Week-over-week comparison, top affected assets
full           # All sections expanded (for reports/handoffs)

Exemplo de saída:

═══════════════════════════════════════════════════════════════════
MORNING BRIEFING — 2026-04-17
Last 24 hours | Account: 123456789012
═══════════════════════════════════════════════════════════════════

PULSE: ⚠ NEEDS ATTENTION — 3 new critical alerts

┌─────────────────────────────────────────────────────────────────┐
│  NEW ALERTS         12 total (3 critical, 4 high, 5 medium)    │
│  ESCALATED          2 alerts changed severity or reopened       │
│  ATTACK PATHS       1 new, 2 worsened                           │
│  COMPLIANCE         PCI DSS dropped 2%                          │
│  EXPOSURE           1 asset newly internet-facing               │
│  CROWN JEWELS       1 new alert on critical asset               │
│  AGING CRITICALS    4 critical alerts open > 7 days             │
│  CDR ACTIVITY       Elevated — 3.2k events (normal: ~1k)       │
└─────────────────────────────────────────────────────────────────┘

TOP PRIORITIES:
  [1] orca-4567890 — Log4j RCE on public bastion (137d open!)
  [2] orca-6789012 — S3 bucket publicly accessible (new today)
  [3] orca-7890123 — SendGrid API key exposed in container
═══════════════════════════════════════════════════════════════════

Documentação completa →

"Me conte tudo sobre este ativo em um só lugar."

Perfil completo de segurança 360° de qualquer ativo de nuvem — todos os alertas abertos (agrupados por categoria), caminhos de ataque, violações de conformidade, permissões, exposição de rede, dados sensíveis, resumo de atividade CDR, status de ativo valioso e entidades vinculadas.

Recursos:

• Identidade completa do ativo — nome, tipo, conta, região, IPs, SO, tags, data de criação, fonte IaC
• Resumo de risco com Orca Score, status de ativo valioso e classificação de exposição
• Alertas agrupados por categoria — vulnerabilidades, configurações incorretas, malware, dados sensíveis, anomalias, IAM
• Mapeamento de caminhos de ataque — cadeias de ataque com o papel do ativo (ponto de entrada, pivô, alvo)
• Violações de framework de conformidade por ativo
• Análise de permissões efetivas (ativos AWS IAM) com detalhamento de usadas vs. não usadas
• Resumo de atividade CDR — volumes de eventos de 30 dias, principais ações, atores únicos
• Entidades vinculadas — roles, instâncias, buckets, bancos de dados, balanceadores de carga conectados
• Remediação proativa — sugere a correção de maior impacto e oferece gerar código em Terraform, CloudFormation, Ansible, CLI, Pulumi ou ARM/Bicep

Uso:

# Profile an asset by name, ID, or ARN
/orca-asset-profile web-bastion-host
/orca-asset-profile i-1234567890abcdef0

# Or use natural language
tell me about web-bastion-host
asset risk for vm-chain3-1

Palavras-chave de detalhamento (digite após o perfil):

alerts         # All alerts by category
attack paths   # Kill chains with this asset
compliance     # Framework violations
permissions    # IAM analysis (used vs unused)
exposure       # Network exposure details
activity       # CDR events (last 30 days)
linked         # Connected assets
code origin    # IaC source mapping
full           # All sections expanded

Exemplo de saída:

═══════════════════════════════════════════════════════════════════
ASSET PROFILE — web-bastion-host
AwsEc2Instance | 123456789012 | us-east-1 | running
═══════════════════════════════════════════════════════════════════

RISK: Orca Score 9.0 (Critical) | Crown Jewel: NO

┌─────────────────────────────────────────────────────────────────┐
│  ALERTS        12 total (3 critical, 4 high, 5 medium)         │
│  ATTACK PATHS  4 active kill chains                             │
│  COMPLIANCE    6 frameworks, 18 failing controls                │
│  EXPOSURE      public_facing | ports: 22, 443                   │
│  SENSITIVE     API keys, credentials                            │
│  PERMISSIONS   overprivileged (via instance profile)            │
│  CDR ACTIVITY  847 events in 30d (elevated)                     │
│  LINKED        9 connected assets                               │
└─────────────────────────────────────────────────────────────────┘

TOP ALERTS:
  [1] orca-4567890 — Log4j RCE (score: 9.0, vulnerability)
  [2] orca-7890123 — SendGrid API key exposed (score: 8.5, sensitive data)
  [3] orca-3456789 — Root account without MFA (score: 8.0, misconfiguration)

RECOMMENDED ACTION:
  The highest-impact fix is orca-4567890 (Log4j RCE on a public
  asset). I can generate remediation code right now.

  What format? terraform | cloudformation | cli | instructions
═══════════════════════════════════════════════════════════════════

Documentação completa →

"Onde estamos falhando e qual é o caminho mais rápido para melhorar?"

Análise profunda de lacunas de conformidade para qualquer framework — controles reprovados classificados por raio de impacto, vitórias rápidas (controles de correção única), detalhamento por conta, tendências de pontuação e um plano de remediação em fases com melhorias projetadas de pontuação. Recursos:

• Visão geral do framework com pontuações, tendências e identificação de pior/melhor
• Controles com falha classificados por impacto entre frameworks e quantidade de ativos
• Detecção de vitórias rápidas — correções de configuração única que melhoram vários frameworks ao mesmo tempo
• Detalhamento por conta/unidade de negócio — quem é dono das piores lacunas
• Análise de tendência de conformidade em 30 dias — melhorando, estável ou degradando
• Plano de remediação em fases — vitórias rápidas (dias), correções sistemáticas (semanas), mudanças arquiteturais (meses)
• Melhorias projetadas de pontuação por fase
• Remediação proativa — oferece gerar código de correção para qualquer controle em Terraform, CloudFormation, Ansible, CLI, Pulumi ou ARM/Bicep

Uso:

# All frameworks overview
/orca-compliance-gap

# Specific framework deep-dive
/orca-compliance-gap PCI DSS
/orca-compliance-gap CIS AWS

# Or use natural language
how's our PCI compliance?
what's failing in SOC 2?
quick wins for compliance

Palavras-chave para aprofundamento (digite após a análise):

controls         # All failing controls ranked by impact
quick wins       # Fastest path to score improvement
accounts         # Gap breakdown by account
trends           # 30-day score history
remediation plan # Phased fix plan with projections
full             # All sections expanded

Exemplo de saída:

═══════════════════════════════════════════════════════════════════
COMPLIANCE GAP ANALYSIS — All Frameworks
2026-04-17 | All accounts
═══════════════════════════════════════════════════════════════════

POSTURE: Moderate — 3 frameworks below 85% target

┌─────────────────────────────────────────────────────────────────┐
│  FRAMEWORKS     8 enabled                                       │
│  AVG SCORE      84%                                             │
│  WORST          HIPAA at 71%                                    │
│  BEST           CIS AWS at 94%                                  │
│  TREND (30d)    degrading — PCI dropped 2%                      │
│  QUICK WINS     6 controls fixable with single changes          │
│  WORST ACCOUNT  123456789012 — 76% avg score                   │
└─────────────────────────────────────────────────────────────────┘

TOP FAILING CONTROLS (highest impact):
  [1] Enable MFA for root — failing on 3 accounts, affects 5 frameworks
  [2] Encrypt EBS volumes — failing on 12 assets, affects 4 frameworks
  [3] Restrict SSH access — failing on 8 assets, affects 4 frameworks

RECOMMENDED ACTION:
  The fastest score improvement: enable MFA for root —
  affects 3 accounts across 5 frameworks. I can generate the fix.

  What format? terraform | cloudformation | cli | instructions
═══════════════════════════════════════════════════════════════════

Documentação completa →

"Onde estão nossos dados sensíveis, eles estão protegidos e o que está em risco?"

Visão DSPM (Data Security Posture Management): descobre dados sensíveis em todo o ambiente — segredos, PII, credenciais, chaves de API, dados financeiros — identifica armazenamentos de dados desprotegidos ou expostos, classifica riscos de dados por nível de exposição e gera um plano de remediação.

Recursos:

• Varredura DSPM completa — segredos, PII, credenciais, chaves de API, certificados, dados financeiros
• Classificação de risco — crítico (público + sensível), alto (interno + vulnerável), médio, baixo
• Agrupamento por tipo de dado — segredos e credenciais, PII, dados financeiros, dados de saúde, chaves privadas
• Detecção de armazenamentos de dados públicos — buckets S3, bancos de dados, compartilhamentos de arquivos com acesso público
• Identificação de armazenamentos de dados não criptografados com recomendações de criptografia
• Contexto de conformidade — status dos controles de proteção de dados PCI DSS, HIPAA, GDPR, SOC 2
• Detalhamento da distribuição de risco de dados por conta
• Plano de remediação em fases — estancar o sangramento, criptografar tudo, controles de acesso, governança
• Remediação proativa — gera scripts de rotação, políticas de bucket, configurações de criptografia em Terraform, CloudFormation, Ansible, CLI, Pulumi ou ARM/Bicep

Uso:

# Full DSPM report
/orca-data-exposure

# Filter by type or account
/orca-data-exposure secrets
/orca-data-exposure account 123456789012

# Or use natural language
where's our sensitive data?
find exposed API keys
what PII is at risk?

Palavras-chave para aprofundamento (digite após o relatório):

secrets          # Exposed secrets & credentials
pii              # PII exposure details
public data      # Publicly accessible data stores
unencrypted      # Data stores without encryption
compliance       # Data protection compliance status
accounts         # Data risk by account
remediation plan # Phased data protection plan
full             # All sections expanded

Exemplo de saída:

═══════════════════════════════════════════════════════════════════
DATA EXPOSURE REPORT — All Accounts
2026-04-17 | Full environment
═══════════════════════════════════════════════════════════════════

DATA POSTURE: At Risk — 3 critical data exposures on public assets

┌─────────────────────────────────────────────────────────────────┐
│  TOTAL FINDINGS    24 data exposure alerts                      │
│  CRITICAL          3 — immediate breach risk                    │
│  HIGH              8 — significant exposure                     │
│  SECRETS           11 exposed credentials/API keys/tokens       │
│  PII               5 assets with personally identifiable data   │
│  PUBLIC DATA       2 publicly accessible data stores            │
│  UNENCRYPTED       6 data stores without encryption             │
│  CROWN JEWELS      2 data findings on critical assets           │
│  COMPLIANCE        PCI DSS, HIPAA gaps on data controls         │
└─────────────────────────────────────────────────────────────────┘

TOP DATA RISKS:
  [1] orca-7890123 — SendGrid API key in container image (score: 8.5)
      web-bastion-host | credential | public-facing
  [2] orca-8901234 — AWS access key in environment variable (score: 8.0)
      ci-build-server | infrastructure secret | internal
  [3] orca-6789012 — S3 bucket publicly accessible (score: 7.5)
      s3-data-lake-prod | PII + financial data | public

RECOMMENDED ACTION:
  Priority #1: Rotate the SendGrid API key on web-bastion-host and
  move to Secrets Manager. I can generate the rotation script.

  What format? terraform | cloudformation | cli | instructions
═══════════════════════════════════════════════════════════════════

Documentação completa →

"O que um atacante consegue ver de fora?"

Mapeamento da superfície de ataque externa: descobre todos os ativos voltados para a internet, classifica-os por explorabilidade na perspectiva de um atacante, agrupa por vetor de ataque (serviços expostos, armazenamento público, aplicações web vulneráveis, portas de gerenciamento abertas) e mapeia cadeias de ataque de fora para dentro até os ativos mais valiosos.

Recursos:

• Inventário completo da superfície de ataque externa — ativos voltados para a internet classificados por risco
• Classificação na perspectiva do atacante — "como um atacante priorizaria esses alvos?"
• Agrupamento por vetor de ataque — vitórias fáceis, aplicações web, portas de gerenciamento, dados públicos, pontos de entrada para movimento lateral
• Mapeamento de caminho de ataque de fora para dentro — do ativo exposto através de pivôs até os ativos mais valiosos
• Interfaces de gerenciamento expostas (SSH, RDP, painéis administrativos) com status de autenticação
• Detecção de armazenamentos de dados públicos (S3, bancos de dados, compartilhamentos de arquivos)
• Detalhamento de exposição por conta
• Remediação proativa — gera regras de security group, políticas de bucket, configurações de WAF em Terraform, CloudFormation, Ansible, CLI, Pulumi ou ARM/Bicep

Uso:

# Full attack surface map
/orca-exposure-map

# Filter by account or vector
/orca-exposure-map account 123456789012
/orca-exposure-map web services

# Or use natural language
what's exposed to the internet?
show me our attack surface
what can an attacker see?

Palavras-chave para aprofundamento (digite após o mapa):

easy wins      # Immediately exploitable — fix first
web apps       # Exposed web applications
management     # SSH, RDP, admin panels
data           # Public data stores
attack paths   # Outside-in kill chains
accounts       # Exposure by account
all assets     # Complete exposed asset list
full           # All sections expanded

Exemplo de saída:

═══════════════════════════════════════════════════════════════════
EXPOSURE MAP — External Attack Surface
2026-04-17 | All accounts
═══════════════════════════════════════════════════════════════════

SURFACE: Moderate — 4 immediately exploitable targets

┌─────────────────────────────────────────────────────────────────┐
│  EXPOSED ASSETS     18 internet-facing                          │
│  CRITICAL RISK      4 immediately exploitable                   │
│  HIGH RISK          7 exploitable with effort                   │
│  PUBLIC STORAGE     2 buckets/blobs publicly accessible         │
│  EXPOSED MGMT       3 SSH/RDP/admin panels                      │
│  EXPOSED DATABASES  1 database reachable from internet          │
│  CROWN JEWELS       2 exposed critical assets                   │
│  ATTACK PATHS       5 outside-in kill chains                    │
└─────────────────────────────────────────────────────────────────┘

TOP TARGETS (attacker's priority list):
  [1] web-bastion-host — Log4j RCE + public SSH (score: 9.0)
      AwsEc2Instance | 54.210.xx.xx | ports: 22, 443, 8080
  [2] s3-data-lake-prod — public S3 with PII (score: 7.5)
      AwsS3Bucket | public-read | contains financial data
  [3] ci-build-server — exposed admin panel (score: 7.0)
      AwsEc2Instance | 52.90.xx.xx | ports: 8080, 50000

RECOMMENDED ACTION:
  Priority #1: Lock down web-bastion-host — patch Log4j and
  restrict SSH to VPN CIDR. I can generate the fix.

  What format? terraform | cloudformation | cli | instructions
═══════════════════════════════════════════════════════════════════

Documentação completa →

"Esta identidade tem privilégios excessivos e qual é o raio de impacto?"

Análise de identidade IAM: compara permissões efetivas versus uso real no CloudTrail, identifica acesso com privilégios excessivos, mapeia potencial de movimento lateral (assunção de papéis, alcance entre contas) e gera recomendações de política de menor privilégio.

Recursos:

• Análise de permissões efetivas — ações totais em todos os serviços
• Comparação de permissões usadas versus não usadas a partir de dados do CloudTrail de 30 dias
• Classificação de privilégio excessivo — severo, alto, moderado ou mínimo
• Detecção de permissões perigosas — iam:, sts:AssumeRole(amplo), s3:, kms:Decrypt, etc.
• Mapeamento de movimento lateral — papéis assumíveis, alcance entre contas, acesso a serviços
• Análise de caminho de ataque — cadeias de ataque que passam por esta identidade
• Padrões de atividade CDR — IPs de origem, user-agents, padrões de horário
• Recomendação de política de menor privilégio com redução de risco estimada
• Checklist de implantação segura — modo de auditoria, testes, monitoramento, rollback
• Remediação proativa — gera políticas IAM atualizadas em Terraform, CloudFormation, Ansible, CLI, Pulumi ou ARM/Bicep

Uso:

# Review an identity by name or ARN
/orca-identity-review admin-role
/orca-identity-review arn:aws:iam::123456789012:role/ec2-bastion-role

# Or use natural language
is terraform-deploy overprivileged?
review the permissions on admin-role
what can this role access?

Palavras-chave para aprofundamento (digite após a revisão):

permissions    # Full permission list (used, unused, dangerous)
usage          # CDR activity details (actions, IPs, agents)
lateral        # Lateral movement analysis
attack paths   # Kill chains through this identity
alerts         # Open alerts on this identity
activity       # 30-day CDR event summary
recommend      # Least-privilege policy recommendation
full           # All sections expanded

Exemplo de saída:

═══════════════════════════════════════════════════════════════════
IDENTITY REVIEW — ec2-bastion-role
AwsIamRole | 123456789012 | arn:aws:iam::123456789012:role/ec2-bastion-role
═══════════════════════════════════════════════════════════════════

VERDICT: OVERPRIVILEGED

┌─────────────────────────────────────────────────────────────────┐
│  PERMISSIONS     312 effective actions across 28 services       │
│  OVERPRIVILEGE   SEVERE — has admin-level access it doesn't use│
│  USED (30d)      47 actions actually used                       │
│  UNUSED          265 actions never used — removal candidates    │
│  DANGEROUS       8 high-risk permissions (iam:*, s3:*, kms:*)  │
│  BLAST RADIUS    28 services, 150+ resources reachable          │
│  LATERAL MOVE    5 roles assumable, 2 accounts reachable        │
│  ATTACK PATHS    3 kill chains through this identity            │
│  ALERTS          4 open (2 critical, 1 high, 1 medium)         │
│  CDR ACTIVITY    847 events in 30d, 47 unique actions           │
│  CROWN JEWEL     NO                                             │
└─────────────────────────────────────────────────────────────────┘

TOP RISK:
  This role has 265 unused permissions including iam:*, enabling
  full privilege escalation if compromised.

RECOMMENDED ACTION:
  Remove 265 unused permissions to reduce blast radius by 85%.
  I can generate the updated least-privilege policy.

  What format? terraform | cloudformation | cli | instructions
═══════════════════════════════════════════════════════════════════

Documentação completa →

"Quem consegue entrar sem MFA e como fechamos essa lacuna sem bloquear ninguém?"

Varredura de lacunas de MFA em uma conta, unidade de negócio ou tag em todas as nuvens que o Orca suporta: encontra usuários cujo login no console não está protegido, classifica-os por pontuação de risco de identidade e conduz a remediação por meio de cadastro guiado ou um caminho de aplicação controlado. Um usuário somente com senha está a um phishing de se tornar um atacante, e nenhuma nuvem permite que um administrador cadastre MFA em nome de outra pessoa, então a aplicação significa uma política que bloqueia o usuário até que ele se cadastre.

Recursos:

• Cobertura entre nuvens — AWS, Azure (incl. Entra ID), GCP (via Google Workspace), Alibaba Cloud, OCI, Tencent Cloud
• Matriz de capacidades por provedor — o que MFA significa em cada nuvem e o que cada uma não consegue mostrar
• Classificação priorizando risco com incrementos por privilégio, ativos valiosos e alertas abertos
• Contas root tratadas com falha segura em seu próprio grupo — um sinal ilegível de root é escalado em vez de descartado
• Remediação ciente de uso — uma senha de console que ninguém usa é removida em vez de cadastrada
• Três caminhos controlados: orientar (instruções + notificações ao proprietário), aplicar (política de exigência de MFA), remover-acesso (excluir um perfil de login não utilizado)
• Confirmação baseada em evidências — a consequência é reafirmada antes do consentimento, e uma instrução em massa nunca implica aplicação
• Execuções com zero descobertas publicam prova de completude em vez de um "nada encontrado" simples
• Ciclo fechado — ações são comentadas e adiadas nos alertas relacionados, com uma nova verificação pós-varredura

Uso:

# Sweep an account, business unit, or tag
/orca-mfa-enforcement 123456789012
/orca-mfa-enforcement "Production"
/orca-mfa-enforcement --tag env=prod

# Or use natural language
who can log in without MFA?
does our root account have MFA?
find console users missing 2FA in the Production BU

Palavras-chave para aprofundamento (digite após a varredura):

detail <user>     # Full evidence for one identity
guide <ids|all>   # Enrollment instructions + owner notifications
enforce <ids>     # Require-MFA policy (passes the confirmation gate)
remove-access     # Delete an unused console password (gated)
recheck           # Post-scan delta: who enrolled, which alerts closed
cloud <provider>  # Re-scope to one cloud

Exemplo de saída:

═══════════════════════════════════════════════════════════════════
MFA SWEEP — acme-production
═══════════════════════════════════════════════════════════════════

8 users can sign in without MFA, including the root account.
2 are privileged. 1 signed in password-only this week.

 #  Identity                                   Provider  Risk      Action
 1  arn:aws:iam::123456789012:user/deploy      AWS       Critical  Guide, then enforce
 2  arn:aws:iam::123456789012:root             AWS       High      Guide only (root)
 3  arn:aws:iam::123456789012:user/analyst     AWS       High      Remove unused password

ROOT ACCOUNT:
  No API can enroll MFA on root — the account owner must do it signed
  in as root. Hardware MFA recommended (CIS).

QUICK WINS:
  6 console passwords were never used. Removing them closes the gap
  with zero user friction, and access keys are untouched.

MFA ENFORCEMENT SUMMARY
  Found: 8   Proposed: 8   Guided: 0   Enforced: 0   Skipped: 0
  Routed: 18 outside Found (14 API-only, 4 dormant — not MFA gaps)
═══════════════════════════════════════════════════════════════════

Documentação completa →

"O que aconteceu, quem fez e até onde chegaram?"

Investigação de incidentes com tecnologia CDR: rastreia a atividade do ator pelos logs do Orca CDR (CloudTrail/auditoria), constrói linhas do tempo de sessão, mapeia ações para técnicas MITRE ATT&CK, agrupa sessões relacionadas, avalia o raio de impacto e gera um veredito com recomendações de contenção.

Recursos:

• Investigação multi-eixo — por ator (identidade IAM), IP de origem, recurso alvo, conta ou alerta
• Agrupamento de sessões — agrupa eventos brutos em sessões coerentes por ator, IP e intervalos de tempo
• Mapeamento MITRE ATT&CK — mapeia cada ação para técnicas e táticas com níveis de confiança
• Avaliação de cadeia de ataque — quantas táticas ATT&CK são cobertas (parcial, quase completa, completa)
• Classificação de raio de impacto — contido, moderado, amplo ou severo
• Detecção de persistência — novos usuários, chaves de acesso, políticas de papel criadas
• Detecção de evasão de defesa — exclusão de trilhas, alterações em security groups, logging desabilitado
• Sinalização de atividade entre contas
• Extração de IOC — IPs, user-agents, identidades, recursos criados (prontos para copiar e colar em ferramentas de SOC)
• Veredito com confiança — comprometimento ativo, comprometimento provável, suspeito, provavelmente benigno, inconclusivo
• Contenção proativa — gera scripts de revogação, configurações de isolamento, regras de detecção em Terraform, CloudFormation, Ansible, CLI, Pulumi ou ARM/Bicep

Uso:

# Investigate by actor, IP, or resource
/orca-investigate arn:aws:iam::123456789012:role/ec2-bastion-role
/orca-investigate 10.0.1.50
/orca-investigate account 123456789012

# Or use natural language
investigate what this role did in the last 24 hours
trace activity from IP 10.0.1.50
who accessed the prod database?

Palavras-chave para aprofundamento (digite após a investigação):

timeline       # Chronological event timeline
sessions       # Clustered sessions with assessment
mitre          # MITRE ATT&CK technique mapping
blast radius   # Impact assessment
actions        # All actions summary
resources      # Resources touched
alerts         # Related alerts
iocs           # Indicators of compromise (copy-paste ready)
contain        # Containment recommendations
full           # All sections expanded

Exemplo de saída:

═══════════════════════════════════════════════════════════════════
INVESTIGATION — ec2-bastion-role
arn:aws:iam::123456789012:role/ec2-bastion-role | Last 24 hours
═══════════════════════════════════════════════════════════════════

VERDICT: SUSPICIOUS | CONFIDENCE: 72%

┌─────────────────────────────────────────────────────────────────┐
│  EVENTS          156 total, 23 unique actions                   │
│  SESSIONS        3 distinct sessions                            │
│  TIME SPAN       04:12 → 16:47 UTC (12h 35m)                  │
│  SERVICES        7 AWS services touched                         │
│  RESOURCES       34 distinct resources accessed                 │
│  SOURCE IPs      2 unique (1 known VPN, 1 unknown)             │
│  USER AGENTS     2 unique (boto3, aws-cli)                      │
│  BLAST RADIUS    MODERATE — multiple services, same account     │
│  MITRE ATT&CK   5 techniques across 4 tactics                  │
│  ALERTS          4 related alerts on involved assets            │
│  ATTACK PATHS    3 kill chains involving this actor             │
└─────────────────────────────────────────────────────────────────┘

EXECUTIVE SUMMARY:
  ec2-bastion-role had 3 sessions in the last 24h. Session 2 came
  from an unknown IP and performed unusual discovery actions across
  S3 and IAM. No persistence or exfiltration detected yet.

MITRE ATT&CK COVERAGE:
  ■ Initial Access    □ Execution    □ Persistence    □ Priv Esc
  □ Defense Evasion   ■ Discovery    □ Lateral Move   ■ Collection
  □ Exfiltration      □ Impact

RECOMMENDED ACTION:
  Investigate the unknown source IP in Session 2. I can generate
  a containment script to restrict this role's permissions.

  What format? terraform | cloudformation | cli | instructions
═══════════════════════════════════════════════════════════════════

Documentação completa →

"Onde estamos gastando demais e o que devemos corrigir primeiro?"

Analisa todos os ativos de nuvem por meio dos dados do Orca Security MCP para identificar oportunidades acionáveis de redução de custos em computação, bancos de dados, armazenamento, rede e recursos serverless. Entrega um relatório para dois públicos: um resumo executivo com faixa de economia total e um plano de ação por ativo com links da plataforma Orca, links do console da nuvem, comandos CLI e economia mensal projetada por item.

Recursos:

• 10 padrões de otimização: recursos ociosos, redimensionamento, upgrades de geração, instâncias reservadas, migração para spot, dimensionamento de banco de dados, Multi-AZ em não-produção, EBS gp2→gp3, tiering de S3/objetos, limpeza de rede
• Saída para dois públicos — resumo executivo (topo e rodapé do relatório) além de etapas de implementação prontas para engenheiros
• Cada recomendação inclui deep-links da plataforma Orca e URLs do console do provedor de nuvem como evidência
• Descoberta de ativos da Fase 1 em paralelo em todas as categorias de recursos (EC2, EBS, S3, RDS, Lambda, NAT Gateways, EIPs, load balancers)
• Roteiro de implementação em 3 fases: vitórias rápidas sem downtime, mudanças em janela de manutenção, compromissos financeiros
• Consultas de preços ao vivo (busca na web) com fallback para dados de treinamento quando indisponíveis

Uso:

# Run a cost optimization report
/orca-cloud-cost-optimizer

# Or use natural language
give me a cost optimization report
where are we wasting money on cloud?
how do we cut our AWS bill?
find unused resources
what can we rightsize?

Exemplo de saída:

# ☁️ Cloud Cost Optimization Report

Generated: 2026-05-01
Environment: AWS (us-east-1, us-east-2, eu-central-1) | Azure (eastus)
Assets analyzed: 450 across 5 AWS accounts

## 📊 Executive Summary

| | |
|---|---|
| Total assets analyzed | 450 |
| Assets with savings opportunities | 150 (33%) |
| Estimated monthly savings | $2,100 – $3,400/month |
| Estimated annual savings | $25,200 – $40,800/year |
| Immediate low-risk savings (this week) | $800/month |

🏆 Top 5 Quick Wins:
1. EBS gp2→gp3 migration (124 volumes) — $430/month — Very Low Risk
2. Disable Multi-AZ on staging RDS (analytics-db-staging) — $438/month — Low Risk
3. m4.2xlarge→m6i.2xlarge generation upgrade (api-staging-01) — $291/month — Low Risk
4. Release idle Elastic IPs (3 unassociated) — $10/month — Very Low Risk
5. S3 lifecycle policies (cloudtrail + log buckets) — $120/month — Very Low Risk

Documentação completa →

"Como crio um framework de conformidade personalizado adaptado às minhas necessidades?"

Cria frameworks de conformidade personalizados no Orca Security a partir de controles de frameworks existentes, listas de alertas ou temas de segurança. Coleta controles relevantes por meio das ferramentas de leitura do MCP, organiza-os em seções lógicas e envia o framework para o Orca via API REST. Quando existem lacunas — controles que o usuário deseja, mas o Orca não tem uma regra nativa — sugere criar alertas de descoberta personalizados para preenchê-las.

Recursos:

• 3 modos de entrada: baseado em tema ("Supply Chain Security"), a partir de framework ("from:cis_docker") ou lista de alertas
• Puxa controles de vários frameworks existentes e deduplica rule_ids
• Organiza em seções temáticas com pesos de prioridade (alto/médio/baixo)
• Cria frameworks via API REST do Orca (POST /api/compliance/frameworks)
• Identifica lacunas de cobertura e sugere alertas de descoberta personalizados (POST /api/sonar/rules)
• Validação pós-criação com pontuação inicial de conformidade

Uso:

/orca-custom-framework Supply Chain Security Controls
/orca-custom-framework from:cis_docker_v.1.3.1
/orca-custom-framework alerts:orca-1234,orca-5678

# Or use natural language
create a custom compliance framework for supply chain security
build a framework based on CIS Docker + EKS controls
generate a custom framework from these alerts

Exemplo de saída:

=====================================================================
CUSTOM FRAMEWORK CREATED
=====================================================================

  FRAMEWORK     Supply Chain Security Controls
  ID            3104
  CONTROLS      39 total across 6 sections
  INITIAL SCORE 28%
  CLOUD         aws, azure, gcp, shiftleft

SECTIONS:
  1. Container Image & Registry Security       6 controls
  2. Container Runtime Protection              8 controls
  3. Kubernetes Admission & Policy Controls    8 controls
  4. Secrets & Credential Management           7 controls
  5. Build Pipeline & Artifact Integrity       4 controls
  6. Audit Logging & Monitoring                6 controls

COVERAGE GAPS (suggest custom discovery alerts):
  - SBOM generation and validation
  - Container image signing (SLSA provenance)
  - Dependency vulnerability scanning in CI/CD
=====================================================================

Documentação completa →

"Por que meu conector Kubernetes não está instalando ou conectando?" Solução de problemas self-service para o Kubernetes Connector (K8s Tunnel Client, Helm chart orca-tunnel). Recebe entrada bruta do cliente — uma mensagem de erro, helm status, kubectl describe ou logs de pod — e a mapeia para uma categoria conhecida de falha de instalação ou runtime, então conduz a remediação passo a passo liderada por uma correção de uma linha antes do detalhe técnico. Faz perguntas de esclarecimento quando a entrada é ambígua e produz um handoff de suporte limpo para qualquer coisa que não consiga resolver, incluindo limitações conhecidas da plataforma que não podem ser corrigidas do lado do cliente.

Recursos:

• Faz triagem da entrada em instalação (chart nunca implantado) vs. runtime (implantado, tunnel/scan não funcionando), começando com uma verificação de sanidade sobre se o cluster precisa do Connector
• Inclui uma tabela de referência rápida sintoma → categoria para que um erro colado vá direto para a correção em vez de percorrer a lista completa
• Cobre 15 categorias conhecidas de falha: conectividade TLS/rede, RBAC, pulls de imagem, parâmetros inválidos de --set, incompatibilidade de versão, entradas duplicadas de cluster, restrições de recursos, namespaces personalizados, tokens de service account expirados (K8s 1.30+), NetworkPolicy bloqueando egress do API server, quedas de autenticação do tunnel, configuração incorreta de proxy (incluindo proxies com inspeção TLS), falhas de DNS, problemas de SCC no OpenShift e "conectado, mas sem dados de scan"
• Reconhece limitações da plataforma que o cliente não pode corrigir sozinho (por exemplo, contas BYOC não executam scanning de Kubernetes, alvos de tunnel obsoletos, um bug conhecido de crash de tunnel no AKS) e escala em vez de entrar em loop — enquanto aponta para a API de exclusão self-service para entradas duplicadas de cluster em vez de escalar esse caso
• Produz um resumo estruturado de handoff de suporte (tipo de cluster, versão do connector, categoria, IDs, logs) quando não consegue resolver o problema

Uso:

/orca-k8s-connector-troubleshoot <paste error, helm status, kubectl describe, or pod logs>

# Or natural language
the k8s connector pod is stuck in ImagePullBackOff
tunnel keeps disconnecting, logs show TLS handshake timeout
cluster shows connected in Orca but no inventory data is showing up

Documentação completa →

"Quais das nossas identidades são peso morto e como desabilitamos ou excluímos com segurança?"

Varre uma conta ou unidade de negócios em busca de identidades inativas (usuários, grupos e identidades não humanas) em todos os provedores de nuvem que a Orca suporta: AWS, Azure (incl. Entra ID), GCP (incl. Google Workspace), Alibaba Cloud, OCI e Tencent Cloud. Classifica os achados por pontuação de risco da identidade e conduz a limpeza por um caminho não destrutivo (desabilitar) ou um caminho destrutivo (excluir) que sempre exige confirmação explícita.

Recursos:

• Pergunta pelo período de inatividade se não for fornecido (90 dias é a convenção integrada da Orca; 30/60/180 ou personalizado são suportados)
• Cobertura entre nuvens: usuários, grupos e NHIs para todos os seis provedores suportados
• Ancorado no veredito de atividade pré-computado da Orca (timestamps de última atividade), com corroboração do CDR
• Classificação com prioridade de risco: admins dormentes, credenciais expostas e acesso a joias da coroa flutuam para o topo
• Fluxo de desabilitar primeiro: desativação reversível agora, exclusão após um período de carência
• Portão de confirmação explícita antes de qualquer exclusão, com pré-visualização do raio de impacto (o que ainda referencia a identidade)
• Exclusões automáticas: contas break-glass, identidades novas demais para julgar, casos de borda possivelmente humanos
• Artefatos de remediação prontos para execução (CLI/Terraform) com pré-requisitos de exclusão ordenados corretamente
• Resumo de limpeza obrigatório: encontrados, desabilitados, excluídos, propostos, ignorados e uma estimativa de alertas que serão fechados

Uso:

# Sweep an account or business unit
/orca-inactive-identities-cleanup 123456789012
/orca-inactive-identities-cleanup "Production"

# Custom time frame, scope, or action
/orca-inactive-identities-cleanup 123456789012 --inactive 60d
/orca-inactive-identities-cleanup 123456789012 --only nhis
/orca-inactive-identities-cleanup 123456789012 --action disable

# Or use natural language
clean up inactive identities in acme-production
which users haven't been active in the last 60 days?
disable the dormant service accounts in the Production BU

Palavras-chave de aprofundamento (digite após a varredura):

detail <identity>   # Full evidence for one identity
disable <ids|all>   # Generate disable artifacts
delete <ids>        # Delete flow (explicit confirmation required)
window <Nd>         # Re-run with a different time frame
only <bucket>       # users | groups | nhis
cloud <provider>    # aws | azure | gcp | alicloud | oci | tencent

Exemplo de saída:

═══════════════════════════════════════════════════════════════════
INACTIVE IDENTITY CLEANUP — acme-production
Window: 60 days | AWS + Azure + GCP
═══════════════════════════════════════════════════════════════════

62 identities inactive for 60+ days: 41 users, 6 groups, 15 NHIs.
9 carry high or critical risk.

TOP RISK (highest first):
  #  Identity              Type      Provider  Last active  Risk      Action
  1  legacy-admin          IAM user  AWS       142d ago     Critical  Disable now
  2  svc-deploy-old        SP        Azure     never        High      Disable now
  3  ci-runner-2019        Role      AWS       201d ago     High      Disable now

QUICK WINS: 12 identities with zero privileges and zero activity.

CLEANUP SUMMARY  (window: 60 days)
  Found:     62 | Disabled: 0 | Deleted: 0 | Proposed: 55 | Skipped: 7
  Alerts:    ~24 open alerts on these identities close after the next scan
═══════════════════════════════════════════════════════════════════

Documentação completa →

"Quais das nossas identidades têm muito mais permissão do que usam e como reduzimos com segurança?"

Varre uma conta ou unidade de negócios em busca de identidades com privilégios excessivos usando as recomendações pré-computadas de PoLP (Princípio do Menor Privilégio) da Orca em AWS, Azure e GCP. Classifica os achados por pontuação de risco da identidade e conduz o redimensionamento por um caminho não destrutivo (preparar a mudança como artefatos prontos para execução) ou um caminho destrutivo (aplicar) que sempre exige uma verificação de segurança baseada em evidências mais confirmação explícita.

Recursos:

• Ancorado no mecanismo de recomendação da Orca: vereditos por identidade computados a partir de ~90 dias de uso observado
• Correções tipadas por identidade: troca para somente leitura, redução de escopo, política de menor privilégio gerada ou conversão JIT
• Classificação com prioridade de risco com uma coluna "quão sobre-privilegiado" (serviços usados vs. concedidos)
• Fluxo de preparar primeiro: artefatos com rollback e verificação embutidos, nada aplicado automaticamente
• Portão de aplicação baseado em evidências: reproduz a atividade recente real da identidade (CDR) contra a mudança proposta e relata exatamente o que quebraria
• Confirmação explícita antes de qualquer aplicação, com pré-visualização do raio de impacto para papéis
• Exclusões automáticas: identidades gerenciadas pelo provedor, contas break-glass, papéis de fornecedor/entre contas
• Handoffs limpos: identidades inativas roteadas para orca-inactive-identities-cleanup, candidatos JIT para conversão JIT
• Resumo de redimensionamento obrigatório: encontrados, preparados, aplicados, retidos, ignorados e as permissões permanentes que o plano remove

Uso:

# Sweep an account or business unit
/orca-overprivileged-identities-rightsizing 123456789012
/orca-overprivileged-identities-rightsizing "Production"

# Scope, provider, or pre-selected path
/orca-overprivileged-identities-rightsizing 123456789012 --only nhis
/orca-overprivileged-identities-rightsizing 123456789012 --cloud aws
/orca-overprivileged-identities-rightsizing 123456789012 --action stage

# Or use natural language
right-size the over-privileged identities in acme-production
which roles have permissions they never use?
who has admin but only ever reads?

Palavras-chave de aprofundamento (digite após a varredura):

detail <identity>   # Full evidence: used vs granted, the recommendation
stage <ids|all>     # Generate right-sizing artifacts (nothing applied)
apply <ids>         # Apply flow (safety check + explicit confirmation)
safecheck <identity># Run the CDR replay on its own
cloud <provider>    # aws | azure | gcp
only <bucket>       # users | nhis

Exemplo de saída:

═══════════════════════════════════════════════════════════════════
OVER-PRIVILEGED IDENTITY RIGHT-SIZING — acme-production
Engine window: ~90 days | AWS + Azure + GCP
═══════════════════════════════════════════════════════════════════

31 identities hold permissions they haven't used in ~90 days:
9 users, 22 NHIs. 7 carry high or critical risk; right-sizing
removes ~840 unused permissions.

TOP RISK (highest first):
  #  Identity        Type     Provider  Uses            Recommendation    Risk      Change
  1  deploy-runner   Role     AWS       3 of 41 svcs    Reduce perms      Critical  Apply least-priv policy
  2  ops-sp-legacy   SP       Azure     read-only use   Read-only swap    High      Swap to Reader
  3  etl-sa          SA       GCP       narrow scope    Scope reduction   High      Re-scope binding

QUICK WINS: 5 identities only ever read; swap to read-only today.

RIGHT-SIZING SUMMARY  (engine window: ~90 days)
  Found: 31 | Proposed: 24 | Staged: 0 | Applied: 0 | Held: 0 | Skipped: 3 | JIT: 4
  Handed off: 12 inactive -> /orca-inactive-identities-cleanup
  Removes: ~840 unused service grants once the staged plan is applied
═══════════════════════════════════════════════════════════════════

Documentação completa →

"De quantas políticas nossos admins realmente precisam e quem vai em cada uma?"

Lê o agrupamento de admins pré-computado da Orca (IAM Policy Optimizer) para AWS, Azure e GCP, que já classificou a população de admins da organização em grupos pelo que cada admin realmente faz e gerou uma política de menor privilégio por grupo. Apresenta o agrupamento recomendado pelo mecanismo, mostra o que cada grupo receberia em vez de AdministratorAccess / Owner genéricos e conduz a troca por um caminho não destrutivo (preparar) ou um caminho destrutivo (aplicar) que sempre exige confirmação explícita por grupo.

Recursos:

• Uma chamada MCP para toda a organização (get_recommended_admin_policies) retorna todos os grupos com todos os membros, sem teto de 50 resultados, então a enumeração é completa em vez de melhor esforço
• Padrão é o plano recomendado pelo próprio mecanismo; outros agrupamentos (políticas mais restritas vs. menos políticas para manter) disponíveis sob solicitação
• Começa com o balde de inativos: admins para os quais a Orca não encontrou ações observadas, entregues a /orca-inactive-identities-cleanup
• Expõe a troca da união explicitamente — uma política de grupo é a união das ações observadas de seus membros, então cada membro ganha o que seus colegas de grupo usaram
• Precisão por provedor: AWS emite uma política IAM (com escopo de ação, Resource: "*"), Azure um papel RBAC personalizado, GCP um papel personalizado — todos como rascunhos que precisam de correções de escopo e nomenclatura antes da implantação
• Honesto sobre a população: cobre admins que já carregam uma recomendação PoLP da Orca, não todos os admins da organização
• Enriquecimento limitado: pontuações de risco, re-verificações de ainda-admin e última atividade apenas ao aprofundar em um grupo
• Portão de aplicação: reprodução de atividade contra a política proposta, verificação de raio de impacto para papéis / service principals / identidades gerenciadas, confirmação explícita nomeando o grupo
• Resumo de agrupamento obrigatório: no escopo, inativos, agrupados, propostos, preparados, aplicados, retidos, ignorados

Uso:

# Default run — engine-recommended grouping, all providers
/orca-admin-access-grouping

# Narrow or re-plan
/orca-admin-access-grouping --cloud aws
/orca-admin-access-grouping --plan 3
/orca-admin-access-grouping --group 2

# Or use natural language
group our admins and show me what each group would get
how many admin policies do we actually need?
replace AdministratorAccess with something scoped

Palavras-chave de aprofundamento (digite após a execução):

group <n>           # Members, risk, still-admin status, and the union delta
plan <n>            # Re-render against a different number of groups
stage <group|all>   # Generate artifacts, apply nothing
apply <group>       # Apply flow (replay + explicit confirmation required)
safecheck <group>   # Run the activity replay on its own
cloud <provider>    # aws | azure | gcp

Exemplo de saída:

═══════════════════════════════════════════════════════════════════
ADMIN ACCESS GROUPING — acme-corp
Plan: plan_2 (engine recommendation) | AWS + GCP
═══════════════════════════════════════════════════════════════════

61 of the 67 AWS admins Orca can act on show no observed activity
in the last 90 days. The remaining 6 need two policies between them.

GROUPS (biggest standing-risk reduction first):
  #  Group     Members  Granted  Avg used  Instead of
  1  policy_1  5        16       3         AdministratorAccess
  2  policy_2  1        136      136       AdministratorAccess

UNION NOTE: in group 1, three members gain iam:CreateUser and
iam:DeleteUser from a fourth. Review before applying.

INACTIVE: 61 admins → /orca-inactive-identities-cleanup

ADMIN GROUPING SUMMARY  (window: last 90 days; artifact: daily snapshot)
  In scope: 67 | Inactive: 61 | Grouped: 6 | Proposed: 2 | Applied: 0
═══════════════════════════════════════════════════════════════════

Documentação completa →