Segurança na Pleaxy

A Pleaxy roda na Amazon Web Services, na região US East (N. Virginia). O backend é serverless - Amazon API Gateway, AWS Lambda e Amazon DynamoDB - e o aplicativo e este site são servidos a partir do Amazon S3 por meio do Amazon CloudFront.

Toda requisição está sujeita a um limite de requisições aplicado a toda a API, e os feeds de faturas e o assistente do aplicativo têm os seus próprios limites por chave e diários, para conter abusos.

• As contas são gerenciadas pelo Amazon Cognito. O login usa o protocolo Secure Remote Password, então a sua senha nunca é enviada aos servidores da Pleaxy nem armazenada por eles.
• Os endereços de e-mail são verificados no cadastro, e as senhas devem ter pelo menos 8 caracteres, com letras maiúsculas, letras minúsculas e um número.
• Qualquer usuário pode ativar a verificação em duas etapas com um aplicativo autenticador. Ela é opcional, não obrigatória, e não oferecemos códigos por SMS.
• Qualquer usuário pode adicionar uma chave de acesso (passkey) e entrar com o rosto, a impressão digital ou o PIN do dispositivo. Uma chave de acesso só funciona no próprio site da Pleaxy, então um site falso parecido não consegue usá-la. A sua senha continua funcionando junto com ela.
• No plano Enterprise, uma empresa pode configurar o login único com o seu próprio provedor de identidade: Okta, Microsoft Entra ID ou qualquer provedor SAML 2.0 ou OpenID Connect. Os administradores verificam primeiro o domínio de e-mail da empresa, podem exigir o login único de todos que o usam e mantêm administradores de acesso de emergência que ainda conseguem entrar com senha.
• O token de acesso de cada requisição à API é verificado criptograficamente, e a sua participação no espaço de trabalho é verificada novamente a cada requisição - assim, quando um administrador remove alguém, essa pessoa perde o acesso ao espaço de trabalho já na requisição seguinte, e não quando o token expira.
• As chaves de API também são revogadas automaticamente: quando um administrador remove alguém, ou muda a função dessa pessoa de Administrador para outra função, todas as chaves de API que ela criou no espaço de trabalho são revogadas como parte da mesma alteração, e o administrador que faz a alteração é informado de quais chaves foram revogadas.

Cada empresa trabalha no seu próprio espaço de trabalho. Cada registro é armazenado sob a chave do seu espaço de trabalho, e cada requisição é verificada no servidor em relação à participação de quem a faz no espaço de trabalho antes que qualquer dado seja lido ou gravado. Duas coisas são compartilhadas por definição: pedidos de compra e faturas ficam visíveis para as duas partes da transação, e compradores que convidam fornecedores podem encontrar perfis de fornecedores verificados (nome da empresa, e-mail de contato e os nomes dos espaços de trabalho em que o fornecedor está ativo).

Os espaços de trabalho de comprador têm seis funções de compras - Administrador, Somente leitura, Contratos e fornecedores, Relacionamentos, Requisições e Financeiro -, cada uma das quais concede a cada módulo nenhum acesso, acesso de visualização, de criação ou de edição. As permissões são aplicadas pela API, e não apenas ocultadas na interface. Os espaços de trabalho de fornecedor usam um modelo mais simples, de administrador e membro.

• Cada etapa de aprovação é atribuída a uma pessoa específica, e somente essa pessoa pode aprová-la ou rejeitá-la. Uma etapa sem responsável aguarda até que um administrador atribua alguém.
• Uma chave de API nunca pode aprovar nem rejeitar uma etapa de aprovação. Ela também não pode alterar cadeias de aprovação, regras de automação, valores-limite de aprovação automática ou limites de gastos - só uma pessoa conectada pode. Uma integração pode emitir pedidos de compra e faturas, mas se eles precisam de um aprovador humano é algo decidido apenas pelas regras que a sua equipe define.
• Pedidos de compra e faturas ainda podem ser aprovados automaticamente se os seus administradores ativarem regras de automação, ou se administradores ou usuários do Financeiro definirem um valor-limite de aprovação automática. Essas aprovações são registradas como automáticas.
• Toda aprovação, rejeição, reatribuição ou etapa pulada fica no histórico de aprovações do documento, com quem (ou qual automação) a realizou e quando.
• Um solicitante só pode aprovar a própria solicitação quando é o único aprovador elegível, e isso é registrado como autoaprovação. Uma empresa não pode emitir pedidos de compra ou faturas para si mesma.

