Arquitetando agentes confiáveis: transformando grafos de conhecimento em mecanismos seguros de políticas

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Architecting Trusted Agents: Turning Knowledge Graphs into Secure Policy Engines · Canal: Neo4j · 1:00:15 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Dados, bancos de dados e embeddings, Ferramentas de desenvolvimento com IA

Resumo

Alex Babanu apresenta os limites do controle de acesso baseado em funções (RBAC), que pode levar à proliferação de funções e ao compartilhamento excessivo de dados, especialmente em sistemas com agentes de IA. Como alternativa, propõe autorização dinâmica baseada no princípio de zero trust, com pontos de aplicação e decisão de políticas (PEP e PDP) e regras que combinam relacionamentos e atributos em um grafo de conhecimento. A demonstração mostra como representar usuários, agentes, workflows, recursos e políticas no grafo e verificar cada solicitação em tempo real. O exemplo também evidencia que controles de acesso podem limitar o que os agentes consultam, mas as respostas geradas ainda precisam ser verificadas.

Pontos-chave

O RBAC pode acumular funções ao longo do tempo e dificultar a identificação de quem tem acesso a cada recurso.
Agentes de IA podem ampliar os riscos de acesso excessivo ao combinar permissões de usuários, APIs, agentes e servidores MCP.
O princípio de zero trust exige verificar cada solicitação de acesso no momento em que ela ocorre.
PEPs interceptam solicitações e PDPs avaliam políticas determinísticas para conceder ou negar acesso.
Um grafo de conhecimento pode representar identidades, relacionamentos, recursos, agentes e permissões em um contexto unificado.
A combinação de controle baseado em relacionamentos (ReBAC) e controle baseado em atributos (ABAC) permite políticas mais contextuais.
Modelar workflows e relações permitidas entre agentes ajuda a detectar e bloquear chamadas não autorizadas.
A autorização pode considerar a cadeia de delegação entre o usuário, os agentes e as ferramentas acessadas.
A demonstração mostra políticas que variam conforme o usuário, o recurso e o contexto, inclusive para documentos no Google Drive.
Mesmo com controles de acesso, as respostas dos agentes podem ser inconsistentes ou inventadas e devem ser conferidas.

Capítulos

Início	Capítulo	Resumo
00:00	Apresentação e motivação	Os anfitriões introduzem o tema e destacam a importância de tratar segurança e confiança como parte central da arquitetura de agentes.
04:50	O problema do RBAC e do compartilhamento excessivo	Alex explica como funções acumuladas e permissões amplas podem expor dados em sistemas como o Microsoft Copilot.
10:14	Proliferação de funções com APIs e agentes	A apresentação mostra como novas aplicações, APIs e agentes tornam difícil saber quais permissões um usuário efetivamente possui.
15:43	Zero trust, autenticação e autorização	Alex diferencia autenticação de autorização e defende verificar cada solicitação de acesso em tempo real.
21:08	Proteção de workflows e autorização dinâmica	A arquitetura usa PEPs diante de ferramentas e agentes e um PDP para avaliar regras determinísticas.
26:04	Representar permissões em grafos	A apresentação explica como relações entre usuários, funções e recursos permitem consultar caminhos de acesso no grafo.
31:34	Modelagem de agentes e workflows	Agentes, ferramentas e workflows são representados no grafo para identificar chamadas permitidas e bloquear relações indevidas.
38:25	Visão geral da demonstração	Alex apresenta a demonstração local, com agentes protegidos por gateways e dados de várias fontes reunidos no grafo.
44:23	Demonstração com usuários e dados de seguros	A aplicação mostra como as permissões e as respostas variam conforme a identidade do usuário e os dados de seguros que ele pode acessar.
49:25	Restrições de acesso e comportamento do agente	A demonstração testa o bloqueio de dados para a IA e compara o acesso de um funcionário com o de um cliente.
53:40	Conclusões e perguntas sobre agentes	Alex recomenda autorização externalizada, padrões abertos e auditoria, e responde sobre agentes como sujeitos de primeira classe no grafo.
57:36	Encerramento e próximos eventos	Os anfitriões comentam eventos futuros e indicam recursos para explorar a demonstração e a plataforma Neo4j.

Citações

Nunca confie; sempre verifique. — 15:43

A IA é inteligente, mas o sistema precisa ser simples. — 21:08

Verifique cada solicitação. Não confie em nada. — 53:40

Por favor, use seu grafo. — 53:40

Conceitos e entidades

Neo4j (empresa): Empresa e plataforma de banco de dados de grafos que organiza a transmissão e o tema da apresentação.
Alex Babanu (pessoa): Líder de produto de AI Control Suite na Indicite e apresentador da proposta de autorização baseada em grafos.
Indicite (empresa): Plataforma apresentada na demonstração para aplicar políticas de autorização a agentes e workflows de IA.
RBAC (conceito): Controle de acesso baseado em funções, que associa permissões a papéis ou grupos.
Zero trust (conceito): Princípio de segurança segundo o qual cada solicitação deve ser verificada, em vez de confiar em permissões estáticas.
PEP (conceito): Ponto de aplicação de políticas que intercepta solicitações e protege recursos.
PDP (conceito): Ponto de decisão de políticas que avalia regras e decide se uma solicitação deve ser permitida.
OpenID Connect (conceito): Protocolo mencionado para a comunicação entre PEPs e PDPs.
MCP (conceito): Protocolo usado por agentes para acessar ferramentas e recursos expostos por servidores MCP.
A2A (conceito): Protocolo de comunicação entre agentes que permite descoberta e interação entre eles.
ReBAC (conceito): Controle de acesso baseado em relacionamentos, que avalia caminhos entre sujeitos e recursos.
ABAC (conceito): Controle de acesso baseado em atributos, que usa condições contextuais para avaliar solicitações.
KBAC (conceito): Abordagem apresentada que combina relações e condições de atributos em políticas apoiadas por um grafo de conhecimento.
OPA (ferramenta): Mecanismo de políticas citado na discussão sobre autorização baseada em atributos e relacionamentos.
Cedar (ferramenta): Linguagem de políticas da AWS mencionada durante a conversa sobre sistemas de autorização.
Indicite AI Control Suite (ferramenta): Produto apresentado para controlar e aplicar políticas de acesso a IA, agentes e workflows.
Knowledge Graph Access Control demo (repo): Demonstração open source mencionada como disponível no GitHub para execução local.

Tradução completa (pt-BR)

00:00 Certo. Sejam todos bem-vindos. Boa noite, bom dia, boa tarde. Estou reorganizando um pouco esse anúncio. E bem-vindos a mais uma transmissão ao vivo da Neo Forj. Hoje, o tema é projetar agents confiáveis: transformar grafos de conhecimento em mecanismos de políticas seguros. E meu convidado de hoje é Alex Alexandre Bab… Desculpe, estou tropeçando nas palavras. Babanu. Acho que ensaiei isso, ensaiei, mas agora… [risos]

00:30 por algum motivo, não consigo dizer. >> Na próxima vez vai sair melhor. >> É, me desculpe. Me desculpe, Alex. E você é o líder de produto responsável pela AI Control Suite na Indicite. Estamos muito felizes em receber você e por você se juntar a nós hoje na transmissão ao vivo da NEOJ para falar sobre algo que, na minha opinião, costuma ser um pouco negligenciado, um pouco deixado de lado, talvez às vezes esquecido, talvez considerado como

01:02 algo secundário, ou talvez você perceba: “Ah, bom, vamos deixar de lado as coisas chatas. Vamos fazer primeiro as coisas empolgantes.” E aí, no fim, você percebe: “Ah, segurança, é mesmo. Confiar nos meus agents… Agora eles podem fazer todo tipo de coisa. Não sei se deveriam mesmo fazer isso, se deveriam ter acesso àquilo ou se os usuários deveriam ter acesso aos agents que usam isso.” >> É engraçado [risos] você mencionar as coisas chatas. Para mim, são as coisas empolgantes. >> Sim. É. É. É, deveria ser empolgante, mas, com todas essas ferramentas e coisas poderosas…

01:37 >> Acho que… >> Mas você tem toda a razão: os desenvolvedores pensam na segurança como a última coisa, a última mesmo, que querem fazer. Querem cuidar dos aspectos comerciais, implementar o caso de uso, seja ele qual for. A segurança geralmente fica para depois. E um dos problemas é que, quando se trata de controle de acesso, acabam recorrendo a roles, porque isso existe há muito tempo. E, como provavelmente veremos, não é uma boa ideia. É. [risos] >> É, e você sabe, GDPR, CCPA, esse tipo de coisa… >> Nem sempre são tão empolgantes…

02:11 às vezes, mas, com certeza. É algo com que você lidou e que vai nos mostrar um pouco na nossa sessão de hoje, para garantir que isso seja realmente mantido em ordem, que não seja deixado de lado e que seja tratado. Mas também é algo que, se você criar alguma coisa e quiser garantir que seus agents façam tudo de legal que podem fazer, mas ainda assim…

02:42 mantenham tudo em ordem, e que as pessoas acessem aquilo a que têm permissão, enquanto quem não tem permissão não consiga acessar, então acho que esta sessão é para você. Você deu um exemplo muito interessante quando estávamos preparando a descrição da sessão. Você disse: “Sabe, é aceitável seu agent ter permissão para resumir arquivos confidenciais de RH? Tudo bem se alguém puder ver os salários da equipe de liderança ou tiver acesso a…”

03:15 sabe, arquivos cruciais? É como: “Tudo bem, provavelmente você deveria analisar isso e pensar: quem pode acessar o quê, que tipo de acesso é permitido, em que nível e se é só um agent que pode fazer isso.” É importante que a equipe de RH tenha acesso aos próprios arquivos de RH, mas, sabe, talvez o estagiário não devesse ter o mesmo nível de acesso. [fungada] É ainda mais complicado com um RAG baseado em grafo, por exemplo, em que você pode perguntar qualquer coisa ao grafo. Mas, sim, exatamente, se você…

03:47 sabe, tiver dados confidenciais lá dentro, talvez tenha feito embedding de alguns documentos aos quais não deveria ter acesso, e vamos ver que isso é complicado. É ainda mais complicado com IA, e hoje também vou me concentrar no aspecto da IA, porque provavelmente é uma das principais preocupações de muita gente. >> É. >> É. >> Imagino. É. [fungada] Legal. Acho que podemos começar. Antes de passar a palavra para você, Alex, só queria…

04:17 lembrar que a sessão está ao vivo, obviamente, já que estamos transmitindo agora. Se tiverem perguntas, comentários, algo que vejam e que gostariam que explorássemos mais, ou se quiserem que expliquemos alguma coisa um pouco melhor, escrevam no chat, mandem por lá e nos avisem. Com certeza teremos um tempo no final para uma sessão de perguntas e respostas, ou também podemos fazer isso durante a conversa. Então, o canal está aberto e queremos incentivar vocês a tornar esta sessão o mais interativa possível. E, com isso, posso… >> Legal. >> Ah, obrigado, Alex. Hoje é o dia do Alex. É a terça-feira do Alex. Aqui na América do Norte, é a terça do taco, mas você tem tacos. Então, sou o gerente de produto líder da AI Control Suite na Indicite. Meu produto controla e aplica o controle de acesso para IA, IA agentic e workflows de IA usando o Neo forj como

04:50 possível e, sim, acho que com isso consigo… >> Legal. >> Ah, obrigado, obrigado, Alex. Então, hoje é dia do Alex. É a terça-feira do Alex. Aqui na América do Norte, é terça-feira do taco, mas vocês têm tacos. Então, sim, sou gerente de produto líder do AI Control Suite na Indicite. Meu produto controla e impõe o controle de acesso para IA, IA agêntica e workflows de IA usando o Neo4j como

05:23 grafo subjacente e a plataforma indicite, que é uma camada de inteligência sobre o Indicide que torna tudo fácil e simples. Minha formação é, na verdade, em identidade, e me deparei com grafos há cerca de 10 anos, quando tentava resolver alguns problemas de identidade que só um banco de dados de grafos conseguia resolver, como relações complexas em sistemas de IoT, por exemplo. Até falei sobre isso na Graph Connect em 2018. Enfim, quem se importa? Então, hoje vamos falar sobre transformar seus grafos em…

05:55 mecanismos de políticas. Como mencionei mais cedo, quando estávamos conversando, muitos de vocês pensam: “Temos controle de acesso baseado em roles, está tudo certo, não é?” Infelizmente, não. Vou começar falando do Copilot da Microsoft. Provavelmente vocês o conhecem, talvez usem ou já tenham usado: seu companheiro de IA. Por que o Copilot? Por que estou me concentrando nele? Porque ele é conhecido por usar controle de acesso baseado em roles no backend.

06:27 Ele usa todo o pacote da Microsoft: Active Directory, Entra, seja lá o que for, todos os grupos e roles que existem lá. Então, tudo o que você faz pelo Copilot passa por esse sistema de autorização. O Copilot é só um exemplo, mas qualquer sistema que use um agent de IA com roles como sistema de autorização no backend vai se comportar exatamente da mesma maneira, em termos de autorização, é claro. Qual é o problema com o Copilot? Aqui estão alguns resultados de um estudo feito há…

