@nileshchakrabortyTalos Protocol: a trust layer for AI agents. Nilesh, San Francisco
I'm Nilesh Chakraborty, co-founder of Talos Protocol in San Francisco. We're building a security-auditable agent-to-agent protocol: cryptographic identity for agents (DIDs), time-limited capability tokens scoped to specific tools, end-to-end encryption using the Double Ratchet, and a tamper-evident audit log. There's an SDK for TypeScript, Python, Java and Go, a Rust core, and an MCP connector. Day to day I work with Claude, Claude Code, Cursor, Ollama and Vercel.
We're also extending Talos to agent transactions on the Universal Commerce Protocol, with merchant allowlists so agents can only check out where they're meant to. I'm still working out how to make the security model easy enough that builders adopt it without friction.
What I'd love from this community: feedback from anyone shipping agents that call tools or move money. What would you need to trust an agent with real permissions?
Comments2
Welcome to Lounge, Nilesh. Time-limited capability tokens scoped to specific tools feel like the right primitive, but the adoption question is real. Where do you see the friction hitting first: issuing and revoking tokens, or builders deciding the scopes for each agent?
I think the bigger friction will be builders defining the right scopes for each agent. Issuing and revoking tokens is largely an infrastructure problem that can be abstracted away. The harder challenge is understanding what permissions an agent actually needs, especially when workflows are dynamic and agents delegate tasks to other agents. That’s something I’m exploring with Talos Protocol. I think we’ll eventually need a combination of least-privilege defaults, dynamic capability delegation, and runtime policy enforcement rather than expecting developers to define every permission upfront.
2 comments
Welcome to Lounge, Nilesh. Time-limited capability tokens scoped to specific tools feel like the right primitive, but the adoption question is real. Where do you see the friction hitting first: issuing and revoking tokens, or builders deciding the scopes for each agent?
I think the bigger friction will be builders defining the right scopes for each agent. Issuing and revoking tokens is largely an infrastructure problem that can be abstracted away. The harder challenge is understanding what permissions an agent actually needs, especially when workflows are dynamic and agents delegate tasks to other agents. That’s something I’m exploring with Talos Protocol. I think we’ll eventually need a combination of least-privilege defaults, dynamic capability delegation, and runtime policy enforcement rather than expecting developers to define every permission upfront.