• Uma fatura que um comprador lança para um fornecedor, a partir de um PDF recebido por e-mail, uma digitalização ou uma cópia em papel, traz dados bancários que não vieram do fornecedor. Ela fica retida até o fornecedor confirmá-la na Pleaxy, ou um usuário do comprador que não a lançou confirmar os dados bancários com o fornecedor por telefone. Até lá, ela não pode ser aprovada, paga nem exportada para pagamento.
• Um fornecedor pode informar que uma fatura não é dele ou que não traz os dados bancários dele. Uma fatura assim fica retida de vez.
• Quando uma fatura enviada pela própria conta de um fornecedor traz dados bancários diferentes dos da última fatura dele para aquele comprador, cada administrador do fornecedor é avisado na Pleaxy e por e-mail. O e-mail mostra só a forma de pagamento, o banco e os quatro últimos caracteres da conta, nunca o número completo.
• A partir desse aviso, um administrador do fornecedor pode bloquear em um só passo a conta de onde a fatura veio: ela é desconectada de todos os dispositivos, as chaves de API que criou são revogadas e a fatura é comunicada ao comprador. Quando uma chave de API enviou a fatura, só essa chave é revogada. Cada bloqueio fica registrado.
• Os dados bancários de uma fatura que ninguém confirmou nunca servem de referência para comparar a próxima.

• As chaves de API são geradas a partir de 32 bytes aleatórios e exibidas uma única vez. Armazenamos apenas um hash com chave (HMAC-SHA256), nunca a própria chave, e fazemos a comparação em tempo constante.
• Cada chave pertence a um espaço de trabalho e a uma função - as chaves de fornecedor também têm escopos explícitos - e pode ser revogada a qualquer momento. Só um administrador conectado pode criar ou revogar chaves; uma chave não pode gerar outra chave. As chaves de uma pessoa são revogadas automaticamente quando ela é removida do espaço de trabalho ou deixa de ser administradora, e incluí-la novamente não restaura uma chave revogada.
• O servidor MCP da Pleaxy, que permite que agentes de IA chamem a Pleaxy, usa a mesma API e a mesma chave com escopo. Ele não recebe nenhum privilégio adicional.

• Em trânsito: somente HTTPS. O HTTP simples é redirecionado, o armazenamento recusa conexões não criptografadas, e os navegadores são instruídos a usar HTTPS em todas as visitas (HSTS), junto com os cabeçalhos de segurança padrão da AWS.
• Em repouso: bancos de dados, armazenamento de arquivos, filas e segredos são todos criptografados com chaves gerenciadas pela AWS.

Os segredos da aplicação ficam no AWS Secrets Manager e no Systems Manager Parameter Store - nunca no código-fonte nem na configuração de implantação.

Toda conexão de faturamento de nuvem é somente leitura, criada na sua própria conta e revogável no seu próprio console. Nunca pedimos as suas senhas ou chaves de acesso de nuvem. Na AWS, você cria uma função de faturamento com um External ID exclusivo da conexão, e a Pleaxy assume essa função. O Google Cloud e o Microsoft Azure usam login federado, então nenhum segredo é armazenado. Para a Oracle Cloud Infrastructure (OCI), a Pleaxy gera uma chave de assinatura de API para a conexão e você envia apenas a chave pública; a chave privada é armazenada apenas criptografada com o AWS KMS, e excluir a chave na Oracle revoga o acesso. Os dados de faturamento já importados permanecem no seu espaço de trabalho até serem excluídos.

