SOC agêntico via marketplace: guia de compra e contrato

Um fornecedor a mais no cadastro. Um contrato com o papel dele, uma fatura em dólar fora da fatura de nuvem e um calendário de renovação que o financeiro nunca cruza com o orçamento de cloud. O caminho direto de contratar detecção e resposta gerenciadas funciona, e cobra em burocracia o que deveria cobrar em decisão.

A proposta aprovada, porém, pode entrar pela conta de nuvem. Um SOC agêntico (Security Operations Center, o centro de operações de segurança, operado por agentes de IA com validação humana) muda de balcão, não de função. A pergunta deixa de ser quanto custa e passa a ser quem responde.

O texto é escrito do lado do comprador. Os findings que o Security Hub já agrega na conta continuam saindo dela por uma autorização cross-account que o comprador concede e precisa revisar a cada renovação. A fatura consolida. A responsabilidade, não.

O que a assinatura de um SOC agêntico pelo marketplace resolve

Assinar um SOC agêntico pelo AWS Marketplace usa o acordo de nuvem vigente: a compra entra como uma linha na fatura consolidada, com preço e prazo em private offer. O anúncio do Aurora Agentic SOC, publicado no blog do AWS Marketplace em 16/10/2026, atribui a esse caminho menos overhead de contratação, procurement mais simples e billing consolidado.

A assinatura não define quem responde pela operação, e é aí que a fatura para de resolver.

São atribuições do anúncio, não medições.

Para quem já contrata segurança como serviço, a novidade não está no serviço. Está em onde ele é comprado.

A tabela usa cinco critérios e aplica a mesma lógica de compra direta ou marketplace de software a um serviço contínuo.

O anúncio cita o ISC2 2025 AI Pulse Survey, que estima que 30% das equipes de segurança já integraram ferramentas de IA às operações.

A fatura consolida, o acesso não

O pipeline que alimenta o SOC roda na conta AWS do comprador. O Security Hub CSPM agrega os findings em ASFF, o EventBridge dispara o evento, o Firehose leva ao S3, o Lambda enriquece, e o SOC lê o bucket por autorização IAM cross-account. A fatura consolidada não reduz esse acesso.

O GuardDuty, o Inspector, o Macie, o Config e ferramentas de terceiros entregam achados ao Security Hub CSPM, que os normaliza em ASFF (AWS Security Finding Format). O EventBridge dispara a cada finding, sem polling.

O Firehose leva o evento ao S3 com buffer e batching. O Lambda processa, enriquece e roteia para um bucket de destino, e o SOC lê esse bucket por IAM cross-account.

Os templates CloudFormation do fornecedor implantam esse pipeline na conta do comprador. O sistema que produz os dados mora do lado de quem compra.

Os agentes do framework Swarm of Experts fazem triagem, investigação e resposta no SOC, com analistas humanos validando e escalonando; a integração descrita lê o bucket de destino, e o que essa leitura alcança está no papel IAM e no contrato, não no anúncio.

O fornecedor declara monitorar mais de 10.000 clientes, processar mais de 10 trilhões de eventos de segurança por semana e acumular mais de 14 anos de dados curados.

O AWS Shared Responsibility Model organiza o resto: a AWS responde pela segurança da infraestrutura, e o comprador continua responsável pelo que roda na conta dele, inclusive os recursos que o stack do fornecedor cria. A confiança cross-account é concedida, revisada e revogada na conta do comprador; o fornecedor assume a role e opera o SOC do lado dele.

Sobra ao comprador a parte operacional que não aparece na proposta: quotas do Firehose, ciclo de vida do bucket, custo do consumo e leitura de findings por um terceiro. É contrato, não arquitetura.

Quanto custa: assinatura e consumo são duas contas

A contratação cria duas linhas de custo. A assinatura tem preço e prazo negociados com o fornecedor e aparece na fatura AWS consolidada. O pipeline consome serviços AWS pagos por uso, cobrados direto do comprador. Aprovar só a primeira linha deixa a segunda sem dono.

A segunda linha não negocia com ninguém. Cada finding vira evento no Firehose, objeto no S3 e invocação de Lambda. O comprador paga à AWS pelos recursos que o stack cria e pelo processamento dos findings, separadamente da assinatura.

O billing consolidado na AWS junta as duas na mesma fatura. Só uma foi negociada, e a diferença atravessa o trimestre sem explicação.

