Agentforce Ultrapassou US$ 800 Milhões em ARRAgentforce Ultrapassou US$ 800 Milhões em ARR

Salesforce acabou de fechar seu ano fiscal 2026 com números que fariam qualquer investidor prestar atenção. Agentforce atingiu US$ 800 milhões em receita recorrente anual, um crescimento de 169% em relação ao ano anterior. A empresa fechou 29.000 deals de Agentforce — um salto de 50% apenas no quarto trimestre — e processou quase 20 trilhões de tokens desde o lançamento da plataforma, convertendo-os em mais de 2,4 bilhões de unidades de trabalho agentic.

Marc Benioff descreveu o momento como a transformação da Salesforce no “sistema operacional da Agentic Enterprise”, uma plataforma onde humanos e agentes trabalham juntos de forma integrada e confiável. Os cases reais impressionam: a Williams-Sonoma implantou uma agente chamada Olive que resolve 60% das conversas de clientes no site. O IRS automatizou até 98% de atividades manuais, reduzindo o tempo para abrir um processo na corte tributária de 10 dias para 30 minutos. A cidade de Kyle, no Texas, processou mais de 12.000 solicitações de cidadãos com resolução de quase 90% na primeira chamada.

Por baixo desses números, porém, existe uma realidade que merece atenção de qualquer arquiteto, administrador ou CTO trabalhando com Salesforce hoje. E ela tem tudo a ver com governança.

A Lacuna de Governança que Ninguém Está Discutindo

Em fevereiro de 2026, a Salesforce publicou seu Connectivity Report, um estudo com 1.050 líderes de TI empresarial que revelou dados que merecem ser analisados com cuidado. As organizações utilizam atualmente uma média de 12 agentes de IA, um número projetado para crescer 67% nos próximos dois anos. Até aí, nada surpreendente — o mercado de agentes de IA está em expansão acelerada.

O detalhe que muda a conversa é que metade desses agentes opera em silos isolados, sem fazer parte de sistemas multi-agente coordenados. O número de aplicações empresariais em uso cresceu de 897 para 957 ano após ano, mas apenas 27% delas estão integradas. Quando 86% dos líderes de TI dizem que estão preocupados que os agentes introduzam mais complexidade do que valor sem a integração adequada, não estão falando de um problema hipotético. Estão descrevendo o que já vivem no dia a dia.

Os desafios de implantação citados como prioritários foram claros: gestão de risco e compliance em primeiro lugar com 42%, seguido por falta de expertise interna em IA com 41%, e incompatibilidade de infraestrutura legada com 37%. Um dado adicional chama atenção: 96% das organizações relataram barreiras para usar dados com IA, sendo que 40% apontaram especificamente a arquitetura de TI desatualizada como o gargalo.

Andrew Comstock, SVP e GM da MuleSoft na Salesforce, resumiu o ponto de forma direta: o sucesso de uma Agentic Enterprise não está no número de agentes implantados, mas na efetividade geral deles. Precisamos pensar em como esses agentes são descobertos e orquestrados para trabalhar juntos.

O Modelo de Responsabilidade Compartilhada do Agentforce

Salesforce publicou em fevereiro de 2026 um artigo de suporte técnico detalhando o modelo de segurança do Agentforce, e ele funciona sob um princípio que todo time que trabalha com a plataforma precisa entender: responsabilidade compartilhada. A Salesforce fornece uma camada fundamental segura, mas os administradores são responsáveis por configurar acesso, permissões e guardrails específicos de cada agente.

Isso significa que a segurança do Agentforce não é algo que você simplesmente “liga” e pronto. Ela exige configuração ativa, revisão contínua e uma compreensão clara de onde termina a responsabilidade da plataforma e começa a sua. Vamos detalhar cada camada.

Camada 1: Einstein Trust Layer

O coração da segurança do Agentforce é o Einstein Trust Layer, um conjunto integrado de controles de segurança e privacidade que intercepta todas as interações — prompts e respostas — entre sua org e os modelos de linguagem que alimentam os agentes. Três recursos são particularmente relevantes:

Zero Data Retention: os prompts e respostas não são retidos pelos provedores de LLM terceirizados. Seus dados não são usados para treinar os modelos deles. Isso elimina uma das preocupações mais comuns que ouvimos de equipes de compliance.

Detecção de Toxidez e Prompt Injection: a camada protege tanto entradas do usuário quanto saídas do LLM contra conteúdo malicioso, discurso de ódio e vetores de ataque comuns de injeção de prompt.

Audit Trails: permitem rastrear o uso de IA generativa na sua org, garantindo conformidade com políticas de segurança, privacidade, regulação e governança de IA. Os dados de auditoria, junto com feedback, são armazenados no Data Cloud.

