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

Public Trust Center Admin-Authorization Automation: The Gate That Wasn't in the Screen — Or the Database

Centriu Axiom's Trust Center publishes an organization's privacy policy, terms, and subprocessor list to the public. This is the page a prospect or auditor reads to decide whether to trust the company. A special admin screen lets someone create, edit, and delete those published documents. An internal audit found that the screen had no role check of any kind. More seriously, neither did the database. The access rule for both the documents table and the subprocessor table only checked which organization a row belonged to. It never checked which role the user had inside it. Any logged-in member of the organization could open the admin screen. This includes an account executive, a salesperson, or a project manager. They could rewrite the exact privacy policy a customer had already seen publicly. They could also add or remove a subprocessor from the list. The fix adds two layers on purpose. One is a UI gate that shows a restricted-access message to anyone who is not an owner or admin. The other is a database change that actually matters. It requires a real `axiom_user_is_admin()` check on every insert, update, and delete for both tables. This means the restriction holds even if someone bypassed the interface entirely. It also holds if they called the write API directly with their own valid session token.

Quero resolver isso

A screen that checks who can click a button governs less than it looks like it does

A settings page that only shows a "Save" button to the right people creates a strong, correct-looking impression of access control. Nobody who shouldn't be able to make the change can see how to trigger it from the interface. What that impression leaves out entirely is that a web application's interface and its actual data layer are two separate things. Only one of them is impossible to route around. Anyone who already has a valid, logged-in session can, in principle, call the exact same write endpoint the hidden button would have called. They can do this without ever loading the screen that hid it. A role check that lives only in what the screen displays is a restriction on the path most people will take. It is not a restriction on what the system will actually accept. For a screen whose entire purpose is publishing something to the public, that distinction is the whole ballgame.

A settings page that only shows a "Save" button to the right people creates a strong, correct-looking impression of access control. Nobody who shouldn't be able to make the change can see how to trigger it from the interface. What that impression leaves out entirely is that a web application's interface and its actual data layer are two separate things. Only one of them is impossible to route around. Anyone who already has a valid, logged-in session can, in principle, call the exact same write endpoint the hidden button would have called. They can do this without ever loading the screen that hid it. A role check that lives only in what the screen displays is a restriction on the path most people will take. It is not a restriction on what the system will actually accept. For a screen whose entire purpose is publishing something to the public, that distinction is the whole ballgame.

Quero resolver isso

How Centriu Axiom closed the gap on both the screen and the database that actually enforces it

The gap surfaced as part of the same internal audit. This audit rewrote Axiom's proof-of-action mechanism. It also connected its safety scanner to the real AI path. Both are covered on this pillar's companion pages. This showed a recurring pattern of a control that looked complete but was not fully connected. For the Trust Center admin screen specifically, the finding was direct. The screen itself performed zero role checks. The row-level security policies backing both `axiom_trust_documents` and `axiom_subprocessors` were a single `ALL`-scoped rule each. They restricted access only to rows belonging to the caller's own organization. There was no further restriction on which member of that organization could write.

Before writing any code for the fix, the audit checked the blast radius directly against production. This was read-only. Both tables held zero rows at the time. This meant tightening the policy could not corrupt or orphan any existing data. It then checked exactly who would be affected by the change. Two platform masters and 14 organization admins across the live data would keep write access as before. Ten staff-level members would lose a write ability they should never have had. Nobody with a real need to publish or edit a Trust Center document loses access because of this fix.

The fix itself is made of two separate, working-together pieces. It is not just one piece. The database change adds a new function, `axiom_user_is_admin()`. This function returns true only for a platform master. It also returns true for a member whose role in the organization currently active for that request is admin, administrador, or master. This respects the same org-switcher logic the rest of the app already uses. This is a direct, role-for-role mirror of the exact `mapUserRole` function the application's own UI already uses to decide what to show. That mirroring is on purpose. If the UI's idea of "admin" and the database's idea of "admin" were two separate definitions, they could change over time. They could quietly disagree about who is actually allowed to write. The interface might offer a button the database would refuse. Or, worse, the database might silently accept a write the interface should never have allowed. The change replaces each table's single organization-scoped policy with four narrower ones. Read access stays open to the whole organization. The Trust Center itself needs every member to be able to see what has already been published. Insert, update, and delete each now also require `axiom_user_is_admin()` to return true. The update policy specifically carries the same admin check in both its `USING` clause. This clause checks which existing rows can be touched. It also carries the check in its `WITH CHECK` clause. This clause checks what the row is allowed to look like after the edit. The second check exists specifically to close a more subtle gap. Without it, an admin editing a row could move it to a different organization entirely. This could happen as a side effect of the update. This is because `USING` alone only controls which rows can be chosen for editing. It does not control what the edited result is allowed to contain.