Quem usa a mecânica de comprar software pelo marketplace da nuvem contra um compromisso de gasto precisa conferir no próprio acordo se a assinatura conta para o compromisso e como o consumo dos serviços AWS entra na conta do trimestre.

O tratamento tributário da remessa não é o objeto deste texto.

A pergunta de orçamento não é o preço da assinatura. É quem assina a linha variável quando o volume de findings dobra numa semana de incidente.

Prazo, renovação e a diferença entre desligar e cancelar

O prazo, a renovação e o cancelamento seguem os termos do acordo negociado com o fornecedor, e o anúncio diz isso de forma explícita. A remoção técnica é outra coisa: apagar os stacks CloudFormation interrompe o envio de findings e não cancela a assinatura.

Existem dois calendários, e eles quase nunca coincidem: o do contrato tem início, prazo, janela de cancelamento e data de renovação, e o da conta tem stacks instalados e destinos apontando para um bucket.

Apagar os stacks interrompe o envio de findings, e a assinatura continua ativa. A fatura chega do mesmo jeito, porque a assinatura mora no acordo, não no stack. Quem encerra a operação sem encerrar o contrato paga por um serviço que já não recebe dado.

O contrário também acontece, e custa mais: o contrato termina, o pipeline fica instalado, capturando findings, gastando Firehose e enchendo o S3 de um destino que ninguém lê. Nenhum dos dois lados desinstala por cortesia.

A renovação segue o acordo, e o que ele diz precisa ser lido na cláusula, não deduzido da fatura.

Duas perguntas resolvem isso antes da assinatura. Quem percebe a renovação, e quem desinstala?

Aprovação e orçamento: quem assina, quem é dono da linha, quem percebe a renovação

Consolidar a cobrança muda o caminho da aprovação. A compra passa a competir com o orçamento de nuvem, e o dono da linha deixa de ser necessariamente quem opera o serviço. Três campos precisam estar definidos antes da assinatura: dono, linha de orçamento e alerta de renovação.

Quando a assinatura entra na fatura de nuvem, ela deixa de ser compra de segurança e passa a ser linha de cloud. Quem aprova orçamento de nuvem raramente é quem aprova ferramenta de segurança, e o valor compete com instância e compromisso de gasto.

A private offer define preço, prazo e termos. Quem negocia costuma ser procurement. Quem opera é o time de segurança. Quem paga a linha variável costuma ser ninguém, até o primeiro incidente.

Separar as três funções é decisão de desenho. Dono do serviço, dono da linha e dono do alerta podem ser a mesma pessoa, desde que escrito.

A linha precisa circular. Embutir procurement no fluxo com as APIs do marketplace leva a cobrança para o procurement e para o ERP, onde a renovação deixa de depender de memória.

O que verificar antes de assinar

Nove verificações precisam de resposta antes da assinatura. As três primeiras tratam do que os agentes podem fazer, da credencial usada e do escopo da leitura cross-account. As demais cobrem retenção, custo do lado AWS, unidade de preço, renovação, dados e a divisão entre o que a AWS cobre e o que sobra ao comprador.

1. Escopo dos agentes e o ponto de validação humana. Os agentes fazem triagem, investigação e resposta, e analistas humanos validam e escalonam.
2. Qual credencial o fornecedor usa. A leitura é por IAM cross-account, concedida na conta do comprador, e a revogação precisa de dono e prazo.
3. O que a leitura cross-account alcança. Qual bucket, qual prefixo, e se o escopo cresce.

As três primeiras definem o que o fornecedor enxerga, e o jurídico lê com o time de segurança.

1. Retenção e ciclo de vida do bucket. Quem define a expiração, quem paga o armazenamento e o destino do histórico.
2. Pré-requisitos e custo do lado AWS. Security Hub e GuardDuty precisam estar habilitados, além de assinatura ativa, e geram consumo.
3. Unidade de medida do preço na private offer. Por usuário, por volume ou por ativo, e o que faz o número subir.

O bloco do meio fica fora da proposta comercial, e é onde o custo aparece depois.

1. Renovação, cancelamento e o que sobrevive ao fim. A renovação segue o acordo, e sobrevive o que não foi desinstalado.
2. Tratamento de dados, subprocessadores e residência. O pipeline roda na conta do comprador e o SOC lê o bucket de destino, então o dado atravessa a fronteira entre as duas contas a cada finding processado.
3. O que a AWS cobre e o que sobra ao comprador. A operação de segurança é o que o comprador assina de volta.

Nenhum dos nove é novo para quem já contratou segurança; todos mudam com a compra pelo marketplace.