Camada 2: Controles de Acesso

Aqui está o conceito de segurança mais crítico para administradores entenderem. Agentes de IA no Salesforce operam como usuários na sua organização. As permissões que você concede a esses usuários determinam as ações que os agentes podem executar.

O Agentforce suporta dois modelos de interação distintos. Agentes de funcionários operam no contexto do usuário logado, respeitando automaticamente licenças, permission sets, segurança em nível de campo e regras de compartilhamento. Já os agentes de cliente — que interagem via canais públicos como Messaging ou Web Chat — operam como um Agent User dedicado, um Integration User especializado que permite ao agente executar ações e acessar dados de forma segura.

A melhor prática aqui é usar o Agent Creator para gerar um “New Agent User” que começa com acesso mínimo, e então conceder manualmente apenas as permissões específicas necessárias. Esse é o Princípio do Menor Privilégio aplicado a agentes autônomos, e ele não é opcional — é a diferença entre um agente que resolve problemas e um que cria incidentes de segurança.

Camada 3: Guardrails Administrativos

Beyond permissões de usuário, administradores têm controle direto sobre o comportamento e o escopo de cada agente através do Agent Builder e do Prompt Builder. Você pode restringir tópicos que o agente pode discutir, limitar ações a apenas Flows, classes Apex ou chamadas de API pré-aprovadas, configurar respostas de rejeição personalizadas para solicitações fora do escopo, e garantir que os agentes sejam grounded nos dados específicos do seu Salesforce.

Camada 4: Salesforce Shield e Security Center

Para organizações com necessidades avançadas de compliance, a segurança do Agentforce pode ser potencializada com produtos complementares. O Salesforce Shield oferece Event Monitoring, que registra ações granulares realizadas por usuários, agentes ou processos automatizados, além do Field Audit Trail, que cria um histórico detalhado de alterações nos dados. O Security Center 2.0 oferece uma visão holística da postura de segurança, compliance e governança em todos os seus orgs.

Implementando Governança na Prática: Um Exemplo em Apex

Uma das formas mais eficazes de governar o que um agente pode fazer é restringir as ações que ele executa a classes Apex específicas e pré-aprovadas. Em vez de dar ao agente acesso amplo a objetos, você encapsula a lógica de negócio em uma classe Apex que valida contexto, chega permissões e só então executa a operação. Veja um exemplo:

public with sharing class AgentOrderApprovalAction {

    // Invocável pelo Agentforce como uma Custom Action
    @InvocableMethod(label='Aprovar Pedido com Validação' description='Valida e aprova pedidos via agente')
    public static List<ApprovalResult> approveOrders(List<ApprovalRequest> requests) {
        List<ApprovalResult> results = new List<ApprovalResult>();

        for (ApprovalRequest req : requests) {
            ApprovalResult result = new ApprovalResult();

            // 1. Validar que o agente tem permissão para aprovar este pedido
            if (!canAgentApprove(req.orderId, req.agentUserId)) {
                result.success = false;
                result.message = 'Agente não tem permissão para aprovar este pedido';
                results.add(result);
                continue;
            }

            // 2. Verificar regras de negócio e compliance
            Order__c order = [
                SELECT Id, Status__c, Total_Amount__c, Customer__c, Region__c
                FROM Order__c
                WHERE Id = :req.orderId
                FOR UPDATE
            ];

            if (order.Status__c != 'Pending Approval') {
                result.success = false;
                result.message = 'Pedido não está em status de aprovação';
                results.add(result);
                continue;
            }

            // 3. Aplicar limite de aprovação baseado na região
            Decimal approvalLimit = getApprovalLimitForRegion(order.Region__c);
            if (order.Total_Amount__c > approvalLimit) {
                result.success = false;
                result.message = 'Valor excede o limite de aprovação automática para a região. Escalando para humano.';
                escalateToHuman(order.Id, req.agentUserId);
                results.add(result);
                continue;
            }

            // 4. Aprovar e registrar auditoria
            order.Status__c = 'Approved';
            order.Approved_By_Agent__c = req.agentUserId;
            order.Approval_Date__c = System.now();
            update order;

            // 5. Log de auditoria para governança
            logAgentAction(req.agentUserId, order.Id, 'ORDER_APPROVED', 
                'Pedido ' + order.Id + ' aprovado automaticamente. Valor: ' + order.Total_Amount__c);

            result.success = true;
            result.message = 'Pedido aprovado com sucesso';
            result.orderId = order.Id;
            results.add(result);
        }

        return results;
    }

    private static Boolean canAgentApprove(Id orderId, Id agentUserId) {
        // Verificar se o agente tem o permission set necessário
        return [
            SELECT COUNT()
            FROM PermissionSetAssignment
            WHERE AssigneeId = :agentUserId
            AND PermissionSet.Label = 'Agent_Order_Approver'
        ].size() > 0;
    }

    private static Decimal getApprovalLimitForRegion(String region) {
        Map<String, Decimal> limits = new Map<String, Decimal>{
            'North' => 50000,
            'South' => 75000,
            'East' => 60000,
            'West' => 100000
        };
        return limits.containsKey(region) ? limits.get(region) : 25000;
    }

    private static void escalateToHuman(Id orderId, Id agentUserId) {
        // Criar registro de fila de aprovação humana
        Agent_Escalation__c escalation = new Agent_Escalation__c(
            Order__c = orderId,
            Triggered_By_Agent__c = agentUserId,
            Reason__c = 'Valor excede limite automático',
            Status__c = 'Pending'
        );
        insert escalation;
    }

    private static void logAgentAction(Id agentUserId, Id recordId, String action, String details) {
        Agent_Audit_Log__c log = new Agent_Audit_Log__c(
            Agent_User__c = agentUserId,
            Record_Id__c = String.valueOf(recordId),
            Action_Type__c = action,
            Details__c = details,
            Timestamp__c = System.now()
        );
        insert log;
    }

    public class ApprovalRequest {
        @InvocableVariable(label='Order ID' required=true)
        public Id orderId;

        @InvocableVariable(label='Agent User ID' required=true)
        public Id agentUserId;
    }

    public class ApprovalResult {
        @InvocableVariable(label='Success')
        public Boolean success;

        @InvocableVariable(label='Message')
        public String message;

        @InvocableVariable(label='Order ID')
        public Id orderId;
    }
}

