Search projects, hackathons, sponsors and tech

    ← All projects

    LATCH

    Authorization and access control for AI workers inside organizations.

    Demo

    About

    LATCH is an authorization and access control system for AI workers inside organizations. It helps companies give AI agents specific jobs without giving them unlimited access to company tools and services. Each AI worker gets its own verifiable identity and specific capabilities through ENSv2. For example, a Procurement Agent can handle purchase requests, while a Research Agent can search for information. One agent cannot simply use another agent’s permissions. Before an AI worker can perform an action, LATCH checks who the agent is, whether it has the right capability, and whether the exact action follows the organization’s policy. Companies can use normal server side policies or Chainlink Confidential Workflows when sensitive rules, such as spending limits or approved vendors, need to remain private. LATCH can also be used by other AI workflows. Through Bazantic, I created a reusable procurement Recipe that combines Exa for product sourcing with LATCH for authorization. LATCH also uses Tavily for authorized research tasks. The main idea is simple: AI agents should be able to work for organizations, but only within the authority they have been given. Give AI workers a job, not the keys to everything.

    How it's made

    LATCH is built as an authorization layer that sits between an AI worker and the tools it wants to use. When a user gives an agent a task, Gemini first turns the request into one structured action. It can only choose from capabilities that LATCH supports, such as procurement.purchase or research.search. Gemini only understands and proposes the action; it never decides whether the action is allowed. Each worker has an ENSv2 identity under its organization’s namespace. LATCH reads fresh ENS records to verify the worker’s wallet, role, status and capabilities before every protected action. This means permissions are tied to an onchain identity instead of only being stored in a normal application database, and an organization can revoke a worker’s authority. After ENS verification, LATCH checks the exact proposed action against the organization’s policy. Organizations can use normal server side policies or Chainlink Confidential Workflows. With Chainlink, sensitive rules can be loaded and evaluated inside a TEE, while the agent only receives a simple approved or denied result instead of learning the private policy itself. For execution, the Procurement Agent handles authorized product sourcing, while the Research Agent uses Tavily only after receiving the research.search authorization. I also exposed LATCH through a Bazantic Gateway and built a reusable procurement Recipe that combines Exa for real product sourcing with LATCH for authorization. A key security detail is that LATCH binds authorization to the exact proposal. An agent cannot get one product, quantity or capability approved and then execute a different action with that approval. The application is built with Next.js and TypeScript on the frontend, with a NestJS API and MongoDB for application data and audit records. Overall, ENSv2 handles worker identity and capabilities, Chainlink handles private policy evaluation, and LATCH connects those checks to external tools so an AI worker only gets the authority needed for its specific job.