Para empresas que querem crescer com controle

Um sistema para operar sua empresa com IA.

Vendas, marketing, atendimento, operação, financeiro e inteligência trabalhando sobre o mesmo contexto — para sua empresa ganhar escala sem perder controle.

Sua empresa inteira. Uma operação. IA trabalhando.

Ver a Centriu funcionando

Para empresas de qualquer setor que querem crescer com estrutura, controle e inteligência.

Representação ilustrativa do trabalho em execução

O problema

Sua empresa não deveria operar em pedaços

Não é falta de ferramenta. É que cada ferramenta resolve um pedaço, e ninguém é dono do todo. O custo disso não aparece numa fatura — aparece no mês seguinte.

Sistemas que não se falam
O mesmo dado é digitado de novo — e cada cópia conta uma história diferente.
Dados duplicados
Ninguém sabe qual versão é a verdadeira na hora de decidir.
Conversas perdidas
O cliente repete o contexto a cada canal e a cada pessoa.
Tarefas espalhadas
O trabalho vive em planilhas, mensagens e na memória de alguém.
Decisões sem contexto
A escolha é feita com o recorte que estava à mão, não com o que importava.
Automações desconectadas
Cada ferramenta automatiza um pedaço e ninguém enxerga o todo.

Nenhum desses problemas se resolve comprando mais um software. Eles se resolvem quando a operação inteira passa a trabalhar sobre o mesmo contexto.

A resposta

Tudo trabalha sobre o mesmo contexto.

A Centriu não é uma coleção de produtos. É uma plataforma em que clientes, áreas e agentes leem e escrevem no mesmo lugar.

Cliente 360

Um contexto, não vários cadastros

Cada conversa, tarefa, campanha, cobrança e decisão fica ligada ao cliente e à operação — não a um sistema isolado.

Clientes
Comercial
Atendimento
Operação
Financeiro
Marketing
Inteligência
Agentes
Consultoria

As áreas abaixo são partes da mesma operação, não produtos separados. Elas compartilham conta, permissões e histórico.

IA que trabalha — não um chatbot ao lado

A inteligência artificial da Centriu participa da operação: entende contexto, prepara trabalho, executa rotinas e pede aprovação quando importa.

Entende o contexto

Lê a operação, o cliente e o histórico antes de propor qualquer coisa.

Prepara o trabalho

Redige, organiza, calcula e deixa pronto para revisão humana.

Executa rotinas

Roda o que é repetitivo dentro dos limites definidos pela empresa.

Recomenda a próxima ação

Cruza áreas, identifica prioridade e mostra o motivo da recomendação.

Pede aprovação

O que é sensível passa por uma pessoa antes de valer. Sem exceção silenciosa.

Mantém histórico e aprende

Registra o que aconteceu e usa o resultado para melhorar a próxima decisão.

O que a Centriu faz

Uma plataforma, várias frentes de trabalho. Tudo no mesmo contexto, com a IA participando do que dá para acelerar.

Comercial

CRM, pipeline, oportunidades, propostas, follow-up e automações.

Atendimento

WhatsApp, Instagram, Messenger, chat do site e e-mail no mesmo contexto.

Operação

Tarefas, responsáveis, prazos, aprovações, agenda e capacidade.

Financeiro

Contas, cobranças, caixa, fiscal, margem, IR, orçamento e inteligência econômica.

Marketing

Planejar, produzir, aprovar, publicar e medir conteúdo e campanhas.

Inteligência

Painéis, alertas, previsões, recomendações e leitura executiva.

Agentes

Rotinas executadas continuamente pela IA com controle e aprovação.

Consultoria

Diagnóstico, estratégia, transformação, acompanhamento e especialistas.

Para quem é

Para empresas que querem crescer — e crescer certo.

A Centriu faz sentido quando o volume aumenta e a estrutura precisa acompanhar. Não é sobre setor nem tamanho: é sobre a operação conseguir sustentar o próximo estágio.

As vendas crescem, mas o processo não acompanha.

As áreas trabalham separadas e o cliente sente.

A operação depende de pessoas específicas.

O financeiro ficou complexo e o caixa perde visibilidade.

O atendimento cresce em volume e em canais.

A IA entra sem contexto, controle ou histórico.

Se a empresa ainda não começou a crescer, a Centriu também ajuda a preparar a estrutura para o primeiro salto.

Ver a Centriu funcionando

Consultoria

Tecnologia sozinha não resolve uma operação mal desenhada.

A Centriu combina tecnologia, inteligência, método e acompanhamento. A consultoria diagnostica, desenha, implanta e acompanha — com evidências, não com apresentação.