Observe o que esse padrão de implementação faz. O agente nunca toca diretamente no registro de pedido. Toda a lógica de validação, verificação de permissão, checagem de limites e auditoria acontece dentro de uma classe Apex que você controla completamente. Se o agente tentar aprovar um pedido acima do limite, a classe escala automaticamente para um humano e registra a tentativa. Se o agente não tiver o permission set correto, a operação é bloqueada antes mesmo de consultar o banco de dados.

Esse é o tipo de guardrail que separa uma implantação de Agentforce que funciona de uma que gera incidentes. E ele não vem habilitado por padrão — você precisa construí-lo.

Monitoramento Contínuo com LWC

Governança não termina na configuração. Ela requer monitoramento contínuo. Um componente LWC que exibe o painel de auditoria dos agentes pode dar visibilidade em tempo real para administradores e equipes de compliance. Veja um exemplo:

import { LightningElement, wire, track } from 'lwc';
import getAgentAuditLogs from '@salesforce/apex/AgentAuditController.getRecentLogs';
import { refreshApex } from '@salesforce/apex';
import { subscribe, unsubscribe, onError } from 'lightning/empApi';

const COLUMNS = [
    { label: 'Timestamp', fieldName: 'Timestamp__c', type: 'date', sortable: true },
    { label: 'Agente', fieldName: 'Agent_Name__c', type: 'text' },
    { label: 'Ação', fieldName: 'Action_Type__c', type: 'text' },
    { label: 'Registro', fieldName: 'Record_Id__c', type: 'text' },
    { label: 'Detalhes', fieldName: 'Details__c', type: 'text', wrapText: true },
    { label: 'Status', fieldName: 'Status__c', type: 'text',
      cellAttributes: { class: { fieldName: 'statusClass' } } }
];

export default class AgentAuditDashboard extends LightningElement {
    @track logs = [];
    @track columns = COLUMNS;
    @track isLoading = true;
    @track error;
    wiredLogsResult;
    channelName = '/event/Agent_Audit_Event__e';
    subscription = {};

    @wire(getAgentAuditLogs, { limitSize: 50 })
    wiredLogs(result) {
        this.wiredLogsResult = result;
        if (result.data) {
            this.logs = result.data.map(log => ({
                ...log,
                statusClass: log.Status__c === 'Success'
                    ? 'slds-text-color_success'
                    : log.Status__c === 'Blocked'
                        ? 'slds-text-color_error'
                        : 'slds-text-color_warning'
            }));
            this.isLoading = false;
        } else if (result.error) {
            this.error = result.error.body.message;
            this.isLoading = false;
        }
    }

    connectedCallback() {
        // Inscrever para eventos de auditoria em tempo real via Platform Events
        subscribe(this.channelName, -1, (event) => {
            this.handleAuditEvent(event);
        }).then(response => {
            this.subscription = response;
        });
        onError(error => {
            console.error('Erro na inscrição EMP API:', error);
        });
    }

    handleAuditEvent(event) {
        // Quando um evento de auditoria chega, atualiza a lista
        return refreshApex(this.wiredLogsResult);
    }

