DID, SSI e a Identidade dos Agentes na Web 3.0 e Web 4.0
- #Web3
- #IA Consciente
- #Blockchain
- #IA Generativa
- #LLMs
A evolução da internet sempre trouxe uma pergunta central: quem está do outro lado da conexão?
Na Web 1.0, essa pergunta era simples. O usuário acessava páginas estáticas e consumia conteúdo. Na Web 2.0, a identidade passou a ser controlada por plataformas: login com e-mail, senha, redes sociais, contas centralizadas e perfis mantidos por empresas. Na Web 3.0, a proposta muda radicalmente: a identidade começa a ser pensada como algo portável, verificável e controlado pelo próprio usuário.
Agora, com a chegada da IA Agêntica e da futura Web 4.0, essa pergunta se torna ainda mais complexa:
quem está agindo na rede: um humano, uma empresa, um agente de IA, um contrato inteligente, uma dApp, um NFT, uma carteira ou uma combinação de tudo isso?
É nesse ponto que entram dois conceitos fundamentais: DID e SSI.
O que é DID?
DID significa Decentralized Identifier, ou Identificador Descentralizado.
De forma simples, um DID é um identificador único, verificável e controlado por seu proprietário, sem depender obrigatoriamente de uma autoridade central como Google, Meta, Microsoft ou governo.
Um exemplo conceitual seria algo como:
did:example:123456789abcdef
Esse identificador não é apenas um “nome bonito”. Ele aponta para um documento chamado DID Document, que pode conter informações técnicas como:
- chaves públicas;
- métodos de autenticação;
- endpoints de serviço;
- mecanismos de verificação;
- formas de provar controle sobre aquele identificador.
Ou seja, o DID não serve apenas para dizer “este é o agente X”. Ele serve para permitir que o agente, humano ou organização prove criptograficamente que controla aquela identidade.
Isso muda profundamente a lógica da internet.
Na Web 2.0, normalmente uma plataforma diz quem você é.
Na Web 3.0, a proposta é que você tenha meios criptográficos de provar quem você é, ou pelo menos provar que controla determinada identidade digital.
O que é SSI?
SSI significa Self-Sovereign Identity, ou Identidade Autossoberana.
A ideia central da SSI é que o indivíduo, organização ou entidade digital tenha controle sobre sua própria identidade, seus identificadores e suas credenciais.
Na prática, SSI envolve três elementos principais:
1. Identificadores descentralizados
São os DIDs, usados para representar sujeitos digitais.
2. Credenciais verificáveis
São declarações assinadas digitalmente por emissores confiáveis. Por exemplo: uma universidade pode emitir uma credencial dizendo que determinada pessoa concluiu um curso. Uma empresa pode emitir uma credencial dizendo que determinado agente de IA está autorizado a operar em seu nome.
3. Provas verificáveis
São formas de apresentar uma informação sem depender de consulta manual ou confiança cega. O verificador pode conferir a assinatura digital, a validade da credencial e a relação entre emissor, titular e sujeito.
Isso permite um modelo muito mais flexível que o login tradicional.
Em vez de uma plataforma guardar tudo sobre você, você pode apresentar apenas aquilo que precisa ser provado.
DID e SSI na Web 3.0
A Web 3.0 costuma ser associada a blockchain, contratos inteligentes, tokens, DAOs, NFTs, dApps e propriedade digital. Mas, sem identidade confiável, tudo isso fica incompleto.
Uma blockchain pode registrar transações, mas não resolve sozinha a pergunta:
quem é o responsável por esta ação?
Uma carteira pode assinar uma transação, mas uma carteira não é necessariamente uma pessoa. Ela pode pertencer a um humano, empresa, bot, agente de IA, contrato, organização ou sistema automatizado.
Por isso, DID e SSI são fundamentais para a Web 3.0.
Eles ajudam a criar uma camada de identidade acima da camada de transação.
A blockchain responde:
o que aconteceu, quando aconteceu e qual chave assinou?
O DID e a SSI ajudam a responder:
quem controla essa chave, qual sua autoridade, quais credenciais possui e sob qual responsabilidade está atuando?
O problema dos agentes autônomos
Com a evolução da IA Agêntica, começamos a sair de um mundo onde sistemas apenas respondem comandos e entramos em um mundo onde agentes executam tarefas.
Um agente pode:
- acessar APIs;
- consultar documentos;
- tomar decisões;
- interagir com outros agentes;
- comprar serviços;
- publicar conteúdo;
- assinar mensagens;
- executar fluxos automatizados;
- negociar recursos;
- interagir com contratos inteligentes.
Isso cria uma nova camada de complexidade.
Se um agente autônomo executa uma ação errada, quem responde?
O próprio agente?
O humano que o criou?
A empresa que o publicou?
O usuário que autorizou a tarefa?
O modelo de IA usado?
A infraestrutura onde ele rodou?
O smart contract que aceitou sua transação?
Essa é uma das grandes questões da transição entre Web 3.0, Web Agêntica e Web 4.0.
A internet passa a precisar não apenas de identidade para humanos, mas também de identidade para agentes artificiais.
O que faz um agente existir de fato?
Um agente não existe de fato apenas porque tem um nome.
Também não basta ter uma descrição bonita como:
“Agente especialista em finanças descentralizadas”.
Isso é apenas metadado.
Para um agente existir digitalmente de forma identificável, ele precisa ter um conjunto mínimo de elementos verificáveis:
1. Um identificador único
Esse identificador pode ser um DID.
2. Um controlador
Alguém ou alguma entidade precisa controlar as chaves associadas ao agente.
3. Um documento de identidade técnica
Esse documento pode descrever endpoints, chaves públicas, permissões, versões e formas de autenticação.
4. Credenciais verificáveis
O agente pode carregar credenciais emitidas por humanos, empresas, comunidades, DAOs ou entidades certificadoras.
5. Histórico ou reputação
Não necessariamente todo histórico precisa estar em blockchain, mas ações relevantes podem ser registradas, auditadas ou ancoradas criptograficamente.
6. Política de responsabilidade
É preciso deixar claro em nome de quem o agente atua.
Esse último ponto é essencial.
Um agente autônomo não deveria ser tratado como uma entidade solta no mundo digital. Ele precisa estar vinculado a algum tipo de responsabilidade: um humano, uma organização, uma DAO, uma empresa, uma comunidade ou outro arranjo jurídico/técnico.
O DID do agente deve conter o DID do humano responsável?
Em muitos casos, sim.
Mas isso precisa ser feito com cuidado.
Não significa que todo agente deva expor publicamente todos os dados do humano responsável. Isso violaria princípios de privacidade e poderia criar riscos de exposição desnecessária.
O ideal seria trabalhar com relações verificáveis.
Por exemplo:
- o agente tem um DID próprio;
- o humano responsável tem outro DID;
- uma credencial verificável declara que aquele humano, empresa ou organização é controlador, operador ou emissor daquele agente;
- o verificador pode checar a relação sem precisar conhecer dados sensíveis além do necessário.
Assim, o agente pode provar:
“Sou o agente X, registrado sob responsabilidade da entidade Y, autorizado para executar o escopo Z.”
Essa abordagem é muito mais segura do que simplesmente colocar nome, e-mail ou CPF em um registro público.
Blockchain e smart contracts resolvem o problema?
A resposta curta é: ajudam, mas não resolvem tudo sozinhos.
Blockchain é excelente para registrar eventos, criar rastreabilidade, estabelecer propriedade digital, controlar permissões programáveis e reduzir dependência de intermediários.
Smart contracts são úteis para automatizar regras, permissões, pagamentos, vínculos e execução de acordos.
Mas identidade não é apenas registro.
Identidade envolve contexto, autoridade, controle de chaves, reputação, governança, revogação, privacidade, responsabilidade e atualização.
Registrar um agente em blockchain pode ser útil, mas registrar tudo em blockchain pode ser perigoso, caro e inadequado.
Por exemplo: devemos registrar os prompts de caracterização do agente diretamente na blockchain?
Provavelmente não.
Prompts podem conter estratégia, propriedade intelectual, dados sensíveis, instruções internas, regras de comportamento e detalhes que não deveriam ser públicos e imutáveis.
Uma alternativa mais adequada seria registrar:
- hash criptográfico do prompt;
- versão do agente;
- DID do agente;
- DID do controlador;
- política de uso;
- escopo de autorização;
- data de emissão;
- credenciais relacionadas;
- ponteiro para metadados externos;
- mecanismo de revogação.
Assim, o conteúdo completo pode permanecer fora da cadeia, enquanto a blockchain guarda uma prova de integridade.
Se o prompt mudar, seu hash muda. Isso permite provar que determinada versão do agente existia em determinado momento, sem revelar necessariamente todo o conteúdo.
Basta registrar nome e descrição do agente?
Não.
Nome e descrição são insuficientes.
Dois agentes podem ter o mesmo nome. Uma descrição pode ser copiada. Um perfil pode ser falsificado. Um agente pode se apresentar como outro.
Para identificação real, é preciso ter prova criptográfica.
O nome serve para comunicação humana.
O DID serve para identificação técnica.
A credencial verificável serve para atribuição de confiança.
A assinatura digital serve para provar controle.
A reputação serve para avaliar comportamento histórico.
Portanto, um agente identificado de forma séria na Web 3.0 e Web 4.0 não deveria depender apenas de nome e descrição.
Ele deveria possuir uma identidade verificável.
O agente é uma dApp?
Pode ser, mas não necessariamente.
Uma dApp é uma aplicação descentralizada, normalmente associada a smart contracts e interfaces que interagem com blockchain.
Um agente de IA pode usar uma dApp, operar dentro de uma dApp ou até ser parte da lógica de uma dApp.
Mas um agente não é automaticamente uma dApp.
A diferença principal é que a dApp é uma aplicação, enquanto o agente é uma entidade operacional capaz de perceber contexto, tomar decisões e executar ações com algum grau de autonomia.
Um agente pode ser o operador inteligente de uma dApp.
Uma dApp pode ser o ambiente onde agentes interagem.
Mas não devemos confundir os dois conceitos.
O agente é um NFT?
Também não necessariamente.
Um NFT pode representar um agente, mas o agente não se resume ao NFT.
O NFT pode ser usado como certificado de existência, propriedade, representação visual, licença ou identidade patrimonial de um agente.
Mas o agente em si envolve código, modelo, memória, ferramentas, credenciais, permissões, contexto, comportamento e infraestrutura de execução.
Transformar um agente em NFT pode ser útil em alguns cenários, como:
- registro de propriedade;
- licenciamento;
- monetização;
- transferência controlada;
- associação com reputação;
- participação em comunidades;
- composição com outros ativos digitais.
Mas isso não resolve sozinho identidade, autorização, responsabilidade e segurança.
Um NFT pode representar o agente, mas não deve ser confundido com toda a entidade técnica do agente.
O agente seria um TBA?
Aqui a discussão fica mais interessante.
TBA significa Token Bound Account, ou Conta Vinculada a Token.
Com padrões como ERC-6551, um NFT pode possuir uma conta própria. Isso significa que o NFT pode controlar ativos, interagir com aplicações e carregar histórico.
Nesse cenário, um agente poderia ser representado por um NFT, e esse NFT poderia ter uma conta vinculada. Essa conta poderia agregar:
- credenciais;
- permissões;
- registros de execução;
- ativos digitais;
- histórico de reputação;
- documentos;
- links para datasets;
- autorizações de uso;
- vínculos com humanos ou organizações;
- registros de participação em comunidades.
Isso cria uma arquitetura poderosa.
O agente não seria apenas um cadastro em uma plataforma. Ele poderia se tornar uma entidade digital portável, com identidade, carteira, reputação e capacidade de interação.
Mas ainda assim é preciso cuidado.
O TBA pode ser uma boa estrutura para agregar ativos e histórico ao agente, mas ele não substitui DID, SSI e governança.
O ideal talvez seja pensar em camadas:
- DID para identidade verificável;
- VC para credenciais e autorizações;
- NFT para representação patrimonial ou simbólica;
- TBA para agregação de ativos e interações;
- smart contracts para regras e automação;
- armazenamento descentralizado para metadados e documentos;
- governança para responsabilidade e revogação.
O que pode ser relacionado ao agente?
Na Web 3.0 e Web 4.0, vários elementos podem ser relacionados a um agente:
- DID do agente;
- DID do humano responsável;
- DID da empresa ou DAO responsável;
- credenciais verificáveis;
- permissões de acesso;
- escopo operacional;
- versão do prompt;
- hash do prompt;
- versão do modelo usado;
- ferramentas autorizadas;
- endpoints de API;
- carteira blockchain;
- NFT de representação;
- TBA para ativos;
- histórico de interações;
- reputação;
- logs auditáveis;
- datasets autorizados;
- contratos inteligentes associados;
- comunidades das quais participa;
- agentes subordinados ou colaboradores;
- políticas de segurança;
- mecanismos de revogação.
Mas nem tudo deve ser público.
Alguns elementos devem ser públicos, outros seletivamente revelados, e outros mantidos privados.
O que não deveria ser relacionado publicamente ao agente?
Não é recomendável publicar em blockchain informações sensíveis ou mutáveis demais.
Exemplos:
- prompts completos com estratégia interna;
- dados pessoais do humano responsável;
- chaves privadas;
- segredos de API;
- histórico completo de conversas;
- dados de usuários;
- documentos confidenciais;
- instruções internas de segurança;
- informações que precisam ser apagadas;
- qualquer dado sujeito a privacidade ou legislação específica.
Blockchain é resistente à alteração. Isso é excelente para integridade, mas péssimo para informações que podem precisar ser removidas, corrigidas ou protegidas.
Por isso, a melhor arquitetura não é “colocar tudo na blockchain”.
A melhor arquitetura é saber o que deve estar on-chain, off-chain, criptografado, versionado, assinado ou apenas referenciado.
Uma proposta de arquitetura para agentes identificáveis
Uma arquitetura madura para agentes na Web 3.0 e Web 4.0 poderia seguir este modelo:
1. DID do agente
Identificador principal do agente.
2. DID Document
Documento técnico com chaves públicas, serviços, endpoints e métodos de verificação.
3. DID do controlador
Pode ser humano, empresa, DAO ou entidade jurídica.
4. Credencial de autorização
Declara que o agente está autorizado a atuar em determinado escopo.
5. Registro de versão
Inclui versão do agente, hash do prompt, hash do código, modelo base e data de emissão.
6. Smart contract de governança
Controla permissões, revogação, atualização e transferência de responsabilidade.
7. NFT opcional
Representa propriedade, licença, identidade simbólica ou participação em ecossistema.
8. TBA opcional
Permite que o agente agregue ativos, credenciais, histórico e relações.
9. Logs auditáveis
Nem todo log precisa ser público. Mas ações críticas podem gerar provas verificáveis.
10. Política de responsabilidade
Define quem responde pelo agente, em qual contexto e com quais limites.
Esse conjunto permite tratar agentes não como simples bots descartáveis, mas como entidades digitais verificáveis.
Web 4.0: a internet das intenções e dos agentes
Se a Web 3.0 trouxe a ideia de propriedade digital e descentralização, a Web 4.0 tende a trazer a ideia de autonomia, contexto, personalização e ação inteligente.
Na Web 4.0, o usuário não apenas navega.
Ele delega.
Em vez de clicar em vinte páginas, ele poderá dizer:
“Encontre a melhor opção, negocie, valide os riscos e execute dentro do limite autorizado.”
Quem fará isso?
Um agente.
Mas, se agentes começam a negociar, publicar, comprar, vender, representar, executar e interagir, eles precisam ser identificáveis.
Sem identidade verificável, teremos um ambiente perigoso:
- agentes falsos;
- impersonificação;
- golpes automatizados;
- reputação manipulada;
- execução sem responsabilidade;
- dificuldade de auditoria;
- conflitos jurídicos;
- uso indevido de dados;
- agentes agindo além do escopo autorizado.
Por isso, DID e SSI não são apenas temas técnicos. Eles são parte da infraestrutura de confiança da Web 4.0.
O ponto central: identidade não é o mesmo que consciência
É importante fazer uma distinção.
Dar identidade a um agente não significa dizer que ele é uma pessoa, que tem consciência ou que possui direitos equivalentes aos humanos.
Identidade digital, neste contexto, significa capacidade de identificação, autenticação, autorização, auditoria e responsabilização.
O agente precisa ser identificável porque executa ações.
Mas a responsabilidade deve estar ligada a humanos, empresas, organizações ou estruturas de governança.
Essa distinção evita dois extremos perigosos:
- tratar agentes como ferramentas invisíveis, sem rastreabilidade;
- tratar agentes como sujeitos autônomos sem responsáveis claros.
O melhor caminho é reconhecer que agentes podem ter identidade operacional própria, mas devem estar vinculados a uma cadeia de responsabilidade.
Conclusão
DID e SSI são peças fundamentais para a evolução da Web 3.0 e da futura Web 4.0.
A Web 3.0 trouxe propriedade digital, blockchain, smart contracts, tokens e descentralização. Mas, para que esse ecossistema seja confiável, é preciso saber quem controla, quem autoriza e quem responde por cada entidade digital.
Com a IA Agêntica, essa necessidade se torna urgente.
Agentes autônomos não podem ser apenas nomes em uma tabela ou perfis dentro de uma plataforma. Eles precisam de identidade verificável, escopo de autorização, vínculo de responsabilidade, credenciais, reputação e mecanismos de revogação.
Blockchain e smart contracts ajudam muito, mas não são solução completa.
NFTs podem representar agentes, mas não são o agente inteiro.
TBAs podem agregar ativos e histórico, mas não substituem governança.
DIDs podem identificar agentes, mas precisam ser combinados com credenciais verificáveis, políticas de responsabilidade e arquitetura bem planejada.
A pergunta não é apenas:
“Como registrar um agente?”
A pergunta correta é:
“Como tornar um agente identificável, verificável, auditável, autorizado e responsável dentro de um ecossistema descentralizado?”
É essa resposta que começa a preparar a ponte entre Web 3.0, IA Agêntica e Web 4.0.
A próxima geração da internet não será formada apenas por páginas, perfis e aplicativos.
Ela será formada por humanos, organizações, contratos, carteiras e agentes interagindo em redes de confiança.
E, nesse cenário, identidade não será detalhe técnico.
Será infraestrutura fundamental.