Diagnóstico e imersão na operação

Estratégia e prioridades

Roadmap de transformação

Desenho da arquitetura operacional

Implantação conduzida

Acompanhamento com evidências

Benchmarking e leitura de mercado

Especialistas, rede e inteligência coletiva

A participação de especialistas depende da solução e do contrato. Não é um item incluído automaticamente em toda contratação, e não prometemos acompanhamento humano ilimitado.

Veja a Centriu funcionando na sua operação

Uma conversa para entender onde a sua operação perde tempo, dinheiro ou capacidade — e o que a Centriu faria primeiro.

Ver a Centriu funcionando

problema

OAuth Token Encryption-at-Rest Automation: A Column Privilege That Was Silently Ignored

When Centriu Maestro connects to Meta, Google, LinkedIn, or Google Business Profile on a client's behalf, the OAuth access and refresh tokens it receives get stored. This keeps the connection working. It avoids asking the person to reconnect every time. A security check on the production database was run. It used a real user's own session. It found those tokens stored in plain text and readable directly. A single `SELECT` returned four live, 350-character access tokens. These were from the organization's real ad-platform connections. The application's own screen had always been careful. It requested only the non-sensitive columns. But that was a convention the interface chose to follow. It was not a control the database enforced. Anyone with a valid session, a browser console, or a successful cross-site-scripting attempt could have called the database directly. They could have read the credentials that spend real advertising money. The fix has two independent layers. The database privilege itself was corrected. Now, no session can read the token columns at all. There was a specific finding along the way. Revoking access to just the token column did nothing. This was because a broader table-level grant silently took precedence. Also, every stored token is now encrypted with AES-256-GCM. It uses a key kept outside the database entirely. So, even someone with a raw database backup or replica cannot read a token. They would also need the separate encryption key.

Quero resolver isso

A screen that only asks for the columns it needs is not the same as a database that only allows them

A well-written application screen requests exactly the data fields it displays and nothing more. It is good practice. It genuinely limits what a normal user of that screen ever sees. What it does not do is limit what the database itself will hand over. This applies to anyone with a valid connection who asks for something different. A database privilege and an application's own restraint are two entirely separate mechanisms. Only one of them holds up against a request that does not come from the application's own well-behaved screen. This includes a browser's developer console, a compromised script, or anyone who simply calls the same API the screen uses, but asks for a different column.

A well-written application screen requests exactly the data fields it displays and nothing more. It is good practice. It genuinely limits what a normal user of that screen ever sees. What it does not do is limit what the database itself will hand over. This applies to anyone with a valid connection who asks for something different. A database privilege and an application's own restraint are two entirely separate mechanisms. Only one of them holds up against a request that does not come from the application's own well-behaved screen. This includes a browser's developer console, a compromised script, or anyone who simply calls the same API the screen uses, but asks for a different column.

Quero resolver isso

How Centriu Maestro closed both the read path and the raw-data path

The gap was found by directly probing the production database. It used a real, ordinary user's own session. This was not a hypothetical scenario. The result was clear. A plain `SELECT` against the table storing platform connections returned four live, 350-character OAuth access tokens. These were from the organization's real ad-platform integrations (Meta, Google, LinkedIn, Google Business Profile). The application's own service layer had always requested only the safe, non-sensitive columns. But that discipline lived entirely in application code. Any other caller with the same session privileges could simply ignore it.

The first fix corrected the actual database privilege. Its own account of the process includes a specific detail. This detail is worth taking seriously. The team's first attempt was to revoke read access to just the token columns. They left the broader table-level read grant in place. When measured directly, that column-level revoke had zero effect. The role still read all four tokens. This was because a table-level grant is checked first. A column-level restriction is only consulted when no such broader grant exists. The working fix reverses the order. The table-level grant is revoked entirely. Read access is re-granted column by column. It explicitly excludes the two token columns. Write access follows the same principle. It is narrowed to only the specific columns the application's screen genuinely needs to update. Inserting and deleting a connection record now happens exclusively through a backend service role. It never happens through a user's own session privileges. Disconnecting an integration needs to clear the token columns. This was moved into a narrowly scoped database function. This means a user's own session never needs write privilege over a secret column at all.