Quando o marketplace é a rota errada

A rota pelo marketplace é a errada quando o time não consegue operar o pipeline dentro da própria conta, quando a leitura por terceiro não passa pela política de dados, ou quando a compra precisa sair em moeda local com documento fiscal local. Nesses casos, a consolidação não compensa.

A primeira é operacional: sem dono para quotas, ciclo de vida do bucket e revisão do IAM, a empresa herda o trabalho.

A segunda é de dados. Uma política que não admite leitura contínua por terceiro não muda porque a fatura ficou mais simples.

A terceira é de contratação: quando a compra precisa sair em real, com documento fiscal local e ponto de contratação definido, a rota muda. O Nexforce Marketplace contrata soluções internacionais de software e IA com preço em real, nota fiscal brasileira e procurement centralizado, com alertas de orçamento e de renovação.

A consolidação de billing resolve a fatura, não a responsabilidade. O Nexforce Marketplace muda a moeda, o documento fiscal e o ponto de contratação, não quem responde pela operação de segurança.

https://nexforce.ai/marketplace

A rota pelo marketplace da nuvem compensa quando o time opera o pipeline na própria conta e a leitura por terceiro passa pela política de dados.

Perguntas frequentes

O que muda ao assinar um SOC agêntico pelo marketplace?

A assinatura usa a conta AWS que a empresa já tem, com preço e prazo em private offer e cobrança na fatura consolidada. O que não muda é a operação: o pipeline continua rodando na conta do comprador, com a mesma responsabilidade sobre a operação.

O que acontece com o pipeline se o contrato terminar?

O SOC gerenciado continua instalado. Os stacks CloudFormation seguem na conta, capturando findings e consumindo Firehose, S3 e Lambda. Apagar esses stacks interrompe o envio de findings e não cancela a assinatura. Quem desinstala, e em que prazo, fica definido no contrato, inclusive no último dia de vigência.

Quem paga o consumo de AWS que o pipeline gera?

O comprador. A assinatura cobre o serviço do fornecedor, e o pipeline consome serviços AWS pagos por uso, cobrados direto na conta. Security Hub e GuardDuty precisam estar habilitados, e Firehose, S3 e Lambda crescem com o volume de findings processados em semanas de incidente.

O que verificar no acesso cross-account antes de assinar?

Qual bucket o fornecedor lê, com qual prefixo, por qual conta e por qual credencial. Verificar também como essa autorização é revogada e se o escopo pode crescer sem nova aprovação. Quando o contrato termina, alguém precisa definir quem leva o histórico e quem apaga o que ficou.

Quando compensa contratar SOC pelo marketplace?

Compensa quando o time consegue operar o pipeline dentro da própria conta e a leitura por terceiro passa pela política de dados. Quando a compra precisa sair em moeda local, com documento fiscal local, o marketplace da nuvem deixa de ser a rota mais simples.

Referências

Anúncio "Resolve security signals faster with Arctic Wolf's Aurora Agentic SOC", AWS Marketplace blog, 16/10/2026. https://aws.amazon.com/blogs/awsmarketplace/resolve-security-signals-faster-with-arctic-wolfs-aurora-agentic-soc/ Acesso em 23/10/2026.

ISC2 2025 AI Pulse Survey, citado no anúncio acima. Acesso em 23/10/2026.

AWS, Shared Responsibility Model. https://aws.amazon.com/compliance/shared-responsibility-model/ Acesso em 23/10/2026.

O próximo passo

A próxima tarefa cabe numa folha: levar as nove verificações para a mesa em que o jurídico lê com o time de segurança, escrever os três nomes (dono do serviço, dono da linha de orçamento e dono do alerta de renovação) e pedir a private offer com a unidade de preço e a forma de revogação do acesso cross-account no texto. O que ficar fora dessas três linhas aparece no trimestre seguinte, na primeira semana de incidente em que o volume de findings dobrar.

Depois disso a decisão fica simples. Quando a compra precisa sair em real, com documento fiscal brasileiro e ponto de contratação definido, o Nexforce Marketplace contrata soluções internacionais de software e IA com preço em real, nota fiscal brasileira e procurement centralizado, com alertas de orçamento e de renovação. Ele muda a moeda, o documento fiscal e o ponto de contratação. Não muda quem responde pela operação de segurança, e essa parte segue na conta do comprador, com o pipeline e o acesso cross-account sob o IAM que a empresa concede e revisa.