Os provedores de IA que você conecta diretamente (OpenAI, Anthropic, Mistral, OpenRouter, Databricks, CoreWeave e Snowflake) usam uma chave que você cria no console deles. O Pleaxy a verifica com uma leitura antes de salvá-la, usa-a apenas para ler uso e custos e a guarda somente criptografada com o AWS KMS, vinculada àquela conexão; depois disso, só os quatro últimos caracteres aparecem. Para o Snowflake, o Pleaxy gera um par de chaves e você atribui apenas a chave pública a um usuário de serviço. Desconectar apaga a chave na hora, e revogá-la no console do provedor também corta o acesso; o uso de IA já importado fica como histórico.

Limites de gastos em um provedor são opcionais e usam uma credencial separada que você cria só para isso, nunca a da conexão somente leitura: uma função da AWS restrita a orçamentos, uma conta de serviço do Google Cloud ou um app do Azure federados como a conexão, ou outra chave de administrador da OpenAI ou da Anthropic, criptografada do mesmo jeito. O Pleaxy a verifica antes de salvá-la, e você pode removê-la quando quiser.

Formulários fiscais, certificados de seguro e cartas bancárias são mantidos em um bucket de armazenamento privado e só podem ser acessados por links assinados de curta duração. Excluir um documento apaga todas as versões armazenadas dele.

• O assistente do aplicativo roda no Claude, da Anthropic, por meio do Amazon Bedrock, chamado a partir da nossa própria conta AWS na região US East.
• A Pleaxy não mantém transcrições de chat. Uma ação proposta pelo assistente fica retida por pouco tempo para que você possa confirmá-la.
• O assistente age como o usuário conectado, exatamente com as permissões dele. Aprovações, pagamentos registrados, resoluções de divergências e alterações de regras de automação são apenas propostos - uma pessoa confirma cada um com um botão. O assistente também pode rejeitar um documento, criar um pedido de compra, transformá-lo em fatura, executar novamente a conciliação de faturas ou enviar um lembrete sem uma etapa de confirmação separada - ele é instruído a fazer isso somente quando você pede, então revise o que ele diz que vai fazer.

• Uma trilha de auditoria do AWS CloudTrail, abrangendo toda a conta, registra cada chamada às APIs de gerenciamento da AWS, com validação de integridade dos arquivos de log, mantida por 365 dias em um bucket cuja política impede a exclusão. Alterações na trilha ou nessa política geram um alerta.
• Alarmes automáticos monitoram erros e latência da API, tarefas com falha e sincronizações de faturamento com falha, com um canal separado para alertas de segurança.
• Os bancos de dados de produção têm recuperação pontual (point-in-time recovery) e proteção contra exclusão, e o armazenamento de documentos tem controle de versões.
• Os logs de acesso à API são mantidos por 30 dias, e os logs de aplicação, por 90 dias.

Se você acredita ter encontrado um problema de segurança na Pleaxy, envie os detalhes por e-mail para support@pleaxy.ai. Pedimos que nos dê uma oportunidade razoável de corrigi-lo antes de divulgá-lo publicamente.

O GDPR é uma lei, não um certificado, e desenvolvemos a Pleaxy para cumpri-la. Para os dados que você insere no seu espaço de trabalho - funcionários, fornecedores, pedidos de compra, faturas e documentos -, você é o controlador e a Pleaxy é o seu operador, agindo apenas conforme as suas instruções. Para os dados de conta, de cobrança e do site, a Pleaxy é o controlador.

• Acordo de Tratamento de Dados: envie-nos um e-mail se precisar de um. Ele abrange a nossa lista de suboperadores, as medidas de segurança desta página e as cláusulas de transferência abaixo.
• Onde os dados ficam: nos Estados Unidos (AWS US East). As transferências de dados pessoais da UE e do Reino Unido são cobertas pelas Cláusulas Contratuais Padrão da UE e pelo Adendo do Reino Unido no nosso DPA.
• Seus direitos: solicitações de acesso, correção e exclusão são atendidas mediante pedido - veja a nossa Política de privacidade.

Não vendemos informações pessoais nem as “compartilhamos” para publicidade comportamental entre contextos, conforme a lei da Califórnia define esses termos, e o site da Pleaxy não usa rastreadores de publicidade ou de análise.

A Pleaxy nunca manipula os dados do seu cartão. Os pagamentos de assinaturas são processados nas páginas hospedadas pela Stripe, e a Stripe é um prestador de serviços PCI DSS Nível 1.