The second fix addresses a different threat. The first one cannot. This threat is anyone who obtains a raw copy of the underlying data. This could be a database backup, a replica, or access through the database platform's own management interface. This bypasses ordinary access-control privileges entirely. This is because those privileges only govern connections through the normal query interface. To close that gap, every stored token is now encrypted with AES-256-GCM before it is written. It uses a 32-byte key kept specifically outside the database itself. This key is accessible only through a tightly scoped internal function. This function is restricted to the backend's own service identity. It was confirmed directly that neither an ordinary authenticated session nor an anonymous one can reach the function that resolves the encryption key. The stored format carries an explicit version marker. This is specifically to support a gradual, reversible migration. A token stored under the old, unmarked format is recognized as legacy plain text. It is returned as-is. Every newly written or re-encrypted token carries the marker. It also has the tooling needed to decrypt it. Critically, if the encryption key is ever unavailable for any reason, the encryption function fails loudly. It does not silently fall back to writing the token in plain text. An absence of configuration is treated as a hard failure. This is specifically so the protection can never quietly turn itself off.

The fix's own end-to-end verification was performed directly against the production environment. It is worth stating plainly. An ordinary user session attempting to select a token column now receives an explicit access-denied response. The application's own screen continues reading its real connections normally. The live backend service can still decrypt a real token. It can successfully call the ad platform's own API in a read-only way. This confirms the credential still works. Every one of the organization's existing real tokens was confirmed migrated to the encrypted format. Zero were left in plain text.

Ver como funciona

What is actually built today

Table-level read access to the connections table is fully revoked for ordinary user sessions. It is replaced with an explicit, column-by-column grant. This grant excludes both token columns entirely.
Write access is narrowed to exactly the columns the application's own screen updates. Creating and deleting a connection record now requires the backend's own service identity. It never requires a user's own session.
A dedicated, narrowly scoped database function is used for disconnecting an integration. So, clearing a token no longer requires giving a user session any write privilege over a secret column.
Every stored token is encrypted at rest with AES-256-GCM. It uses a key resolvable only through a tightly restricted internal path. This path is confirmed unreachable by both ordinary authenticated and anonymous sessions.
An explicit version marker is on every encrypted value. This supports a gradual, reversible migration. An unmarked value is recognized as legacy plain text. It does not cause an error.
A hard failure occurs, rather than a silent fallback to plain text. This happens whenever the encryption key is genuinely unavailable. It is confirmed the encryption path cannot quietly disable itself.

Conhecer os recursos

What changes operationally

A credential that spends real advertising money on a client's behalf is no longer reachable through an ordinary user session. This is true under any circumstance. Even someone with a raw copy of the underlying database cannot read it. They would also need a separate, narrowly held encryption key. The protection holds regardless of which specific application code path is used to reach the database. It is enforced by the database itself. It is not enforced by any particular screen's discipline.

A credential that spends real advertising money on a client's behalf is no longer reachable through an ordinary user session. This is true under any circumstance. Even someone with a raw copy of the underlying database cannot read it. They would also need a separate, narrowly held encryption key. The protection holds regardless of which specific application code path is used to reach the database. It is enforced by the database itself. It is not enforced by any particular screen's discipline.

Quero esses resultados

The same request, a different answer (illustrative scenario, not a real client)

Someone with a valid, ordinary session opens their browser's developer console. They issue a direct request for the token columns on their organization's own ad-platform connection. This is exactly the kind of request an XSS attempt or a curious extension might make. Before the fix, that request returned the real, usable access token. After the fix, the same request is refused outright by the database itself. This is true regardless of what the requesting application intended to ask for.

Conversar sobre meu caso

How to get started

Começar agora

Frequently asked questions

Could a real user session actually read another person's ad-platform token before this fix?

The finding was more direct than that. An ordinary session could read the token columns on the table at all. This was confirmed by a real `SELECT` returning four live, usable access tokens.

Why didn't revoking access to just the token column fix the problem?

A broader, table-level read grant for the same role was still in place. That broader grant is checked first. The column-level restriction had measurably zero effect. This was true until the table-level grant was also removed.

Does encryption at rest replace the need for access-control privileges, or the other way around?

Neither replaces the other. Access control stops an ordinary session from reading a column through the normal query interface. Encryption at rest protects the same data from anyone who obtains a raw copy of the database itself. Access-control rules do not apply there.

What happens if the encryption key becomes unavailable?

The encryption operation fails loudly. It does not silently write the token in plain text. An absence of the key is treated as a hard failure. It is not a fallback to the insecure state.

Were any of the organization's existing tokens left unencrypted after the fix?

No. The fix's own verification confirmed every existing real token was migrated to the encrypted format. Zero were left in plain text.

What does Centriu Maestro cost?

It is sold by subscription with a published starting price. Exact current values are on the central pricing page.

Ainda tenho dúvida

See how Centriu Maestro protects ad-platform credentials

Quero resolver isso