07:00 uns dois ou três meses, talvez três ou quatro meses. A Concentric AI publicou este relatório e identificou vários riscos associados ao Copilot. Por exemplo, 83% dos arquivos em risco estão com compartilhamento excessivo. Isso significa que, se você tem arquivos confidenciais, a maioria está compartilhada com pessoas demais. Em 17% dos casos, eles estavam compartilhados em excesso com terceiros externos; alguns dos seus arquivos críticos podem até estar acessíveis a pessoas de fora. 90% dos documentos essenciais para os negócios são compartilhados fora do pacote do Microsoft 365. Então, coisas que…

07:35 deveriam ser acessíveis apenas aos executivos da C-suite acabam, na verdade, compartilhadas com todo mundo. 15% de todos os arquivos essenciais para os negócios correm risco por causa do compartilhamento excessivo, e 3% dos dados confidenciais ativos foram compartilhados com toda a organização. Então, obviamente, temos um problema de compartilhamento excessivo, o que significa que há dados, há documentos, e o risco é que muitas pessoas consigam vê-los ou acessá-los, embora não devessem. Por que isso acontece? Quer dizer, você…

08:07 Você pode pensar: “Bem, esse é um problema da Microsoft, certo?” Bem, não, porque a Microsoft diz que isso faz parte da documentação dela. Você pode conferir. O Copilot só acessa dados que um usuário individual está autorizado a acessar, com base, por exemplo, em controles de acesso baseados em função. Então, aí está. A culpa não é deles. A culpa é sua. Se todas essas estatísticas são [risos] reais — você sabe, problemas reais nas organizações —, a culpa não é deles; o problema é seu. Mas estou aqui para dizer que a Microsoft não facilita para

08:38 você; na verdade, ela torna isso impossível. Qualquer sistema — não só o da Microsoft — baseado apenas em funções vai causar os mesmos problemas. E aqui está o motivo. Qual é o problema das funções? Bem, elas se multiplicam com o tempo. Você tende a ter cada vez mais funções, até acabar com um sistema em que já não sabe quem tem acesso a quê. >> E é assim que isso vai acontecer. Basicamente, já vi isso como consultor. Já vi isso na prática.

09:10 Passei 10 anos prestando consultoria para empresas da Fortune 500, enfim. Mas todas tinham esse problema. Todas. E tenho quase certeza de que, se você trabalha em uma organização que existe há pelo menos alguns anos, a sua também tem esse problema com funções, sejam funções da Microsoft ou de outros sistemas. Então, como isso funciona? O problema da explosão de funções começa quando você está começando a construir aplicativos. Você constrói um aplicativo; seus desenvolvedores, ou você, se for desenvolvedor, criam algumas

09:41 funções para gerenciar o acesso aos dados ou aos recursos do seu aplicativo, e tudo está bem. Um pouco mais tarde, sua organização cria, digamos, APIs ou mais aplicativos, mas você não quer quebrar o que já fez. Então, cria mais funções. Depois de algum tempo, as pessoas que criaram as primeiras funções saem da empresa, seguem em frente, ganham na loteria, seja o que for. E você acaba com funções que já não pertencem a ninguém e ninguém sabe o que fazem. Então, no fim, você acaba com um ponto cego. Tudo o que consegue ver é a associação às funções.

10:14 Vamos nos aprofundar um pouco nisso, porque é muito importante. Aqui está o exemplo explicado em detalhes. Digamos que você crie um portal de análises para que clientes e funcionários criem, acessem e gerenciem suas próprias análises com base nos dados do seu grafo. Algo muito legal. Parece bom. Para isso, você precisa de algumas funções, como, por exemplo, gerentes de análise, que podem visualizar tudo, e usuários comuns, que só podem ver o que é deles. Ótimo. Essas são as funções definidas no próprio aplicativo do portal de análises

10:47 e agora você tem um diretório da organização — pode ser o Microsoft Entra ID, o Active Directory, seu próprio diretório, LDAP, qualquer que seja —, onde estão as associações aos grupos e às funções. Por exemplo, aqui temos Alice e Bob como gerentes de análise, e Rebecca e Roy como usuários de análise. Ótimo. Então, quando Bob faz login, por exemplo, ele é gerente. Pode visualizar e ver tudo. Legal. Na fase dois, você agora tem algumas APIs de dados.

11:20 Então, agora precisa criar, como mencionei, algumas novas funções. Você tem visualizadores de dados, que só podem ver o que é deles, e administradores de dados, que podem fazer CRUD em tudo. Como você tem uma API nova, precisa essencialmente criar novas funções, porque não pode reutilizar as mesmas: elas dão acessos diferentes, certo? Não é o mesmo conjunto de pessoas. Veja, por exemplo, Roy aqui: ele ficaria sozinho. Quer dizer, você não pode reutilizar as funções, então precisa criar outras. E cria outras. No fim da etapa três, depois de algum tempo, você tem

11:55 provavelmente centenas de milhares de funções. Na verdade, muitas organizações têm mais funções do que funcionários. Isso diz muito. Nesses diretórios organizacionais, você tem todas as associações a grupos, mas não faz ideia dos privilégios concedidos, porque eles estão espalhados por todos esses aplicativos que você tem, certo? E agora entra a IA. Você está implantando esse agent de IA e agora Rebecca, uma das nossas usuárias, quer usar esse agent para, por exemplo, fazer alguma coisa com graph RAG

12:29 ou recuperar dados, ou executar consultas, ou fazer perguntas do tipo análise. Lembre-se: Rebecca fazia parte do grupo de usuários de análise e também tinha a função de administradora de dados. Então, quando Rebecca envia um prompt para a IA, ela tem, na verdade, essas permissões, mas você não as vê explicitamente. Elas estão ocultas nos bancos de dados e nas APIs subjacentes que a IA pode acessar, certo? E assim, sua IA tem acesso de CRUD a tudo. A IA não é uma API. Portanto, a IA pode decidir por conta própria o que quer fazer, o que quer fazer com base nos seus objetivos. E >> agora você tem uma IA com acesso de CRUD a todos os seus dados.

13:03 >> Isso pode ser um problema. E, na verdade, esse é o tipo de comportamento que vemos nas notícias. O agent fez alguma coisa e não sabemos por quê. Isso é um pesadelo para a governança, para o GDPR, como você mencionou, e para qualquer exigência regulatória. O que aconteceu? Bem, você vê isso o tempo todo nas notícias: a IA apagou um

13:34 banco de dados. Ela usou isso, ela… e esse é exatamente o problema, especialmente com o Copilot ou qualquer sistema de controle de acesso baseado em funções. Então, o que podemos fazer? Bem, espero que… Ah, só mais uma coisa, porque vimos o problema do compartilhamento excessivo, mas agora vamos analisar outro problema que também leva à explosão de funções: as IAs, como sabemos, precisam de ferramentas para fazer qualquer coisa. Elas precisam do MCP. O Model Context Protocol se tornou

14:04 o protocolo mais popular para acessar ferramentas. Então, temos esses servidores MCP, e qualquer agent de IA agora pode encontrar online vários servidores MCP, cada um expondo um certo número de recursos e ferramentas. Esses recursos e ferramentas podem variar de um servidor para outro. Então, a pergunta é: de quantas funções você precisa para proteger o sistema? Você tem X agents em execução na sua organização — estamos falando de grandes bancos ou

14:38 empresas multinacionais — e elas nem sabem quantos agents têm. Pelo que sabem, podem ter milhares. E talvez haja centenas de servidores MCP. E quantos usuários você tem? 10 mil, ou até mil, ou até cem usuários. Então, de quantas funções você realmente precisa para proteger esse sistema? Sua cardinalidade vai explodir muito rápido aqui, porque, se você precisa proteger esse cara específico aqui [fungada] e Rebecca só deve acessar esse cara, quantas funções Rebecca precisa ter só para isso?

15:11 Então, desde o começo, você já está entrando no problema da explosão de funções com a IA, mesmo sem considerar a outra explosão que já tem em mãos. Ou seja, você precisa de um sistema melhor, como venho tentando dizer. Então, de novo, esses são os riscos. Precisamos deixar as funções para trás e passar para a autorização dinâmica. Vamos ver o que isso significa. Essencialmente, precisamos adotar o paradigma de zero trust. Isso é

15:43 algo sofisticado que já vem sendo discutido há algum tempo no mundo da identidade, mas precisa absolutamente acontecer para a IA. O conceito principal de zero trust é: nunca confie, sempre verifique. Então, em vez de depender de funções estáticas, você precisa autorizar cada ação. Cada solicitação precisa ser autorizada no momento em que é feita, em tempo real e dinamicamente. Essa é a única opção aqui. Vamos ver como isso se desenrola e como você pode usar seu grafo para isso. Então

16:14 Antes de entrarmos [limpa a garganta] nos detalhes, precisamos de um pouco de contexto, para que todos estejam no mesmo nível e estejamos falando da mesma coisa. Alguns conceitos sobre isso dizem mais respeito à identidade. Talvez você já conheça isso; nesse caso, pode fechar os olhos. Se já conhece, é sempre bom ouvir tudo explicado de novo. Quando falamos de controle de acesso, há duas coisas principais, e isso também se aplica ao controle de IA: autenticação, à esquerda, e autorização. A autenticação é como o portão principal do seu castelo, a porta da frente, onde você verifica as credenciais, onde faz login e entra.

16:47 Depois que você está dentro, está no castelo, tudo certo. A autorização é o que acontece depois: sabemos quem você é. Você está no castelo, mas a quais salas pode ter acesso? Pode entrar no tesouro e roubar o ouro, como este sujeito aqui? É isso que estamos tentando evitar com IA, certo? Então, autorização é, na verdade, o problema difícil. A autenticação, como veremos, é mais fácil. A primeira coisa de que precisamos é falar

17:19 sobre identidade. Você, seja uma pessoa ou uma máquina, precisa de algum tipo de identidade ou, pelo menos, de um identificador para identificar as instâncias em execução das coisas que fazem solicitações no seu sistema. E, depois que você tem isso, pode autenticar. Hoje em dia, os usuários geralmente usam autenticação multifator ou passkeys, se preferirem. Ótimo. Já as máquinas normalmente são autenticadas por criptografia. Portanto, a autenticação está, em grande parte,

17:51 resolvida. A autorização, porém, é um problema mais difícil. Então, como se faz a autorização? Normalmente, isso acontece quando um sujeito autenticado, uma máquina ou uma pessoa, tenta acessar um recurso. O paradigma de zero trust diz que é preciso verificar cada solicitação. Para isso, você precisa de mais alguns componentes no seu sistema, a saber: um ponto de aplicação de políticas, um PEP, e um ponto de decisão de políticas, um PDP.

18:21 Eles atuam em conjunto. O PEP é um proxy que protege cada recurso que você tem. É como um proxy: pode ser um proxy de API, uma API, um gateway MCP, um gateway de agent ou algum tipo de coisa que filtre todo o tráfego. Observe que isso vale para toda a pilha, desde a rede até a camada de aplicação. Você pode ter PEPs no nível da rede, como, sei lá, switches, roteadores e coisas do tipo, além de gateways e gateways de API e

18:51 coisas assim. Esses componentes capturam… Tecnicamente, esses já são produtos que existem, então você pode simplesmente usá-los. O PEP captura todo o tráfego e o redireciona para um ponto de decisão de políticas, que tem um conjunto de políticas de acesso e regras de negócio implementadas. São mecanismos de regras que analisam a solicitação recebida e respondem, normalmente, permitindo ou negando o acesso. Hoje em dia, a comunicação entre os dois é padronizada por meio de um protocolo chamado AuthZEN, da OpenID Foundation. Sou um dos copresidentes, mas

19:26 o protocolo vem ganhando popularidade. Isso permite que qualquer PEP se comunique com qualquer PDP disponível. É isso que também estamos tentando alcançar com IA. Precisamos implementar PEPs e PDPs. Agora, um pequeno spoiler: o PDP será o lugar onde o seu grafo entra, e já vamos chegar a isso. Então, como proteger workflows agentic usando esse conceito de zero trust? Voltando ao nosso agent de IA, que usa vários servidores MCP, a ideia é

20:01 colocar um PEP na frente deles. A boa notícia é que existem vários gateways MCP comerciais e até open source que podem ser usados para esse fim. Temos o nosso, mas você pode escolher qualquer um. Eles devem se comunicar com um PDP, um ponto de decisão de políticas, por meio do AuthZEN. Assim, toda solicitação MCP que tentar acessar um servidor MCP precisa passar primeiro por algum tipo de gateway, que se comunica com um ponto de decisão de políticas e então permite

20:32 ou não a solicitação. Simples. Mas a IA também pode usar chamadas de API legadas, REST ou GraphQL. Há um movimento que diz que não precisamos de MCP. Tudo bem, basta proteger isso também com um PEP. Essa abordagem é mais tradicional. Existem gateways de API disponíveis. Alguns são open source. Você também pode fazer isso e incluí-los nesse tipo de círculo de confiança do AuthZEN, por assim dizer. Então, é isso. A ideia aqui é que a IA seja inteligente, mas o seu sistema precisa ser burro. Você usa

21:08 regras determinísticas tanto quanto possível. Se você tentar confiar em outra IA para proteger a IA, pode confiar nessa IA? E aí é IA até o fim. De qualquer forma, o ideal é usar aqui o máximo possível de regras determinísticas. E quanto aos workflows? Um workflow agentic ocorre quando vários agents colaboram para alcançar um objetivo, um objetivo comum. Há também outro protocolo, chamado A2A, de agent para agent, que foi proposto pela

21:39 Google no ano passado ou no ano anterior. Não me lembro da data exata, mas agora os agents podem se comunicar e descobrir uns aos outros. Eles têm cartões de agent que descrevem o que fazem, suas skills, e cada agent pode descobrir outro agent e simplesmente se comunicar com ele. Agora temos esses frameworks agentic. Então, como protegê-los? Bem, é a mesma ideia. Você coloca um PEP em todos os lugares, e lá embaixo fica o PDP, com o grafo como contexto. É aí que o contexto será realmente, realmente necessário para entender

22:10 tudo isso, como veremos daqui a pouco. Essa é a ideia. A ideia básica, como vocês viram, é colocar PEPs nos lugares certos e usar um ponto de decisão de políticas para conceder acesso. Agora que vimos a arquitetura em alto nível, como escrever de fato essas políticas de acesso? É aí que chamamos isso de controle de acesso baseado em conhecimento, porque usamos um grafo de conhecimento. Vamos entrar nos detalhes, mas precisamos falar sobre políticas de acesso. Há duas linhas de pensamento aqui: autorização dinâmica

22:46 e autorização estática. Para lembrar, a autorização estática inclui, por exemplo, suas funções. É assim que se parece uma entrada LDAP. Se você nunca viu uma, é assim que ela se parece. É isso que fica armazenado em um diretório LDAP, por exemplo, no Azure AD ou no ENTRA. Isso descreve um grupo chamado gerentes de RH. E tudo o que você vê ali é um conjunto de membros. Está gravado em pedra, por assim dizer. Diretórios LDAP são muito lentos para gravação e muito rápidos para leitura. Portanto, não se espera que mudem muito; são bem estáticos. E

23:19 aqui está, por exemplo, como uma função seria embutida em um código espaguete de algum aplicativo. Por exemplo, está codificado diretamente ali que, nesse aplicativo específico, os gerentes podem fazer isto ou aquilo. Por isso, é muito difícil entender quem tem acesso a quê, porque, de um lado, temos esses membros e, do outro, 10 mil aplicativos, cada um com seu próprio código. Nossas listas de controle de acesso também são muito estáticas. É isso que o Linux ou qualquer sistema baseado em Unix usa. É assim que o sistema de arquivos é protegido. Funciona bem no Linux, mas, na escala de uma empresa,

23:53 fica um pouco mais complicado. Não quero entrar agora nos sistemas que usam isso, embora existam sistemas modernos que o fazem. Em vez disso, então. Isso é ruim porque cada um desses sistemas leva a uma explosão. Com o tempo, você terá cada vez mais ACLs e cada vez mais funções, como vimos. Portanto, é melhor, e na verdade é recomendado, migrar para a autorização dinâmica. São sistemas de autorização que dependem de mecanismos de regras, como mencionei, e regras… Você precisa de muito

24:25 menos regras do que funções. Talvez você precise de 100 regras, e isso poderia substituir, sabe, mil regras. Não tenho especificações aqui. Depende dos seus casos de uso, mas seriam muito, muito menos, muito mais gerenciáveis. A ideia é que essas coisas recebam como entrada um sujeito que quer acessar um recurso. Tudo isso acontece em tempo real. Um sujeito está tentando acessar um recurso. Aqui está o contexto. O sujeito está localizado nesta localização geográfica, neste horário do dia, por exemplo. Ele pode acessar o recurso? Isso acontece em tempo real, e você recebe uma

24:57 concessão ou uma negação. Alguns eventos podem acontecer e alterar os dados ou as regras subjacentes, ou algo do tipo. Mas tudo bem. É tudo dinâmico e acontece em tempo real. É exatamente disso que precisamos. Então, como mencionei, entre o PEP e o PDP temos o protocolo ODSEN, e é assim que o protocolo se parece. Essencialmente, há vários payloads JSON que são trocados. Este é um pedido, e você vê que ele corresponde ao que mencionei aqui no diagrama. Temos o sujeito aqui: Alice tenta acessar, tenta ler

25:32 um recurso chamado conta, conta um, dois, três, e neste horário do dia. Então, agora o mecanismo de regras processa isso e diz: decisão verdadeira; Alice pode acessar o documento. Ótimo, bem fácil, certo? Então, o que estou dizendo é: agora, como todos nós trabalhamos com grafos aqui — ou deveríamos trabalhar —, como sabemos, como migramos do controle de acesso baseado em funções para algo que usa um grafo? Bem, a primeira coisa é representar… talvez, se você

26:04 tenha funções por toda parte, uma primeira ideia seja colocar todas essas funções no seu grafo. Por exemplo, isto expressa a mesma coisa: está escrito estaticamente em algum diretório LDAP e poderia ser armazenado no seu banco de dados Neo Forj, expressando a mesma coisa. Esses dois usuários são gerentes. Então, se nos concentrarmos apenas nisso, não estamos mais falando de controle de acesso baseado em funções. Isso é controle de acesso baseado em relacionamentos, porque observamos os relacionamentos. Mas

26:36 agora, o interessante é que também podemos representar as permissões. E essa era a peça que faltava. Se as funções tivessem sido representadas como grafos desde o início, na verdade, elas não teriam sido um problema. A qualquer momento, você poderia saber quem tinha acesso a quê, reutilizar funções ou, sabe, gerenciar o acesso adequadamente. Mas, por algum motivo, isso não aconteceu. A representação mudou para LDAP, que, na verdade, ocultou tudo. Então, agora você tem suas permissões, tem seus gerentes,

27:07 eles podem criar todos os dados da API. Na verdade, só quero ressaltar um ponto: se você olhar para as pessoas que criaram o controle de acesso baseado em funções em 1992, Ferolo e seu artigo que criou o controle de acesso baseado em funções, é exatamente assim que representaram a associação a funções. >> Usuários são membros da função, certo? >> Então, havia um grafo desde o começo. >> Sim, sim. >> Então, por que acabamos usando diretórios? Não sei. Suspeito que tenha sido a Microsoft.

27:40 >> [risos] >> Não, na verdade, provavelmente não. Deve ter sido a Netscape. Primeiro houve o diretório da Netscape. O LDAP v3 surgiu. Ficou popular. Enfim, se tivéssemos mantido essa ideia, estaríamos em melhor situação. Mas, infelizmente, não foi o que aconteceu. E… >> Em 1992, não havia nenhum banco de dados capaz de fazer isso. [risos] >> É, [fungada] verdade. Na verdade, sim, a Web Semântica, em 1998. Então, foi nisso que acabamos. Na verdade, até um banco de dados relacional teria sido melhor, porque você teria

28:12 conseguido modelar aqueles elementos ali, pelo menos. Enfim, seguindo em frente. É assim que funciona o controle de acesso baseado em relacionamentos, ou rebback. Ele analisa os caminhos. Por exemplo, se você quisesse saber a que Jay do, aqui embaixo, tinha acesso, bastaria seguir o caminho e descobrir que, certo, Jay do tem acesso à API de dados e ao documento um. E você pode, na verdade, ver aqui neste exemplo específico que ele pode ler as APIs de dados e visualizar o documento um; e pode expandir essa ideia indefinidamente

28:48 no seu grafo, certo? Mas agora não são só funções. Você tem liberdade para usar qualquer tipo de nó ou tipo que quiser. Por exemplo, aqui temos organizações; não são mais apenas funções, é o que você quiser. Então, você tem liberdade para usar qualquer tipo de controle de acesso, com os caminhos e relacionamentos que quiser no seu grafo. Não é ótimo? >> Então, ainda está faltando algo: aquelas condições ambientais, sabe, como o horário do dia, a localização geográfica ou algo baseado

29:21 talvez no token de acesso apresentado, porque, ao fazer login, você recebe um token de acesso, e o MCP exige autenticação e autorização por meio do OS. Então, talvez haja algumas coisas que precisem ser verificadas. Portanto, além dos relacionamentos, você precisa de algumas condições de atributos. Sistemas baseados em atributos são chamados de sistemas de controle de acesso baseado em atributos, ou Aback, que também é outro tipo de autorização dinâmica. Bem, precisamos combinar os dois para obter

29:51 o contexto completo e políticas de acesso adequadas. Então, é isto que temos: rebback à esquerda, Aback à direita, que juntos formam Kback. Kback é, essencialmente, o conjunto completo. É assim que o chamamos. Provavelmente somos os únicos que o chamam assim. Mas, de resto, acho que o nome científico disso é controle de acesso baseado em relacionamentos com atributos — ARback. É meio complicado de dizer. [risos] [fungada] Então, agora você tem todas as peças do quebra-cabeça para o seu sistema de controle. Isso é para

30:26 exemplo, como a política Kback poderia ser. É assim que as representamos. Você não precisa fazer do jeito que fazemos, mas, como pode ver, há uma parte declarativa, que é a parte do acesso por relacionamentos, e depois há algumas condições adicionadas a ela. Então, combinamos isso no nosso mecanismo de regras para conceder ou não o acesso. Verificamos o caminho e, se a verificação do caminho for aprovada, também verificamos as condições, basicamente. Então, esse é só um exemplo de Kback — ou de rebback, se você quiser usar o termo mais acadêmico.

31:00 Então, agora você tem seu grafo de conhecimento. Você deve enriquecê-lo com identidades, políticas e recursos. Agora, você tem um grafo de conhecimento completo de identidade e contexto. Ele contém não apenas seu conhecimento normal, mas, se você o enriquecer com identidade e o contexto relacionado à identidade, terá um quadro completo que pode usar para controle de acesso e talvez para obter insights, como, por exemplo, quem pode acessar o quê — algo que, mais uma vez, é invisível nos sistemas tradicionais de controle de acesso baseado em funções. Então, como usar isso para IA? E esta

31:34 é a última peça do quebra-cabeça. Digamos que agora você tenha esses frameworks e workflows agentic e que possa modelá-los no seu grafo. Por exemplo, tenho aqui um grafo simples que modela um workflow com três agents, dois agents e um servidor MCP. Digamos: agent um, agent dois, agent e MCP, ou agent três, tanto faz. Então, em runtime, temos aqui o agent um, que chama o agent dois, e temos PEPs por toda parte. Assim, podemos rastrear todas essas comunicações. Então, olhamos

32:07 para o nosso grafo de referência aqui. O agent um pode chamar o agent dois. Então, isso está certo, na verdade. Mas agora o agent dois, por algum motivo, decide chamar o agent quatro. Calma aí. Se olharmos para o nosso grafo aqui, o agent dois nunca deveria chamar o agent quatro. Ele só deveria ter acesso a um servidor MCP. Então, isso não deveria ser permitido. Isso é agência excessiva. O agent dois está tentando fazer alguma coisa. Não deveríamos deixá-lo fazer isso. É assim que isso poderia funcionar. Por exemplo, vamos ver um exemplo adequado…

32:40 grafo. Então, digamos que este seja um grafo que representa dois workflows, dois workflows de agentes. O primeiro é uma busca de dados, ou algo do tipo RAG. Um tipo de RAG com grafo, em que temos uma transação que passa por um chatbot e, no caso da busca, passa por um agent recuperador e, depois, busca dados no grafo. Em seguida, um gerador produz a resposta. Ótimo. Também há outro workflow, talvez um de inicialização de computação, e este é um

33:11 workflow que também passa pelo mesmo chatbot, mas gerencia instâncias na nuvem, talvez iniciando ou desligando VMs, criando balanceadores de carga ou algo assim. Quando isso é concluído, ele se comunica com outro agent para notificar os usuários, por exemplo, pelo Slack. >> Hum-hum. >> Ótimo. Temos esses dois workflows modelados e, logo de cara, podemos ver que o cloudbot nunca deveria conseguir recuperar dados. Não há nenhuma relação entre eles. Portanto, devemos conseguir bloquear isso logo de cara e impedir totalmente essa comunicação.

33:43 Agora, vamos adicionar alguns usuários. Temos quatro usuários aqui. Temos Alice, que pode iniciar a busca. Temos algumas pessoas da equipe de vendas que também podem interromper a transação de busca. E temos Bob, que provavelmente é de DevOps, porque pode iniciar o workflow de computação, que inicia ou desliga VMs. Roger não deveria poder iniciar isso; só Bob pode, porque, mais uma vez, identificamos essas relações. Elas têm tipos diferentes, então conseguimos determinar qual é qual e

34:18 definir políticas de acesso para isso, como vimos antes. E aqui você pode ser tão granular quanto precisar. Pode vincular isso aos seus dados reais e criar as regras de relacionamento, como vimos, com granularidade até os dados ou as propriedades dos nós, se precisar. Então, é basicamente assim que isso funciona. Agora que já mostrei isso, queria mostrar como funciona na prática. >> Legal.

34:49 >> Para provar meu ponto. >> Sim. >> Sim. Vamos fazer uma rodada rápida de perguntas primeiro ou…? Ou, sim. E desculpem, não conheço muito bem todas as siglas, então talvez eu tropece um pouco nelas, mas teve uma que você mencionou: ABAC. É controle de acesso baseado em atributos, acho. >> Sim. >> E o Sai pergunta: qual é a sua opinião sobre a configuração de ABAC com OPAL? E estou supondo

35:19 que essas também sejam abreviações com as quais não estou muito familiarizado. >> OPAL é aquele framework de orquestração do OPA, provavelmente Open Policy Agent. >> Sim, pode ser isso. Certo. Mas, se você não tiver familiaridade, talvez o Sai possa nos explicar um pouco melhor o que quer dizer com isso. Quer dizer, obviamente, ABAC já existe há algum tempo e é uma boa maneira

35:50 de implementar autorização dinâmica. A ideia do controle de acesso baseado em atributos é que todas as regras se baseiam em atributos que você pode coletar em tempo de execução e usar para controlar o acesso. Então, com ABAC, você acaba tendo muito mais regras, porque pode haver muitos atributos, mas o que falta é a parte das relações. Acho que o contexto é bastante importante, e o OPA também não tem isso. OPA ou OPAL,

36:21 se for isso mesmo que estou pensando. Mais uma vez, levar os dados para o OPA é complicado, e falta toda a parte das relações, que você pode implementar com um sistema como o Zanzibar. Mas, mesmo nesse caso, você precisa dos hubs, e é mais parecido com um sistema do tipo ACL, com relações. Quer dizer, também é bom, desde que… O ponto é que acho que você precisa das relações para ter o contexto completo para IA. >> Sim, isso é… >> Sim, acho que isso é mais como

36:54 um comentário e, depois, provavelmente uma pergunta do David. David diz: “ABAC com ALFA é algo que você poderia fazer. ALFA escala melhor que Cedar.” Muitas siglas hoje. Desculpem, não sei o que todas elas significam. >> Sim. Não, tudo bem. Cedar é uma linguagem de políticas da AWS. Ela foi disponibilizada como open source. David, se for o mesmo David que estou pensando,

37:24 é um dos coordenadores do ALFA, um padrão JSON para ABAC baseado em um padrão mais antigo chamado XACML — mais siglas, que usa XML. [risos] Esse é melhor nem tentar entender. Quer dizer, de novo, ouçam, ele entende disso, mas acho que as relações são realmente o componente principal que falta em todos esses outros sistemas. Elas não são tão explícitas ou expressivas da mesma forma que em um banco de dados de grafos.

37:54 Dá para ver isso na tela. É difícil reproduzir essa lógica com ABAC. Quer dizer, David provavelmente sabe como fazer, mas você provavelmente precisaria de um monte de regras para chegar à mesma ideia: seguir este caminho, por exemplo, concede acesso. >> Sim, faz sentido. Não vejo outras perguntas, mas, se tiverem mais alguma, especialmente talvez quando Alex mostrar

38:25 a demonstração, avisem no chat, por favor, e não sejam tímidos. É só enviar as perguntas, e podem jogar qualquer sigla que quiserem para mim. Vou apenas lê-las em voz alta. [risos] >> Legal. Sim, colocando o pessoal de grafos na berlinda. >> Sim. [risos] >> Eles levam na esportiva. Então, só queria mencionar que esta demonstração está disponível para todos no nosso GitHub open source. Essas demonstrações estão disponíveis para desenvolvedores. Vocês podem executá-las localmente.

38:57 Estou executando-a localmente na minha máquina. Vocês podem fazer o mesmo que eu, mas vou apenas mostrá-la. Esta é a aparência da demonstração. Sei que há muitas caixas e setas, mas não é tão complicado. Temos nosso banco de dados de grafos, que fica meio escondido atrás do painel de controle do Indykite. Estou usando o Indykite porque é a ferramenta que tenho à disposição aqui. Mas as ideias são as mesmas, independentemente das ferramentas que vocês usem. O Indykite é uma boa plataforma, obviamente.

39:30 Temos alguns agents que nos permitem fazer algumas coisas. Temos um agent orquestrador que recebe prompts de uma pessoa, e a orquestração pode decidir se o prompt diz respeito à recuperação de dados — nesse caso, delega a tarefa a um agent de recuperação de dados — ou se diz respeito a alguns documentos armazenados no Google Drive, e vou mostrar isso daqui a pouco. Também temos alguns documentos do Google Drive por meio de MCP, ou

40:00 se o prompt diz respeito ao clima. É um exemplo bobo, mas serve apenas para mostrar que você pode fazer chamadas REST externas para fontes externas diretamente, em tempo de execução, a partir da plataforma. Não precisa armazenar todos os dados na plataforma. Basta apontar para outro lugar onde os dados estão armazenados e usá-los em tempo de execução. Enfim, todos esses agents são protegidos pelo nosso próprio PEP, nosso próprio gateway. Temos um PEP para cada um deles. >> Hum-hum. >> Temos um PEP na frente do nosso orquestrador, do nosso recuperador e do Google Drive via MCP, e então

40:37 buscamos os dados. O recuperador busca os dados no nosso grafo de conhecimento por meio do servidor MCP, que dá acesso às nossas ferramentas do OPA e a algumas consultas que temos — algumas consultas de conhecimento que expõem nossas consultas de conhecimento do Context IQ para acessar os dados. Agora, tudo isso é protegido pela plataforma de autorização e, do ponto de vista da autenticação, usamos um provedor de identidade externo. Neste exemplo, é o Security…

41:09 E esse provedor de identidade autentica usuários e máquinas por meio do sistema operacional, então também faz a troca de token para nós. O que acontece é que queremos autorizar não apenas o usuário ou a máquina, mas toda a cadeia de delegação. É o usuário usando o agent. É isso que estamos autorizando. Então, precisamos rastrear a cadeia de autorização, a cadeia de delegação até o fim, para ter uma visão completa do que está acontecendo. Então, quando essa pessoa chega a este

41:44 retriever, por exemplo, a cadeia de autenticação e delegação também deve incluir o agent anterior. Assim, sabemos que podemos autorizar o workflow completo. Agora, é claro, os dados vêm de várias fontes. Podem vir do CRM, de RH, de alguns bancos de dados personalizados, de alguns documentos do SharePoint. E também encapsulamos alguns papéis e coisas assim que vêm do SharePoint. Então, temos um monte de coisas no knowledge graph. Espero que isso faça sentido. O caso de uso aqui é que somos uma

42:16 seguradora e lidamos com sinistros. O que é importante nessa seguradora são os domicílios e as relações entre os membros do domicílio: quem faz parte do domicílio, seus filhos, os veículos que têm, as apólices de seguro dos veículos, as apólices de seguro residencial e assim por diante. Então, vamos dar uma olhada em como isso se parece. Primeiro, vou mostrar os dados propriamente ditos. Esta é a plataforma indicite, e é assim que os

42:47 dados se parecem. Este, por exemplo, é um dos nossos clientes, James Mitchell. Vamos vê-lo novamente daqui a pouco. James faz parte do domicílio. Ele é pai de Ethan. Sarah é sua esposa. Sarah é a titular da apólice do seguro residencial. Eles têm uma propriedade, uma hipoteca e um monte de seguros. Ótimo. Mas, como podem ver aqui, vinculamos isso a algumas definições de workflow. Os clientes, em particular James,

43:20 podem acionar alguns workflows de IA vinculados a alguns agents, e vamos ver isso em um instante. Esses agents que mostrei ali. Também temos alguns departamentos. Alguns dos nossos usuários são funcionários, e outros usuários são clientes. James é cliente. Mas, se eu olhar para outro… Desculpem, cliquei no botão errado. Por exemplo, aqui está Millen, que é funcionária. Então, a

43:52 visualização dela é um pouco diferente. Ela se reporta a outra pessoa e trabalha no departamento. Basicamente, neste caso de uso simples, quem trabalha no departamento é funcionário. >> Este é o esquema do banco de dados. Esta é a ontologia dos dados, por assim dizer. Pessoas podem acionar workflows, workflows têm agents, pessoas trabalham em departamentos, e é assim que juntamos tudo. A parte de acesso fica mais do lado do

44:23 workflow, vinculada aos dados, que são mais específicos das apólices de seguro. Então, é assim que os dados aparecem na plataforma. Tenho aqui um app, que é o nosso app de seguros. Criei-o com meu amigo Clo. [risos] Então, não ficou muito bonito. >> É. Primeiro, vou entrar aqui como a usuária Millisent. Millisent é funcionária de atendimento ao cliente da nossa seguradora de residências seguras.

44:59 Este app está aqui apenas para mostrar que usa o endpoint REST. Tudo o que vocês veem aqui usa as consultas de conhecimento do REST Context IQ. Por exemplo, tenho aqui uma consulta de domicílio. Se eu clicar aqui… Sim, por exemplo, posso consultar Sarah Mitchell. É bem estático, sabe? Mas, aqui embaixo, tenho uma pequena janela de chat. Essa janelinha de chat, na verdade, aciona o workflow que mostrei

45:34 no slide anterior. Aqui, posso fazer uma pergunta, e isso vai acionar o workflow inteiro. Por exemplo, só para garantir que nossa IA saiba como quem estou conectado, vou perguntar quem sou. E vocês vão ver aqui um pequeno log de rastreamento de todos os nossos PEPs, os nossos gateways. A solicitação passou primeiro pelo gateway. Millent tem autorização para acessar o agent orquestrador. Ela tem autorização para acessar o agent retriever e tem autorização para

46:04 acessar o servidor MCP. E temos uma resposta. Isso passou pelo servidor MCP, que obteve os dados do knowledge graph. “Você é Medicent, uma representante de atendimento ao cliente.” Ótimo. Agora, como vocês podem ver, esses dados que obtive do REST são muito estáticos. Mas ela tem uma pergunta de James, o cliente. James está ligando sobre o seguro residencial da casa dele, no endereço 123 Oak Avenue. O que ele pode ver sobre a apólice? Então, ele está fazendo essa pergunta

46:36 porque não está vendo alguma coisa. Basicamente, ele quer saber por quê. Em vez de consultar a parte estática, vou simplesmente perguntar à IA. Isso passa por este processo e, enquanto ela está pensando, tudo está sendo executado na minha máquina. Posso mostrar a vocês como é quando executamos isso. Está fazendo várias coisas. Está passando pelo workflow inteiro. E, como podem ver, James vê apenas algumas coberturas básicas da casa. Mas vamos ver.

47:10 Sabemos que James é casado com Sarah. Então, vamos ver o que Sarah consegue ver e tentar descobrir por que James não vê algumas coisas que ela vê. Mais uma vez, este quadrado representa o grafo no backend e, espero, vamos obter alguma coisa. Aí está. Sarah consegue ver mais coisas. Vejam: James só consegue ver as coberturas, mas Sarah consegue ver os valores porque é a titular da apólice. Então, essa era, na verdade, a pergunta que James fez quando ligou. Por que James não consegue ver

47:43 o prêmio? Mais uma vez, minha parte estática não respondeu a essa pergunta. Quer dizer, consigo ver o domicílio, >> mas não consigo dizer por que James não vê o prêmio. É por isso que estamos perguntando à nossa amiga IA. >> James não consegue ver o prêmio do seguro residencial porque, de acordo com os registros do sistema, ele não tem atualmente uma apólice ativa de seguro residencial. A esposa dele tem o prêmio. Então, ele não consegue vê-lo porque a esposa tem essa coisa. >> Entendi. Não. >> Agora, essa família tem vários filhos. Eles já têm idade para dirigir. Então,

48:19 sei que, no nosso… Ah, eu devia mostrar o Google Drive. Temos um Google Drive aqui com alguns compartilhamentos. Estes são alguns documentos no Google Drive, documentos reais. São documentos de demonstração, mas são documentos relacionados ao seguro dos clientes. Há alguns outros documentos que vêm do SharePoint, que foram incorporados e armazenados no banco de dados. Mas esta pergunta diz respeito às apólices relacionadas aos clientes, às apólices de seguro nos documentos do nosso Google Drive. Nossos motoristas de car sharing

48:53 estão cobertos pelo nosso produto de responsabilidade civil guarda-chuva? Provavelmente é uma pergunta que faz sentido para profissionais do setor de seguros. Agora, uma coisa… Vamos ver, vamos ver o processamento. O que acontece aqui é que o fluxo é diferente. Agora, passamos por um fluxo diferente de agents, porque estamos acessando o Google Drive. Então, um conjunto diferente de agents é acionado e autorizado em tempo real, e obtivemos uma resposta. Não vou lê-la. Agora, há uma coisa

49:25 aqui que quero mencionar: temos uma política da empresa segundo a qual a lista de pessoas e veículos, essa lista que posso acessar pelo REST, não deve ficar disponível para a IA de jeito nenhum. Então, por exemplo, se eu perguntar “Você pode me dar a lista de pessoas e veículos?”, isso deveria retornar essa lista, certo? A lista de pessoas e veículos.

49:57 Vamos ver o que acontece. De novo, temos uma política que diz que a IA não deve acessar isso. >> Sim. >> E vamos ver o que acontece. Desculpe, não consegui encontrar nenhuma informação sobre a lista de pessoas nos serviços. Então, com base no contexto, podemos ou não autorizar, seja IA ou não; podemos autorizar em um nível bem granular aqui, usando todas aquelas coisas de que falei. Então, vamos dar uma olhada no que um cliente veria aqui se eu entrasse como James. Me dê um…

50:28 …segundo aqui, as credenciais. Então, vou entrar como James. Então, James… Opa. Ah, desculpe. Colei errado. Pronto. James tem uma visão diferente do aplicativo. Obviamente, é uma visão bem limitada. Ele só consegue ver a própria residência. Ótimo.

50:59 >> Claro. Sim. >> Sim. Então, agora vamos dar uma olhada nisso. Ele também tem acesso ao assistente. Lembra que mostrei que havia algumas relações ali? Então, por exemplo, deixe-me fazer a mesma pergunta. Você pode me dar a lista de pessoas e veículos? Neste caso específico, James deve poder acessar os detalhes da própria residência. Então, será acionada uma política diferente.

51:30 >> Então… >> Esperamos que ele só consiga ver a própria residência. Isso. Então, mais uma vez, o poder do contexto aqui… Esperamos que… [risos] >> Sim, obrigado. Ah, não foi possível encontrar informações. Bem, funcionou antes… De qualquer forma, [risos] os dados estão protegidos. Deveria ter acionado outra política, mas vamos ver se conseguimos fazer a mesma pergunta sobre o Google Drive…

52:03 …porque o Google Drive é, na verdade, um recurso protegido pela empresa. Então, James não deveria ter autorização para acessar esse Drive de jeito nenhum. Como você pode ver aqui, acesso não permitido. Curiosamente, ainda está acionando alguma coisa. Bem, esse é o problema com o meu workflow, acho. De qualquer forma, vamos ver o que acontece. Acho que o orquestrador está tentando várias coisas aqui agora. >> Sim. Sim, eles podem ser bem criativos… [risos] >> Interessante. Sabe, eu tentei isso…

52:35 …antes da nossa sessão e estava funcionando como eu esperava. Mas esse é o problema: você nunca sabe o que ele vai fazer. Ainda está pensando, se olharmos para isso. >> Acho que encontrou a resposta agora. >> Ah, encontrou. Sim, com base na documentação de políticas disponível, o Secure Home Premium. Então, encontrou isso em… Certo, não há menção explícita. Então, tentou encontrar isso no banco de dados. Interessante. Acho que está inventando coisas agora. >> Uau. Interessante. Mas não tinha autorização para acessar o Google Drive. Essa é a parte importante. Então, tenta…

53:07 …obter alguma coisa do nosso MCP. Isso não é uma resposta no MCP. Interessante. Então, é aí que, na vida real, você vê… Isso não aconteceu nos meus testes anteriores. Então, é isso. Em essência, é assim que funcionaria. Se eu voltar… Esse é o resumo do que eu queria mostrar. O que vimos aqui é que, usando contexto e controles de acesso adequados, você consegue realmente proteger seus dados. Por exemplo, o que vocês viram no final não está no…

53:40 …banco de dados. [risos] >> Sim. >> Então, confira o que a IA diz. Para concluir, sempre verifique; nunca confie em nada. Então, verifique cada solicitação, por menor que seja. Chega de controle de acesso baseado em funções. Use seu grafo. E use padrões abertos sempre que possível. Oso e autorização externalizada, porque esses sistemas de autorização externalizada oferecem tudo o que você precisa para a governança também. Eles informam por que algo aconteceu. Há um registro de auditoria. Se você quiser…

54:14 …saber por que um agent fez alguma coisa, pode encontrar a resposta. E, por último, você pode experimentar por conta própria tudo o que mostrei. Este repo no GitHub é para você se divertir. >> É isso. >> Legal. Ótimo. Muito obrigado, Alex. O link para o repo está, obviamente, na descrição do vídeo no YouTube. Então, procure por ele; também o publiquei no chat. Estamos quase no fim do tempo disponível, mas, Alex, há mais uma pergunta no chat, do Phil, que eu gostaria de ler, e talvez você possa tentar responder. Phil pergunta…

54:44 …se a autorização empresarial é representada como um grafo de conhecimento usando relações ABAC e ReBAC, os agentes de IA podem ser modelados como sujeitos de primeira classe no grafo, com permissões derivadas dos mesmos caminhos de autorização que os usuários humanos, em vez de usarem uma estrutura separada de permissões para agents? >> Sim. Na verdade, não há uma estrutura separada aqui. O que vocês veem, o que mostrei no aplicativo normal, o aplicativo web estático…

55:20 …para usuários humanos, usa exatamente as mesmas políticas. Não tenho políticas diferentes; ele usa exatamente o mesmo grafo. Mas o contexto e as políticas são tais que, no caso da IA, geram resultados diferentes. Então, sim, é possível, e é exatamente assim que foi implementado. >> Sim. Legal. E há um comentário interessante do Ross sobre o comportamento que acabamos de…

55:52 …ver: os agentes de IA são, acima de tudo, persistentes e muitas vezes inconsistentes. É uma tecnologia incrível, isso é bem verdade. [risos] >> Então, sim, você nunca deve confiar nela, certo? Por isso, por exemplo, você não quer proteger a IA com IA. >> Sim, com certeza. E temos mais uma pergunta, do Michael. Michael pergunta: “Isso pode ser usado com uma rede de agents baseada em DIDComm?” DID… >> Não sei. >> Certo. DID, então isso provavelmente se refere a…

56:24 …identidade descentralizada. DIDComm provavelmente seria um método. Sim. Na verdade, na minha apresentação anterior, fiz uma demonstração para uma startup de CTO chamada Three Edges, e fizemos uma demonstração exatamente assim, em que usamos credenciais verificáveis com DID Web. Não sei o que é DIDComm, mas espero que seja parecido o suficiente. Credenciais verificáveis são payloads JSON carimbados criptograficamente, por assim dizer, que podem ser distribuídos para atestar…

57:00 …alguma coisa. Por exemplo, um caso de uso: tenho uma certificação em encanamento e esse certificado está na carteira do meu celular, e posso compartilhá-lo com alguém. Um agent poderia carregar algo parecido. Sabe, “sou um agent. Tenho minha credencial verificável, que permite confiar em mim porque foi emitida por essas pessoas em quem você confia”. E, sim, você pode representar uma credencial dessas no grafo como um nó. Na verdade, isso é bem poderoso, porque você pode relacioná-la a emissores, titulares e verificadores, e acompanhar em tempo real toda a…

57:36 …evolução dessas credenciais. Então, com certeza, seria uma ótima maneira de fazer isso. Tenho uma demonstração em algum lugar, dos bons e velhos tempos, em que fizemos exatamente isso. >> Ótimo. Isso me deixa com um minuto. Gostaria de anunciar a próxima transmissão, que faremos no dia 30 de setembro. Daqui a duas semanas, Jose vai participar comigo, e vamos falar sobre memória de agents: um mecanismo de memória persistente para agents de IA no .NET. Deve ser uma sessão…

58:08 …bem interessante sobre memória de agents, especificamente sobre a solução de memória para agents no .NET. O NODES está chegando cada vez mais rápido. Então, também gostaria de compartilhar com vocês o caminho até o NODES. Anunciamos a programação do NODES 2026. Se tiver interesse, confira o site do NODES. Se quiser participar de várias oficinas práticas, elas também começam daqui a duas semanas, no dia 1º de outubro, e vão acontecer durante todo o mês de outubro, com sessões práticas interessantes. Isso também está chegando. Faça sua inscrição pelo link que compartilhei no chat. E, sim, se agora você está pensando no que fazer em seguida e em como se aprofundar, experimente o repo do Alex que foi compartilhado. Dê ao seu sistema de segurança um backend baseado em grafo para comprovar os caminhos de acesso. Se quiser aprender mais, a Graph Academy está à sua disposição. E, se quiser simplesmente brincar com o Neo…

58:42 …

59:14 O Neo4j Free é um ótimo lugar para começar, sem ter que se preocupar com nada. E sim, acho que é isso por hoje, ao fim desta sessão. Foi uma visão geral muito, muito legal, uma demonstração muito, muito interessante e um conceito muito interessante. Então, muito obrigado, Alex, por mostrar isso e nos dar essa perspectiva. Você compartilhou suas formas de contato, então vou voltar rapidamente aqui. Você compartilhou suas informações de contato, então, se

59:45 se houver mais alguma coisa para conversarmos depois, entre em contato com Alex pelo LinkedIn ou pelo endereço de e-mail aqui. E sim, espero pelas próximas conversas e por encontrar todos vocês em outro lugar, se possível. Mas, fora isso, não deixem de acompanhar a próxima sessão do Neo4j Live na semana que vem — daqui a duas semanas, desculpem. Até lá, aproveitem o resto da semana, o resto do dia, e nos vemos em breve. Muito obrigado novamente, Alex, por

1:00:15 >> Obrigado. Obrigado por me receber. Até mais.

Transcrição original

[00:00] All right. Um, welcome everybody. Good evening, good morning, good afternoon. Shuffling that announcement a little bit around. Um, and welcome to another Neo Forj live. Today the topic is architecting trusted agents turning knowledge graphs into secure policy engines. And uh, my guest today is Alex Alexandre Bab. Sorry, I’m I’m I’m now stumbling over my words. Babanu. I think I I I trained I I trained this but now I’m [laughter]

[00:30] for some reason I cannot get it out. >> Get it better next time. >> Yeah, I’m sorry. I’m sorry, Alex. Um and you are the the product lead uh at Indicite uh responsible for AI um control suit um at >> super happy to have you um and um to join join us today at the at the NEOJ live stream talking about something I think that’s a little bit over overseen a little bit over a little bit maybe skipped sometimes maybe think of as as

[01:02] an afterthought or maybe you know you realize ah well Let’s let’s not do the boring stuff. Let’s do the exciting things first. And uh and then in the end you realize, oh security, yeah, trusting my agents, they can do all kinds of things now. I don’t know if they really should be doing that or if they should have access to that or if users should have access to the agents using that. So yeah. >> Yeah. It’s funny [laughter] that you mentioned the boring stuff. To me, it’s the exciting stuff. >> Yes. Yeah. Yeah. Yeah. It it should be it should be the exciting stuff but with all these tools and things and powerful you know um

[01:37] >> I think >> but you’re absolutely right developers think of security as the last the very last thing they want to do like they want to do their business stuff implement their use case whatever it is security is just an afterthought usually and and one of the problems is they when it comes to access control they eventually rely on you know roles because that’s the thing that’s been around forever and as we’ll see probably not a good idea Yeah. [laughter] >> Yeah. And and and you know GDPR, CCPA, these kind of things >> not as not as uh not as exciting

[02:11] sometimes, but um but yeah, for sure. Um it’s it’s something that you are you tackled and and you will you will show us today um a little bit in our in our in our session today to make sure that this is actually you know kept uh in line is is not going uh going away is is is taken care of but is also something that um that if if you build something there um and you want to make sure that your your agents do all the all the cool stuff that they can do but still you

[02:42] know keep in line and that that people access things that they are allowed to access and other people who are not allowed to access things are not allowed to to to access then I think this session uh is for you. You you gave a very interesting example in um in in when we were crafting the description of the of the session saying, you know, is it is it is it okay if if your agent has has the rights to summarize confidential AR files or is it is it is it fine if if somebody can see the the salary of of of leadership team or or gets access to,

[03:15] you know, crucial um files is is like, okay, you you probably should take take a look at that and think about okay, what what is what is who can access what what access what access is allowed and in what level and um and if it’s just an agent that can do it. Yeah, it’s important that the HR team can have access to their own HR files but you know the intern maybe should not have the same level of access. [snorts] Yeah, it gets even trickier with a graph rack for example where you can ask anything to the graph but yeah exactly if the you

[03:47] know confidential data is in there uh maybe you’ve embedded some documents that you shouldn’t have access to uh and we’ll see it’s tricky it’s even trickier with AI and and I’ll focus on on the AI aspect as well today because that’s probably top of mind for a lot of people. >> Yeah. >> Yeah. >> I I can imagine. Yeah. [snorts] Um cool. I think um yeah we could uh we can probably dive in um I want before handing it over to you Alex just you

[04:17] know the session is live obviously as we are as we are running it right now um if you have any questions any comments anything you see you’d like us to explore some more or you like us to give a little bit more of a of a explanation on something then please um type uh type it in chat put it in chat let us know we will have some time um towards at the end for sure to do a little bit of a Q&A or sometime in between. Um so um definitely you know the the the channel is open and and we’d like to encourage you to to make this as uh interactive as

[04:50] possible and um yeah I think with that I can uh >> Cool. >> Oh thanks thanks Alex. So, it’s Alex’s today. Uh, it’s Alex Tuesday. Uh, here in North America, it’s taco Tuesday, but you have tacos. So, uh, yeah, I’m the lead product manager for AI control suite at Indicite. So my product controls enforces access control for AI, agentic AI and AI workflows using Neo forj as

[05:23] the underlying graph and using the indicite platform which is an intelligence layer on top of Indicide that makes everything uh easy and smooth. Uh my background is actually identity and I stumbled upon graphs about 10 years ago while trying to solve some identity problems that only graph database could handle like complex relationships in IoT systems for example that was uh I even talked about this at graph connect back in 2018 who cares anyway so uh so today we’re going to talk about turning your uh graphs into

[05:55] policy engines now uh as I mentioned earlier when we were chatting uh A lot of you think about role based access control have that so we’re good right well unfortunately not um and I’m going to start this by talking about copilot Microsoft copilot um you probably know it you’re probably using it have used it uh your AI companion so why copilot why am I zeroing down on on on that uh that’s because it’s notoriously using rolebased

[06:27] access control in the back end it uses the whole Microsoft suite Active directory entra what have you all the groups and roles in there and so whatever you you you run through copilot uh well it goes through that authorization system uh now copilot is just an example but any system that us an an AI agent that you use uses roles as a backend authorization system will behave exactly the same I mean in terms of authorization of course now what’s the problem with copilot well here’s uh some results from a study earlier this

[07:00] here like two three months ago maybe three four months ago uh about this concentric AI released this report that they found a bunch of risks associated with copilot uh for example 83% of the at risk files are overshared that means if you have some files that are sensitive like most of them are overshared uh 17% were overshared with external third party even like some of your critical files may actually be accessible by external people 90% of business critical documents are shared outside the sea suite. So things that

[07:35] should be only for your seale executive eyes only are actually a lot of them are actually shared to everybody. Um 15% of all business critical files are at risk of from oversharing and 3% of active sensitive data was shared organizationwide. So obviously we have an oversharing problem uh which means that uh you have data, you have documents and the risk is that a lot of people can’t see them or access them and they shouldn’t. Why is that? I mean you

[08:07] you may think well this is Microsoft’s problem right? Well no because Microsoft tells you this is part of their documentation. You can have a look. Copilot only accesses data that an individual user is authorized to access based for example on role-based access controls. So there you have it. It’s not their fault. It’s your fault. If all these statistics that are [laughter] real, you know, real problems in organizations, not their fault, it’s your problem. But I’m here to tell you that Microsoft doesn’t make it easy for

[08:38] you because actually it makes it impossible for you. any system, it’s not just Microsoft, any system based on roles only will uh cause you the same problems. Uh and here’s why. What’s the problem with roles? Well, they multiply over time. You tend to have more and more and more roles until you end up with a system where you don’t know at all who has access to what anymore. >> And this is how it’s going to to happen. Like basically, and I’ve seen this as a consultant. I’ve seen this in the field.

[09:10] I’ve spent 10 years consulting with fortune for Fortune 500 companies, whatever. But all of them had this problem. All of them. And I’m pretty sure if you work for an organization that’s been around for a couple of years at least, yourization also has this problem with ROS, whether it’s Microsoft ROS or other. So how does this work? Uh the role explosion problem starts when you’re starting to you know starting to building building applications. uh you build an application, your developers or if you’re a developer, you create some

[09:41] roles for managing access to the data or to the features of your application and everything’s fine. A bit later on, uh your organization builds some say APIs or more applications, but you don’t want to break whatever you’ve done before. So, you’re creating more roles. After some time, uh people who created the first roles leave the company, move on, win the lottery, whatever. and you end up with roles that nobody owns anymore and nobody has any idea what they do. Uh so eventually you end up with a blind spot. All you can see is the role

[10:14] membership. We dive a little bit into that because that’s quite important. Here’s uh the example spelled out. So let’s say that you build an analytics portal uh for customers and staff to create and access and manage their own analytics based on your graph data. Something really cool. Looks good. And for that you need a couple of roles like uh for example analytics managers they can view everything and the regular users they can only see their own things. Great. So these are the roles defined in the analytics portal

[10:47] application itself right and you have now an organization directory could be enter ID Microsoft active directory your own uh uh directory LDAP direct whatever it is and there you have your group memberships and your role memberships. So for example, here we have Alice and Bob are analytics managers and Rebecca and Roy are analytics users. Great. So whenever say Bob logs in, he’s a manager. He can view and see all. Cool. Phase two, you now have uh some data

[11:20] APIs. So now you need to create, as I mentioned, a couple of new roles. You have a data viewers that can only view their own stuff and data admins that can crud everything. So because you have a new uh you know a new API you need to essentially create new roles because you cannot reuse the same roles they have different accesses right it’s not the same set of people you see for example uh Roy here would be alone I mean you can’t reuse the roles so you have to create new ones uh so you create new ones so at the end of uh in step three now you have after some time you have

[11:55] probably you know hundreds of thousands of roles actually a lot of organ organizations have more roles than than employees. So that tells you a lot those organizational directories where you have you have all the group memberships but you have no idea what the they are entitled to because the entitlements are spread out in all these apps you’ve had, right? And now enter AI. So you’re deploying this AI agent and and now Rebecca, one of our users wants to use that agent for you know some

[12:29] graph rag stuff for example or for data retrieval what have you or for running for asking analytics type of questions. Remember Rebecca was part of the analytics users and she was also part of the data admin role. So now when Rebecca prompts the AI, she has actually these entitlements, but you don’t actually see it explicitly. They’re, you know, they’re hidden in the actual underlying databases and APIs, right, that the AI can access. And so here’s your AI now that has a CRUD all access. Uh the AI is not an API. So the AI can decide on its

[13:03] own what it wants to do, what it wants to, what it based on its goals. And >> here you have an AI now that has a CRUD all access to your data. >> That may be a problem. And actually this is kind of the behavior we see in the news. The agent did something and we don’t know why. So this is a nightmare for governance for GDPR as you mentioned for any regulatory things. What happened? Well, and you see this on the news all the time that the AI dropped a

[13:34] database. it use this it it and that’s exactly the problem especially with scope pilot or any role based access control system. So what can we do? Well, hopefully oh one last thing cuz so now we’ve seen the oversharing problem but now let’s have a look at another problem which also lead to road explosion and that is the AIS as we know they need some tools to do anything they need the MCP now model context protocol has become kind of the

[14:04] the most uh popular protocol for accessing tools so we have these MCP servers so any AI agent now can find online a bunch of MCP servers each one of them you know exposing a certain number of resources and tools. So these you know resources and tools may vary from a server to another. So the question is now how many roles do you need to protect the system? You have X agents running in your uh organization like we’re talking to big banks or

[14:38] multinational companies and they have they don’t even know how many agents they have. They might have thousands for all they know. uh and you have MCP servers that are also maybe in the hundreds and how many users do you have like 10,000 even 1,000 even 100 users. So now how many roles do you actually need to protect this system? Your cardality is going to explode really fast here because if you need to secure this particular guy here [snorts] uh and Rebecca should only access this guy, how many does Rebecca need her own role for

[15:11] that? So from the get-go, you’re getting into this role explosion problem with AI right off the bat, even forgetting the other explosion you already have at hand. So you need a better system is what I’ve been trying to tell you. So again, these are the risks. So we need to shift from away from roles to dynamic authorization. So let’s have a look here at what that means. That means essentially we need to adopt the pre the paradigm of zero trust. This is

[15:43] a fancy thing that’s been going on for a while in the identity world but it it absolutely needs to happen for AI. The the main concept with zero trust is never trust always verify. So instead of relying on static roles you need to authorize every single action. every single request must be authorized at the time when it’s made in real time dynamically. That’s the only option here and we’ll see how this pans out and how you can use your graph for that. So

[16:14] before we get [clears throat] into the details, we need some background uh so everybody is on the same level and we’re talking about the same. So couple of concepts about that are more on the ident. uh maybe you know this uh just close your eyes in that case uh if you know it’s always good to have them spelled out again. So there’s two main things when we talk about access control and this apply to AI control as well. Authentication on the left and authorization. So authentication is like the main gate to your castle is the front door is where you check for

[16:47] credentials is where you log in and once you’re in you’re in you’re in the castle you’re good. authorization is uh what happens afterwards? We know who you are. You’re in the castle, but what rooms can you access? Can you access the treasury and steal steal the gold like this guy here? Uh that’s what we’re trying to avoid with AI, right? So, authorization is actually the hard problem. Authentication as we’ll see uh is easier. The first thing is that we need

[17:19] to talk about identity. you whether it’s human or machine, you need some kind of identity or at least an identifier to identify the running instances of the things that are making requests in your system. And once [snorts] you’ve got that uh you can authenticate like users usually use multiffactor authentication these days or pass keys if you fancy great and machines are typically authenticated with cryptography. So authentication is for the most part

[17:51] problem solved. Authorization though is a harder problem. So how do you do authorization? So typically that happens when uh a a subject that has been authenticated a machine or a human tries to access a resource. So zero trust paradigm says you need to verify every single request. Now to do that you need a couple of more components in your system. uh namely a policy enforcement point, a PEP, and a policy decision point, a PDP.

[18:21] These act together. The PEP is a proxy that protects every single resource that you have. Uh it’s like a proxy, could be an API proxy, an API, uh an MCP gateway, an agent gateway, some kind of a a thing that filters all traffic. Uh now note that this is valid for for the whole stack from the network all the way to the application layer. uh you can have network level peps like I don’t know switches and what have you routers and then gateways and API gateways and

[18:51] things like that. So these things capture so technic technically these are already products that exist so you can just use them. Uh so PEP will capture all traffic redirected to a policy decision point which has a set of access policies business rules implemented. So these are rules engines that reason on the incoming request and respond typically grant or deny. Now the communication between the two uh nowadays is standardized through a protocol called Ozen v by the open ID foundation. I’m one of the co-chairs but

[19:26] it’s been gaining popularity. So this enables any pep to talk to any PDP out there. So that’s what we’re trying to achieve with AI as well. We need to implement PEPs and PDPs. Now, this little uh spoiler here, spoiler alert, the PDP will be where your graph will leave and we’ll get to that. So, how do you protect agentic workflows using this concept of zero trust? So, again, back to our AI agent that uses a bunch of MCP servers. The idea then is

[20:01] to put a PEP in front of them. Uh now the good news is that there are number of uh MCP gateways that are commercially or open source even out there that can be used for the purpose. Uh we have our own uh but you can you know whichever and these should talk to a PDP a policy decision point via odds end. So every MCP request that tries to access an MCP server has to go through a gateway of some sort first which communicates with a policy decision point and then grants

[20:32] or not the request. Simple. But now uh AI can also use you know kind of legacy or REST or GraphQL API calls as well. I mean there’s a movement that says we don’t need MTP. Fair enough just protect that as well with a PEP. Uh now this is more traditional. We have API gateways out there. some are open. You can do that as well and bring them into this oddsen kind of circle of trust if you will. >> Um so that’s it. The point here is that the AI is smart but your system here must be dumb. Uh you use uh

[21:08] deterministic rules as much as possible. If you try to rely on another AI to protect the AI, can you trust that AI? And it’s AI all the way down. So anyway, ideally you want you want as deterministic rules as possible here. So what about workflows? So an agentic workflow is when several agents collaborate together to achieve a goal, a common goal. Uh and now there’s another protocol called A2A agent to agent that’s been uh put forward by

[21:39] Google last year or the year before forget the exact date but anyway now agents can communicate discover each other. They have agent cards that describe what they do, their skills and every agent can discover another agent and they can just communicate. So we have now these agentic frameworks. Uh so how do you protect them? Well, same idea. You place a PEP everywhere and down there is where you have the PDP with your the graph as a context and this is where the context is is going to be really really necessary to figure out

[22:10] the whole thing as we’ll see in a second. Uh so that’s the idea. the bare the base idea as you seen is placing peps in the right places and using a policy decision point uh to grant access. So now that we’ve seen the architecture from a high level how do you actually write those access policies and this is where I mean we call this knowledgebased access control because we use a knowledge graph and we’ll get to the details but you need to talk about access policies. So there are two uh schools of thought here. Uh we have dynamic authorization

[22:46] and static authorization. As a reminder, static authorization is for example your roles. This is what an LDAP entry looks like. If you’ve never seen one, this is what it looks like. This is what is stored in an LDAP directory. For example, Azure AD or ENTRA for example. This describes a group called HR managers. And all you can see in there is a bunch of members. It’s written in stone so to speak. LDAP directories are are very slow on write so and very fast on read. So they’re not expected to change very much very static. Uh and

[23:19] here’s how for example a role would be embedded in in some spaghetti code in some app. So for example it’s hardcoded there that in this particular app that managers can do this or that. So it’s very hard to make sense that of who has access to what because on the one hand we have these members and you have 10,000 apps each one and with their own code in there. Our access control list are very static also. This is what Linux uses or any Unix based systems. It’s how the file system is protected. Works fine on Linux but at enterprise scales it

[23:53] gets a bit more complicated. I don’t want there’s some systems that use that modern systems but I don’t want to get there now. as opposed to that. So this is bad because every one of these systems leads to explosion. Uh over time you’ll have a more more and more ACL you have more and more roles as we’ve seen. So instead it is better and actually advised to move to dynamic authorization. This is what uh these are authorization systems that rely on rules engines uh as I mentioned and rules uh you need much

[24:25] fewer rules than you need roles. Maybe you need a 100 rules and that could replace you know a thousand rules. I don’t have specs here. Depends on your use cases but much much less much more manageable. The idea is that these things uh taken as an input a subject who wants to access a res. This is all happening in real time. A subject is trying to access a resource. Here’s the context. The subject is located at this uh geol location at this time of day for example. Can they access the resource? it happens in real time and you get a

[24:57] grant and deny. Some events may happen that change the underlying data or rules or what have you. Uh but it’s okay. It’s all dynamic and happening in real time. This is exactly what we need. So uh what this looks like I mentioned between PEP and PDP we have the oddsen protocol and this is what the protocol looks like. Uh it’s essentially a bunch of JSON payloads that are exchanged. Uh this is a request and you see that the request matches uh what I mentioned here in the in the diagram. We have subject here Alice tries to access tries to read

[25:32] uh a resource called account count account count one two three and at this time of day. So now you can crunch the rules engine crunches that and says decision true Alice can access the document. Great fairly easy right? uh so what I’m saying so now because we all are graph practitioners here or should be uh as we know uh so how do we shift from rolebased access control to something that uses a graph well the first thing is to represent maybe if you

[26:04] have roles everywhere a first idea let’s put all those roles in your graph so for example this expresses the same thing this is statically written in an LDAP directory somewhere and this could be stored in your Neo Forj database uh and expresses the same thing. Uh those two users are managers. So now if we just focus on this, we’re not talking about role-based access control anymore. This is relationship based access control because we look at relationships. But

[26:36] now the beauty is that we can now represent entitlements as well. And that was the missing piece. Uh if ROS were from the get-go represented as graphs, actually they would not have been a problem. At any given time, you could have known who had access to what and you could have reused roles or you could have, you know, managed the access properly. But they weren’t for some reason. They shifted from from this representation to LDAP which actually hid everything. So now you have your entitlements, you have your managers,

[27:07] they can crude all the data API. Uh actually as a as a point I just want to point out that if you look at the people who created rolebased access control in 1992 Ferolo and in their paper that created rolebased access control this is exactly how they actually represented RO membership >> users members of Rome right >> so there was a graph from the beginning >> yeah yeah >> so why why did we end up with directories I don’t know there was something I suspect Microsoft

[27:40] >> [laughter] >> No, actually probably not true. It was It’s probably Netscape. There was a Netscape directory first. LDAV v3 happened. It gained popular. Anyway, if we kept that idea, we would be better off. But unfortunately, it’s not the case. And >> there was no database around that could do it back in 1992. [laughter] >> Yeah, [snorts] true. Actually, uh yeah, semantic web 98. So that’s what we ended up with. Um actually even a relational database could have been better because you would

[28:12] have been able to model th those guys here at least. Anyway, uh moving on. So this is what relationship or rebback access control uh works. It looks at path. So for example, if you wanted to know uh what Jay do down here had access to, all you have to do is follow the path and figure out that okay, Jay do has access to data API and document one. And you can uh and actually you can tell here in this particular example that you can read data APIs and view document one and you can expand that idea uh at at infinity

[28:48] in your in your graph right but it it’s not just roles now you’re free to use any kind of node or types as you want for example here we have organizations it’s not just roles anymore it’s whatever you want so you’re now free uh to have any kind of access controls using paths and relationships as you want in your graph. Isn’t that great? >> Um, so but we’re still missing something those environmental conditions, you know, like the time of day, geoloccation, or something that is based

[29:21] maybe on the access token presented because all of these when when you’re logging in, you get an access token and MCP insists on on OS for a authentication and authorization. And so maybe you have some some things that need to be checked. So you need some attribute conditions as well as relationships. Uh attribute condition are actually systems based on attributes are called attribute based access control systems or Aback which is also another type of dynamic authorization. Well, we need to combine the two to get

[29:51] full context and proper uh access policies. So this is what we have. Rebback on the left, Aback on the right uh equals Kback. So Kback is essentially the whole thing. That’s what we call it. We’re probably the only ones calling it that. Uh but otherwise the I think the scientific name name for this is attribute enhance relationship base access control. So ARback kind of a mouthful. [laughter] [snorts] So you have now uh the movie the all the pieces of the puzzle for uh your control system. Uh this is for

[30:26] example what the kback policy could look like. This is how we represent them. You don’t have to do it the way we do but you can as you can see here you have a cipher part which is the relationship access part and then you have some conditions on the uh that are added to that. So we could we combine that in our rules engine in order to grant access or not. So we need we check the path and if the pass checkout we also check the conditions essentially. Uh so that’s just an example of kback or a reback if you wanted to be more academic. Um so

[31:00] now you have uh your knowledge graph. It has you you should enhance it with identities, policies, re resources. So you have now a full identity and context knowledge graph. It contains not only your normal knowledge. But if you enhance it with identity and identity related context, you have a full picture that you can now use for access control and maybe to have insights such as for example who can access what which is again invisible in traditional role-based control systems. So how do you use this for AI? And this

[31:34] is the last piece of the puzzle. Let’s say that you now have those agentic frameworks and workflows and you can now model them in your graph. For example, I have here a simple graph that models a workflow with three agents, two agents and an MCP server. Say agent one, agent two, agent and MCP or agent three, whatever. So at runtime, uh we have agent one here that calls agent two and we have PEPs everywhere. So we can track all these communications. Uh so we look

[32:07] at our reference graph here. Agent one can call agent two. So so this is okay actually. But now agent two here for some reason decides to call agent 4. Well, wait a second. If we look at our graph here, agent two should never call agent 4. It should only have access to an MCP server. So, this should not be allowed. This is excessive agency. The agent two is trying to something. It’s we shouldn’t let it do it. So, that’s how that could work out. For example, uh so let’s have a look with a proper

[32:40] graph. So let’s say this is a graph that we have that represents two workflows, two agentic workflows. The first one is a data search or rack type of thing. Graph rack type of thing where uh you know we have a transaction here goes through a chatbot uh and in the case of the search it goes through a retriever agent and then uh to fetch data from the graph and then a generator to generate the answer. Great. Uh there’s also another uh workflow that is maybe a

[33:11] start compute and this one actually goes to the same chatbot but this one uh manages cloud instances maybe starting or shutting down VMs or what have you creating load balances what have you and whenever that’s done uh it communicates with another agent to notify users through Slack for example. >> Mhm. >> Great. So we have these two workflows modeled and right off the bat we can see that the cloudbot should never be able to retrieve data. There’s no relationship there. So we should be able to block that right off the bat and prevent that communication alto

[33:43] together. Now let’s have some users. So we have uh four users here. We have Alice that can actually start the search. We have a couple of salespeople that uh can actually also stop the search transaction. And we have Bob here who’s probably a DevOps because he can start the compute uh workflow which starts or shuts down VMs. Uh Roger here should not be able to start the to do that only Bob uh because again we we identify these relationships. Uh they have different types and so we can figure out which

[34:18] one’s which and have access policies as we’ve seen before to do that. And here you can go as granular as you need to be. uh you can tie this to your actual data and create the relationship rules as we’ve seen in as granular up down to the data or node property if you if you need to. Uh so that’s essentially how how this works. So now that I’ve shown you this, I just wanted to show it to you in action. >> Cool.

[34:49] >> To prove my point. >> Yeah. >> Yes. Shall we do a quick quick round of questions first or Sure. or Yeah. the And I’m sorry I’m not 100% familiar with all the acronyms, so I’m I I might be uh stumbling over them a little bit, but there was one and you mentioned this this Aback. So there was attribute attribute based access control, I think. >> Yes. >> Um and Sai asks, what’s your view on on Aback setup plus opal? And I’m assuming

[35:19] these are also abbreviations I’m not too familiar with. Um, >> opal is that the uh the OPA orchestration framework probably open policy agent. >> Yeah, that could be that. Yeah. Okay. But if you are not familiar maybe maybe Sai can can um give us a bit more what um what he actually thinks about this. I mean obviously ABACK has been around for a while as well and it’s it’s a good way

[35:50] of uh uh of implementing dynamic authorization. Uh the the the idea with attribute based access control is every all the rules are based on attributes that you can gather at runtime uh and have access. So you end up with actually much more uh rules with Aback because you you might have a lot of attributes but what you’re missing is the relationship part. Uh I think it’s quite important the the the context and OPA doesn’t have that either. Uh OPA or Opal

[36:21] if that’s what I’m thinking it is. Uh again bringing the data to OPA is complicated and you’re missing out on the whole relationship part which you can do if you implemented something like a Zenzibar system. Uh but even there the the hubs you need and the it’s like more like an ACL type of system with relationships. Uh I mean it’s good as well as long the point is I think you need the relationships to have the full context for AI. >> Yeah that’s >> yeah I think that goes similar more like

[36:54] a comment and then probably a question from from David. David says, “Abeback with alpha um is something that you could do. Alpha scales better than Cedar Cedar.” Um lots of abbreviations today. So um which I’m sorry I don’t I don’t know what what they all mean. >> Yeah. No, that’s fair. So uh Cedar is a policy language by AWS. It’s been open sourced. Uh David is if it’s the same David that I think it

[37:24] is is one of the coordors of alpha which is a standard a JSON standard for Aback based on an older standard called Zakmo more abbreviations which has XML [laughter] that one you don’t want to get into. Uh I mean again listen I mean they knows this but I think relationships are really the key component that all these other systems are are missing. they’re not quite explicit or expressive in the same way that a graph database is. Uh

[37:54] you can like what you see on the screen here. It’s hard to make sense of this uh with aback just you have to I mean David probably knows how to do it but you probably need a bunch of rules to get to the same idea uh that you know following this path here uh you know grants you access for example. >> Yeah, makes sense. Um yeah, I I see no uh no other questions, but um if you have uh any any more, especially probably maybe when uh when Alex shows

[38:25] the demo, then please please let us know um in chat and don’t be shy. Just just put them in and throw any abbreviations at me as you like. I’ll uh I’ll just read them out. [laughter] >> Nice. Yeah, put putting graph people on the spot. >> Yeah, [laughter] >> good sport. So um the demo I just want to mention that this demo is actually available uh to everybody on our open source GitHub. We have these demos are available to developers. You can run it

[38:57] locally. I’m running it locally on my machine here. Uh and you can achieve the same as me here, but I’m just going to show it to you. Uh so this is what the demo looks like. I know there’s a lot of boxes and arrows uh but it’s not that complicated. So we have a bunch of we have our graph database that is uh kind of hidden behind the indicad control pane. I’m using indicite for this because that’s my tool I have at my disposal here. But the ideas are the same regardless of of the tools you use. But Indicad’s a good platform obviously.

[39:30] So we have some agents that allow us to perform a couple of uh a few things. uh we have an orchestrator agent that takes some prompts from a from a human and the orchestration can decide whether the prompt pertains to data retrieval in which case it delegates that to a a data retrieval agent or if it’s pertaining to some documents that are show stored in Google Drive and I’ll show you that in a second. We have some Google Drive documents uh through MCP as well or

[40:00] whether the prompt pertains to the weather. I mean stupid example but this is just to showcase that you can make external rest calls to external references directly at runtime from the platform. You don’t have to store all the data in the platform. You can just point it to some other place where the data is actually stored and use it at runtime. Anyway now all these agents are pro protected by our own PEP, our own uh gateway. Uh so we have one all these peps here. Mhm. >> Uh so we have a PEP in front of our orchestrator of of our retriever in front of the Google MCP drive and we uh

[40:37] fetch the data. The retriever fetches the data from our knowledge graph through the MCP RMCP server which grants access to our oddsen tools and some queries that we have some knowledge queries which uh essentially exposes our context IQ query knowledge queries to access the data. Now all of this is protected by uh yeah the platform for authorization and from an authentication standpoint we use an external identity provider in this example it’s security

[41:09] uh and this uh identity provider authenticates users and machines uh through OS and so it also does token exchange for us. So what happens is we want to what we want to authorize is not just the user or the machine but actually the whole delegation chain. It’s the user when using the agent. That’s what we’re authorizing. So, we need to track the um authorization chain, the delegation chain all the way to the bottom in order to have a complete picture of what’s happening. So, when this human gets down to this

[41:44] retriever for example, the authentication the delegation chain should have the previous agent as well in it. So, we know that we can authorize the full workflow. Now, of course, the data comes from various sources. It could be CRM, HR, some custom databases, some documents from SharePoint. Uh, and we’ve also encapsulated some roles and all that in there that come from SharePoint. So, we have a whole bunch of stuff in the knowledge graph. Hopefully, this makes sense. So the use case here is we are an

[42:16] insurance company and uh dealing with claims and what’s important in this insurance company is the households and the relationships between household members who’s in the household their children and the vehicles they have and the vehicle insurance policies and house insurance policies and and whatnot. So so let’s have a look at what that looks like. So first of all I’m going to show you uh the actual uh data. This is the indicite platform and this is what the

[42:47] data looks like. So uh this is for example one of our customers uh James Mitchell. We we’ll see him again in a bit. Uh James uh is in the household. He’s the parent of uh Ethan. Sarah is his wife. Sarah is the policy holder of the home insurance. and they have an estate and they have a mortgage and they have a bunch of insuranceances. Great. But as you can see here, uh we’ve have been tying this to some workflow definitions here. Uh so customers James

[43:20] in particular can trigger a couple of AI workflows uh that are tied to some agents and we’ll see that in a second. Those agents I showed in uh in there and we also have some departments. Some some of our users are actually employees and some other users are customers. James is a customer. Uh but if I were to look at uh some other uh sorry clicked the wrong button here. Uh for example, where do we have millen here is an employee. So her

[43:52] view is a bit different. she reports to another person and she works the department. Whoever works in the department is an employee basically in this simple use case. >> Uh this is what the schema of the database look like. This is the u the ontology of the data if you will. So persons uh can trigger workflows, workflows have agents, uh persons working in departments and this is where we tie it all together. the the access stuff is more on the

[44:23] workflow side here tied to the data stuff which is more the insurance policy specifics. So that’s what the data looks like uh on the platform. So I have here uh an app that is our insurance app. I created this with my friend Clo. So [laughter] it doesn’t look very good. >> Yeah. So I’m first going to log in here as a user Millisent. So, Millisent is uh a customer support uh employee at at our secure home insurance company.

[44:59] So, uh this this app actually is just there to show you that uh this app just uses the rest endpoint. It uh everything you see here uses the rest context IQ knowledge queries. Uh, for example, if I have an a household lookup here, uh, hopefully if I click this, uh, yeah, for example, I can look at Sarah Mitchell. It’s very static, you know, but at the bottom here, I have a little chat window. And this little chat window um, actually triggers the workflow I showed

[45:34] you in the slide earlier. So, here I can ask a question and it will trigger the whole workflow. Uh so for example just to make sure our AIS know uh who I’m actually logged in as uh I’m just going to ask it who am I and you’ll see here a bit of a a trace log from all our PEPs our gateways. Uh so the request went through first gateway millent went is authorized to access uh the orchestrator agent. She’s authorized to access the retriever agent and she’s authorized to

[46:04] access the MCP server. Uh and yeah we have an answer. This went through the MTP server which got the data from the knowledge graph. You are medicent a customer service representative. Great. So now uh as you see this data here that that I got from rest is very static. Uh but she has a question from James uh the customer and uh James is calling about the home insurance for his house at 123 Oak Avenue. What can he see about the policy? So he’s asking a question uh

[46:36] because he’s not seeing something. He wants to know why basically uh instead of looking at the static thing well just asked the AI. So this goes through this actually runs on my machine while it’s thinking. I can show you uh what this looks like when you run this. It’s it’s doing a bunch of things. So it’s going through the whole workflow here. And as you can see, uh, James, uh, just sees some basic house coverage here. Uh, but let’s see.

[47:10] James, we know that, uh, uh, he’s married to Sarah. So, let’s let’s have a look at what Sarah can see and and see if we can determine why James doesn’t see some things that he sees. So again, this square is the graph in the back end and u hopefully we’ll get something. There we go. And Sarah can see a bit more things. You see uh James can only see the coverage but Sarah can actually see numbers because she is the policy owner. So actually why that’s the question that James had when he called in the first place. Why can’t James see

[47:43] the premium? So again my static thing didn’t answer that question. I mean I can see the household >> uh but I cannot say why James doesn’t see the premium. So this is why we’re asking our friend EI. >> Uh James cannot see the premium for his home because according to the system records he does not currently have an active home insurance policy. His spouse has the premium. So he cannot see it because his spouse has uh the thing. >> I see. No. >> Now uh this family has a bunch of uh children. They are of driving age. Uh so

[48:19] I know in our Oh, I should show you the Google Drive. We have a Google Drive here with some shares. So these are some documents uh in Google Drive and they’re actual documents. They’re demo documents. They’re not uh but these are documents that pertain to customer insurance. There are some other documents that come from SharePoint that have been embedded and stored in the database. Uh but this this question pertains to uh the the customer related policies uh insurance policies in our Google Drive documents. Our car sharing

[48:53] drivers covered in our umbrella liability product. It’s probably a question that makes sense for insurance practitioners. Um so now there’s one thing uh let’s see let’s see it crunch. So this what happens here is you see the the flow here is different. Now we went through a different flow uh in agents because now we’re accessing the Google drive. So we have a different set of agents that that are called upon and are being authorized in real time and we got an answer. Not going to read it. Now there’s one thing

[49:25] here that uh I want to mention is we have a company policy that persons and vehicles this thing here that I can access rest this list here should not be available to AI at all. So for example, if I ask can you give me the list of persons and vehicles which should really return this list, right? This persons and vehicles.

[49:57] Let’s see what happens. Again, we have a policy that says AI should not access that. >> Yeah. >> And let’s see what happens. I’m sorry, I couldn’t find any information regarding the list of persons in services. So based on context uh we can or not authorize uh if it’s AI or not AI we can authorize at the fine grain grain level here using you know the the all the stuff I told you about. So let let’s have a look at what a customer would see here if I log in as James. Uh give me a

[50:28] second here credential. So here I’m going to log in as James. So, James, whoops. Ah, sorry. Wrong paste. There we go. So, James has a different view of the app. Obviously, it’s got a very limited view. He can only see his own household. Great.

[50:59] >> Of course. Yeah. >> Yeah. So, now let’s have a look at this. He’s also access to the um assistant. Remember I I showed you that there were some relationships there. Um so for example here uh let me ask you the same question. Can you give me the list of persons and vehicles? Now in this particular case uh James should be able to access details from his own household. So it’s different policy that will trigger here.

[51:30] >> Um >> so hopefully he should be able to just see his household. Yep. Uh so again the power of the context here uh hopefully [laughter] >> yeah thanks oh couldn’t find information well worked earlier uh but anyway [laughter] the data is protected it should have triggered another but let’s see if we can uh ask the same question about the Google drive uh

[52:03] because the Google drive is actually a protected resource by the company. So James should not be authorized to access that drive at all. Uh so as you can see here, not allowed. Interestingly, it’s still triggering. Well, that’s [clears throat] problem with my workflow, I think. Uh anyway, let’s see what happens. I think the the orchestrator is trying various uh things here now. >> Yeah. Yeah, they can get very creative to uh [laughter] >> interesting. You know, I tried this

[52:35] before uh our session and it was working as I would expect. But this is the problem with you never know what it’s going to do. Uh it’s still thinking if we’re looking at this. >> It got the answer now I think. >> Oh, it got Yeah, based on available policy documentation, the secure home premium. So, it got this from uh Okay, there’s not explicit mention. So it tried to get this from the database. Interesting. I think it’s inventing stuff now. >> Wow. Interesting. It was not authorized to access the Google drive though. That’s the important part. So it tries

[53:07] to get something from our MCP. Uh that’s not an answer in MCP. Interesting. So this is where uh you see in real life in this didn’t happen in my test before. Um so there you have it. So that that’s in essence what that would look like. Uh if I go back to my that’s the gist of what I wanted to show you. So you can what we’ve seen here is that uh using context and and proper access controls you can really protect your data like the stuff you’ve seen at the end is not in the

[53:40] database. [laughter] >> Yeah. >> So double check what AI tells you. Um so to conclude really always verify never trust anything. So verify every little request. No more role based access control. Please use your graph. Uh and use open standards wherever possible. OS odden and externalized authorization because those external authorization systems will provide you all the things you need for governance as well. Uh they will tell you why something happened. There’s an audit trace. Uh if you want

[54:14] to know why an agent did something, you can actually find the answer to that. And last thing, you can try whatever I showed you for yourself. It’s this GitHub repo that you can have fun with. >> That’s it. >> Cool. Super. Thank you very much, Alex. Um the link to the repo is obviously um in the YouTube video description. So if you if you look for it and I’ve posted it in chat as well. Um we are close to end of the the time we have available but Alex there is one more question coming in in chat from Phil which I’d

[54:44] like to to read out and maybe you can you can have a stab at answering this. So, Phil asks um if enterprise authorization is represented as a knowledge graph using arbback and rebback relationships, can AI agents be modeled as first class graph subject whose permissions are derived from the same authorization paths as human users rather than through a separate agent permissions framework. >> Uh yes, actually there’s no separate framework uh here. uh what you see what I showed on the normal app the static

[55:20] user you know web app >> that’s for humans and uses exactly the same policies I don’t have different policies it uses exactly the same graph uh but it the context the policies are such that in the case of AI they they provide different outcomes so yes it is possible and actually this is exactly how it’s been implemented >> yeah Cool. And then a good a good uh comment from from Ross on on on the on the you know behavior I think we just

[55:52] saw is the AI agents are nothing if not persistent and often uh inconsistent. It’s amazing technology that’s very true. [laughter] >> So yeah you should never trust it right which is why you don’t want to protect AI with AI for example. >> Yeah yeah for sure. Um and then we have one more question from Michael. Michael asks, “Can this be used with a and that’s another abbreviation throwing at me, DIDCOM based agent network?” DID >> I don’t know. >> Okay. Did so this is this refers

[56:24] probably to distributed identity. Uh didcom would be probably a method. Uh yes. Uh in fact uh we uh in my before indicator I did a demo uh CTO startup called three edges and we did a demo exactly like that where uh verifiable credentials we we use did web I don’t I don’t know didcom but hopefully similar enough verifiable credentials are uh cryptographically stamped uh JSON payloads if you if you will that can be distributed to attest

[57:00] something say for example use case is I have a certification for plumbing and I have this certificate on my phone wallet and I can share it with someone. An agent could carry similar things. Uh you know I’m an agent. I have my verifiable credential that uh you can trust me because it’s been issued by these people that you trust and yeah you can represent a credential like that in the graph as as a node and actually it’s pretty powerful because you can relate to issuers to holders to verifiers and you can track in real time the whole

[57:36] evolution of these credentials. So absolutely it would be a great way to and I I have a demo somewhere from my good old days when we’ve actually done that. >> Super. Um that leaves me with one minute. Um I’d like to announce the next stream we’re doing on the 30th of September. So that’s in two weeks time where Jose will join me um and um we’ll talk about agent memory for.net persistent AI agent memory engine. So that should be a a fun

[58:08] fun session on agent memory for specifically for uh uh for the agent memory um you know solution on.net um nodes um obviously um is is approaching ever ever so uh fast fast coming to our way. So I’d like to share um also road to nodes with you. We have announced the agenda to notes 2026. So if you’re interested in that, check out the notes website. If you’d like to participate in a bunch of hands-on workshops, they are also starting in two weeks time on the 1st of October running

[58:42] all of October with interesting hands-on sessions. So that’s uh coming your way as well. Please register uh in the link I shared in chat. And yeah, if you are now wondering what to do next and how to dive in, obviously try out the repo um from Alex that that is shared. give give your um give your um security system a graph back end to um to prove the the access paths. Um if you want to learn more, graph academy is there for you. And if you want to just play with Neo

[59:14] forj and don’t have to worry about anything, Neo Forj or free is a great place to to get started. And yes, I think that’s it at the time at the end of this session. was a very very cool um overview, very very interesting demo and uh and very interesting concept. So thank you very much Alex for for showing that off and for for giving us this insight. Um you you shared your your and I’ll let let me quickly pop back here. You shared your um contact means so if

[59:45] if there’s anything else as a follow-up, please reach out to Alex um on LinkedIn or via the email address here. And um yeah uh looking forward to um to the next uh conversations and to meeting you all somewhere else um if possible. But other than that definitely tune in next week uh two weeks time sorry uh for the next session on Neo forj live. Until then have a good rest of the week rest of uh um the day and um see you soon. Thank you very much again Alex for

[1:00:15] >> Thank you. Thanks for having me. Yep.