The screen-level part of the fix adds a real role check to `TrustCenterAdmin.tsx` itself. While the current user's role is still loading, the page shows a loading state. It does not show anything else. Once the role is known, anyone who is not an owner or admin sees a plain, honest restricted-access message. This message directs them back to the read-only Trust Center. They do not see the admin interface. The page's own code comment is clear about what this part actually is and isn't. A screen-level gate alone would be decoration. Anyone who wanted to write anyway could still call the underlying API directly with their own valid token. The database change is described in that same comment as "the half that matters." It is confirmed directly in the current source. Both the UI check and the database function remain in place today. They are unmodified since the fix.

Ver como funciona

What is actually built today

A database function, `axiom_user_is_admin()`, mirrors the application's own role-mapping logic exactly. This means a platform master or an org-level admin, administrador, or master role. It is checked against the organization currently active for the request.
Insert, update, and delete on both `axiom_trust_documents` and `axiom_subprocessors` now require that function to return true. This is enforced by the database itself. It is not only by what the interface displays.
A `WITH CHECK` clause on the update policy specifically prevents a row from being moved into a different organization. This could happen as a side effect of an otherwise-allowed edit.
Read access to both tables remains open to every member of the organization. It is unchanged. The fix is only for writes.
A UI-level gate on the admin screen itself shows a restricted-access message to anyone who is not an owner or admin. This is clearly written in the code as the half that alone would not be enough.
It was checked before deployment against live production data. Zero existing rows were affected. Every legitimate admin's access was kept. Only the staff-level members who should never have had write access are the ones who lose it.

Conhecer os recursos

What changes operationally

A document that is shown to the public as an organization's official privacy policy or subprocessor list can now only be created, changed, or removed by someone the database itself recognizes. This person must be an owner or administrator of that organization. This is not merely based on the interface. The restriction works even if called from a different client, a different screen, or no screen at all. This is because it lives in the one layer that every possible path to writing that data has to pass through.

A document that is shown to the public as an organization's official privacy policy or subprocessor list can now only be created, changed, or removed by someone the database itself recognizes. This person must be an owner or administrator of that organization. This is not merely based on the interface. The restriction works even if called from a different client, a different screen, or no screen at all. This is because it lives in the one layer that every possible path to writing that data has to pass through.

Quero esses resultados

The same restriction, checked two different ways (illustrative scenario, not a real client)

A staff member without any admin role opens the Trust Center admin screen. They are shown the restricted-access message. This means the UI gate is working as designed. Suppose instead that same staff member skipped the screen entirely. They called the underlying write endpoint directly with their own valid, logged-in session token. This is exactly what a browser's developer tools would allow. Before this fix, that request would have worked. This is because the database itself had no role requirement. Only the now-bypassed screen ever asked the question. After the fix, the same direct request is refused by the database's own row-level security policy. This happens no matter if any screen was involved.

Conversar sobre meu caso

How to get started

Começar agora

Frequently asked questions

Who could edit the public Trust Center documents before this fix?

Any logged-in member of the organization could edit the public Trust Center documents before this fix. The admin screen had no role check. The database policy for both tables only restricted access by organization. It never restricted access by role within the organization.

What actually enforces the restriction now — the screen, or the database?

Both, on purpose. The screen shows a restricted-access message to non-admins. But the database itself is the layer that actually matters. It refuses the write even if the screen is bypassed entirely.

Did tightening this policy break any existing data or lock out any legitimate admin?

No. This was checked against live production before the fix. Both tables held zero existing rows. Every one of the organization's real masters and admins was confirmed to keep write access.

Can a member of the organization still see the published documents without admin access?

Yes. Read access is unchanged. It remains open to every member of the organization. Only insert, update, and delete now require an admin or owner role.

What does the `WITH CHECK` clause on the update policy specifically prevent?

It prevents an edit from moving a document or subprocessor row into a different organization. This could happen as a side effect of the update. This is a gap a `USING`-only policy would leave open.

What does Centriu Axiom cost?

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

Ainda tenho dúvida

See how Centriu Axiom protects public Trust Center documents

Quero resolver isso