    handleRefresh() {
        return refreshApex(this.wiredLogsResult);
    }

    disconnectedCallback() {
        unsubscribe(this.subscription);
    }
}

Esse componente se conecta a um controller Apex que retorna os logs recentes de auditoria dos agentes, e também se inscreve em Platform Events para receber atualizações em tempo real. Quando um agente executa uma ação, dispara um evento, e o painel atualiza automaticamente. Administradores podem ver imediatamente quais agentes estão ativos, que ações estão executando, e se alguma foi bloqueada.

O Caminho para uma Governança Eficaz

Com base no modelo de responsabilidade compartilhada da Salesforce e nas práticas que vemos em implantações bem-sucedidas, existem cinco passos que qualquer organização trabalhando com Agentforce deveria seguir:

Primeiro: implemente o Princípio do Menor Privilégio em todos os usuários de agente. Comece com permissões mínimas e adicione apenas o estritamente necessário. Cada permissão adicional é uma superfície de ataque adicional.

Segundo: configure corretamente Profiles, Permission Sets e Field Level Security. Um agente que tem acesso a campos de CPF ou dados financeiros sensíveis quando não precisa deles é um risco de compliance esperando para acontecer.

Terceiro: construa guardrails de agente desde o início. Restrinja tópicos, limite ações a Flows e classes Apex pré-aprovados, e configure respostas de rejeição para solicitações fora do escopo. O Agent Builder é sua primeira linha de defesa.

Quarto: monitore e audite regularmente a atividade de agentes e usuários. Habilite Enhanced Event Logs, configure alertas para comportamentos anômalos, e revise os relatórios de auditoria do Einstein Trust Layer periodicamente.

Quinto: garanta que os dados no Data Cloud estejam limpos, precisos e seguros. Use AI tagging e classificação para marcar dados sensíveis como HIPAA, GDPR ou PII. Configure políticas de governança baseadas em regras que se aplicam automaticamente em todo o Data Cloud. Um agente grounded em dados incorretos ou desatualizados vai tomar decisões incorretas, por mais sofisticado que seja o modelo por trás dele.

Por Que Isso Importa Agora

Os números do fiscal 2026 da Salesforce mostram que a adoção de Agentforce não é mais um experimento. São 29.000 deals fechados, bilhões de unidades de trabalho executadas, e mais de 60% dos bookings de Agentforce no quarto trimestre vieram de expansão de clientes existentes. Isso significa que empresas que já usavam Salesforce estão apostando mais fundo em agentes de IA.

Mas o Connectivity Report revela que o problema não é a tecnologia — é a preparação. Quando 42% das organizações citam gestão de risco e compliance como o principal desafio de implantação, e 96% enfrentam barreiras para usar dados com IA, fica claro que a maioria das empresas está tentando construir a casa sem ter preparado o terreno.

O caso da Safari365 é ilustrativo. A operadora de turismo com 35 funcionários alcançou 62% de resolução de casos com Agentforce, mas a limpeza de dados necessária antes da implantação levou mais tempo do que o deploy do agente em si. Esse detalhe é mais revelador do que a taxa de resolução. Diz exatamente onde o trabalho pesado acontece.

A Salesforce guiou receita de US$ 45,8 a US$ 46,2 bilhões para o ano fiscal 2027, com expectativa de re-aceleração do crescimento orgânico no segundo semestre. O caminho até lá depende de quanto as empresas conseguirão transformar deals em implantações que geram valor real — e isso passa diretamente pela governança.

Conclusão

Agentforce atingiu US$ 800 milhões em ARR porque resolve problemas reais. Os cases de Williams-Sonoma, IRS e Kyle provam isso. Mas a próxima fase de crescimento da plataforma não será definida por quantos agentes as empresas podem implantar, e sim por quão bem governados esses agentes são. Metade dos agentes operando em silos não é um problema técnico — é um problema de governança que exige arquitetura deliberada, processos de revisão contínuos, e uma cultura de segurança que trata dados e guardrails como precondição, não como afterthought.

Se você está em um time que está começando ou expandindo sua jornada com Agentforce, a pergunta não deveria ser “quantos agentes vamos implantar neste trimestre?”. Deveria ser “nossa fundação de dados, nossas permissões e nossos guardrails estão prontos para os agentes que já temos?”. A resposta para essa pergunta é o que separa as empresas que vão extrair valor real de Agentforce das que vão gerar mais complexidade do que resultados.

Revise suas configurações de segurança hoje. Audite os usuários de agente que você já tem. Verifique se o Einstein Trust Layer está ativo e configurado. E construa os guardrails antes de precisar deles — porque quando precisar, já será tarde.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *