Hi everyone, I hope you had a great start to the year! We’ll have our next DeAI call this Thursday; are there any specific topics you’d like to discuss or is there anything you’d like to present?
Hi everyone, during this week’s call I’d like to continue our discussion on administrative and organizational topics for the group. Which other items would you like to see on the agenda?
Folks, I’d like to participate in the 2026 meetings, including the next one you are mentioning Mr. Norris.
Is there a fixed cadence, and how can we join this next meeting?
Thanks,
Joseph Hurtado
Founder Granata Consulting
CTO Satoshi Notes
Hi @josephgranata , that’s great 
The calls are each Thursday at 3pm CET in the ICP Discord’s voice channel. This link should take you to the event in the Discord: ICP
Thanks a lot, I will be there as much as possible.
Which other items would you like to see on the agenda?
I was wondering if anybody has looked into just bringing existing TEE-based AI services onto ICP? Near AI and Phala seem to offer a simple API for various models and verification in a canister seems very doable. People could pay in cycles or bring their own API keys. Seems to me this would truly bring AI onto ICP.
There are various cross chain solutions like this.
You could have the TEE proofs run on-chain in ICP.. just different trust assumptions.
With TEE you need to trust that the vendors making the TEE did not cheat..
you need to make sure the provider does not cheat (easy to break TEE with physical access)..
etc.
This depends on the dapps customers.. and on what they are willing to trust.
Pure on ICP means same trust assumptions as the IC itself.
Maths based (zkML) like we do with Jolt Atlas is good for smaller models.. or in cases where you are willing to wait a few minutes to make sure, cryptographically sure, that the model did what it said it did. Also for privacy use-case. “I don’t want to send my data to anyone when running this model…” NO one!!!
Pure on ICP means same trust assumptions as the IC itself.
I do see the appeal of having fully on-chain or ZK-proven models. But obviously they aren’t able to run state of the art models, so I think the use cases will be different. I saw there’s an LLM canister without any verification, which certainly seems worse than TEE in terms of trust guarantees.
easy to break TEE with physical access
I don’t think that’s true, which is the whole point of TEEs. My understanding is you’d need to extract the private key from the chip with some fancy probably not yet developed technology.
I believe you can verify that a specific docker image is being executed securely. Therefore, you could encrypt the prompt on the client side and only decrypt it inside the TEE.
I agree with most of your view.
My wording was a bit of an oversimplification.. not ‘easy’ but doable.
The IC itself uses TEE now as well. So likely the best solution is all of the above!
Hi @marceljuenemann , for an IC project which is working with TEEs (and has integrated them with canisters), please take a look at the ICPanda’s Anda framework: GitHub - ldclabs/anda: 🤖 An AI agent framework built with Rust, powered by ICP and TEEs.
Hi everyone, are the specific items you would like to discuss or present during this week’s call? One topic to discuss will be DFINITY’s Mission 70 
Hi everyone, during this week’s call Lorenzo and Cris will present ICclaw 
See you all then
Hi everyone, thank you for today’s call! Special thanks to Lorenzo and Cris for introducing ICclaw 
Please find the Manifesto for ICclaw here: Discord
Also posting the Manifesto content here for easy access:
ICclaw
A Manifesto for a Self-sovereign AI Assistant
Executive Summary
Most “autonomous agents” today are toys for developers and liabilities for everyone else. They assume a terminal, expose and leak data by default, and externalize the blast radius onto users who don’t understand what they’ve installed. It’s time now for a private, Self-sovereign AI Assistant, able to run on a tamperproof infrastructure hence able to fix all this mess.
Analysis of the current status
- What’s actually on the market You’ve basically got three overlapping buckets: - Dev‑centric local agents: Cline, OpenDevin, Open Interpreter, OpenHands, SuperAGI, etc.—all built around code repos, terminals, and editor integration.[1][2] - Frameworks / orchestration layers: LangGraph/LangChain, AutoGen, CrewAI, MetaGPT, SuperAGI—SDKs that let engineers assemble multi‑agent systems and toolchains.[3][1] - Productized “agents” and GPT‑like assistants: OpenAI GPTs, browser agents, SaaS “copilots” that expose some autonomy but keep users inside a web UI.[4][5] StackOne’s recent landscape counts 120+ agent tools across ~11 categories - frameworks, browsers agents, RPA, dev tools, CRM agents, etc. - which tells you the space is saturated on supply but thin on coherent primitives.[6] In that mess, OpenClaw sits squarely in the dev‑centric local camp: it runs on your machine or server, talks directly to your terminal, reads/writes files, and executes commands with custom “skills” that can reach deep into your environment.[7][8]
- Why “normies” can’t use this stuff The usability problem isn’t an accident; it’s a design bias. - Most open agents assume you can clone a repo, install dependencies, and run CLI commands (
openclaw onboard --install-daemon, edit.env, set API keys, etc.).[9][7] - Even “friendlier” setups still mean: port juggling, API key management, config files, and background daemons—things normal users neither understand nor want to debug.[9] - Web UIs (like OpenClaw’s dashboard) help after the daemon is installed and configured, but the first mile is still terminal‑gated.[7][9] The result: “agents” today are effectively developer tools masquerading as productivity tools. For non‑technical users, the choice is either: - Entrust everything to a closed SaaS assistant (GPTs, etc.), or - Learn just enough devops to run a local ticking time bomb. There is almost no middle ground that gives non‑technical users sovereignty without expecting them to become sysadmins. - The security reality: agents are root‑kits with good UX You don’t need to hypothesize risks; they’re already documented. - OpenClaw‑style setups give agents terminal access, filesystem read/write, environment variables, and network access via “skills”.[8][7] - OpenClaw’s own skills ecosystem has become a malware supply chain: security researchers and journalists have documented hundreds of malicious or abusive skills in the marketplace.[10][11][12][13] - AccessNow’s “Artificial Insecurity” piece calls this out as a structural problem: AI agents that can execute commands, access private data, and talk to external services create a “root permission problem” and a “lethal trifecta” (private data + untrusted content + external comms).[14] This is reflected in policy/regulatory radar too: - The European Data Protection Supervisor flags “Agentic AI” as especially dangerous because agents often require extensive access to device data and can bypass standard APIs, raising privacy and security risks beyond standard LLMs.[15] - AI privacy/security incidents jumped ~56% in 2024, with a large share involving cloud storage and third‑party vendors; plugin/tool sprawl is explicitly identified as a driver of breaches.[16] Translation: current agents are basically programmable exfiltration engines bolted onto your machine or your SaaS stack, and the default access pattern is “everything, all the time.”
- Data collection and breach dynamics On the data side, you’ve got three overlapping, ugly layers: - LLM providers: prompts, responses, and metadata can be collected, logged, or used for training unless you’re on the right tier and have the right switches flipped. Multiple incidents have shown “AI” features repurposing user data in ways users didn’t anticipate.[14][16] - Plugins/tools/skills: a non‑trivial fraction of AI privacy/security incidents come from third‑party tools - VPN extensions claiming “AI security” that instead harvest LLM prompts and responses to sell to data brokers, for instance.[16][14] - Cloud concentration: over 80% of breaches now involve cloud storage/processing; piling “all your data + an agent with tools” on top of that just increases the blast radius
when (not if) something breaks.[16] In other words, the “AI assistant” UX hides a supply chain where: - Vendor 1 runs the model, - Vendor 2 runs plugins, - Vendor 3 hosts your data, - Vendor 4 sells some telemetry about all of this. Users experience “one assistant,” but from a threat model perspective they’re interacting with a multi‑tenant Rube Goldberg machine [20] - Multi‑account pain: fragmentation as a feature (for vendors) To get something minimally useful today, a user juggles: - An LLM provider account (OpenAI/Anthropic/Gemini, etc.). - Accounts or API keys for each integrated SaaS (calendar, CRM, email, storage, ticketing). - Often, another account for the agent framework’s hosted UI or hub. Lists of “top AI agents” are explicit about this: to orchestrate across tools and services you either wire everything yourself via API keys or pay a hosted platform to wire it for you.[5][4] This fragmentation isn’t an accident; it’s exactly what keeps users from being able to move their agent somewhere sovereign. Every extra account and plugin is another anchor. From the user’s perspective, the pain points are: - Re‑authenticating and re‑connecting the same services in multiple assistants. - No unified policy surface: each agent or GPT has its own permissions, retention, and logging semantics. - No single audit trail: “what did my agents do with my data this month?” is not a question any mainstream system can answer in one place.
- Where your “current state of affairs” should push ICclaw If you’re honest about this landscape, the pitch for ICclaw almost writes itself, but only if you dare to be the opposite of the current norm: - Norm: terminal‑first, local agents with broad, opaque powers; tool marketplaces as unvetted attack surfaces; fractured accounts; opaque data flows.[11][10][7][9][16] - ICclaw stance: - No shell, no filesystem, no generic HTTP in the sovereign core—ever.
- One control plane per person, with cryptographically anchored, append‑only logs of what the agent did and which tools it used. - Tools as narrow, typed capabilities with signed manifests and allowlist‑first governance, not random scripts from a marketplace. - A first‑class answer to “what data do my agents see and where can they send it?” instead of hand‑wavy privacy pages. If you describe the current market honestly - CLI gated, dev‑only, permission‑maximal, and casually leaky - then ICclaw has to be the architectural inversion of that.
ICclaw, A Self-sovereign Assistant: Intent and scope
ICclaw is an open-source project that takes the core control-plane from OpenClaw and the operational rigor from II-Agent, and implements a self-sovereign personal agent that runs primarily on the Internet Computer (IC). The objective is not to replicate OpenClaw’s host-level “computer-use” (filesystem/shell/browser automation). Instead, ICclaw focuses on: - Sovereign state (memory, history, policies) stored and executed on-chain. - Capability-based tooling (allowlisted tools, least privilege). - Auditability (tamper-evident interaction and tool execution logs). - Privacy and data-security by architecture (no shell, no local filesystem access in the canister). OpenClaw itself explicitly recognizes the security risk of giving agents shell-level access (“spicy”) and recommends tight scoping/sandboxing/audit. ICclaw’s thesis is: remove that entire risk class by design in the on-chain core.
Sources
[1] Top 11 Open-Source Autonomous Agents & Frameworks in 2025 https://cline.bot/blog/top-11-open-source-autonomous-agents-frameworks-in-2025 [2] OpenHands | The Open Platform for Cloud Coding Agents https://openhands.dev [3] Best Open-Source AI Agent Frameworks to Try in 2025 Alternates.ai - AI Agent Marketplace [4] Top 10 AI Web Agents in 2025 — Ranked by Usage & … 🌐 Top 10 AI Web Agents in 2025 — Ranked by Usage & Popularity (Free & Paid) - DEV Community [5] 2025 List of Autonomous AI Agents: Ranked & Rated 2025 List of Autonomous AI Agents: Ranked & Rated [6] The AI Agent Tools Landscape: 120+ Tools Across 11.. The AI Agent Tools Landscape: 120+ Tools Mapped [2026] | StackOne [7] OpenClaw: A Practical Guide to Local AI Agents for Developers (2026) A Practical Guide to Local AI Agents for Developers — AI/ML API Blog 🔥 [8] Skills Skills - OpenClaw [9] How to Use OpenClaw: The Ultimate Guide to Setup and AI https://quantumbyte.ai/articles/how-to-use-openclaw [10] From Magic to Malware: The OpenClaw Skills Supply Chain Risk From Magic to Malware: The OpenClaw Skills Supply Chain Risk | SecureMolt [11] OpenClaw’s AI Skill Marketplace Riddled with Malware, Security … OpenClaw’s AI Skill Marketplace Riddled with Malware, Security Experts Warn | Trending Stories | HyperAI [12] OpenClaw’s AI Skill Marketplace Riddled with Malware … OpenClaw’s AI Skill Marketplace Riddled with Malware, Security Experts Warn | Trending Stories | HyperAI [13] Hundreds of Malicious Skills Found in OpenClaw’s ClawHub https://www.esecurityplanet.com/threats/hundreds-of-malicious-skills-found-in-openclaws-clawhub/ [14] Artificial Insecurity: how AI tools compromise confidentiality https://www.accessnow.org/artificial-insecurity-compromising-confidentality/ [15] Agentic AI | European Data Protection Supervisor https://www.edps.europa.eu/data-protection/technology-monitoring/techsonar/agentic-ai_en [16] AI Data Privacy Concerns - Risks, Breaches, Issues in 2025 AI Data Privacy Concerns - Risks, Breaches, Issues In 2025 [17] LLmHub-dev/open-computer-use GitHub - coasty-ai/open-computer-use: The Open Framework for autonomous virtual computer agents at scale, fully open-source, safe, auditable, and production-ready. [18] Autonomous AI Agent Market Insights 2026, Analysis and Forecast … Autonomous AI Agent Market Insights 2026, Analysis and Forecast to 2031 [19] Building AI Agents with OpenClaw https://www.youtube.com/watch?v=xzoF8q0jshE [20] Rupe Goldberg machine Rube Goldberg machine - Wikipedia
Hi everyone, I hope you’re having a great start to the week! Are there any specific topics you’d like to discuss during this week’s call?
Wasm memory and instruction limit constraints and novel work arounds
Hi everyone, I hope you had a great Easter weekend! How would you like to proceed with the group calls?
And as I don’t find the time to organize sessions anymore; would anyone like to take the group lead?
Not related to organize the session. With small models coming with higher accuracy specially Gemma 4. Something worth checking to run Models
Following is Wasm browser based webgpu inference, which I think can be ported to ICP given that canister limitations increase. Thoughts ?
Well ofcourse it has to have a node with a single GPU, this can be an experimental test since the ICOS can run on any cloud / server machine
Then we can create a subnet with cloud machine, running couple nodes to run inference on webgpu / evm
The market size of inference is massive : Chutes is running on bittensor subnet