Directory context | AI Agent and MCP Security

SourceryKit

Verifies an AI agent's outbound requests and MCP handoffs against a source of truth using zero-knowledge proofs, so a call only goes out if its claims check out; hooks the HTTP libraries, logs each outbound call, and blocks endpoints not on the trusted allow-list

Direct answer

What is SourceryKit?

SourceryKit is included in the Awesome MLSecOps AI Agent and MCP Security directory. The community-maintained README describes it as: “Verifies an AI agent's outbound requests and MCP handoffs against a source of truth using zero-knowledge proofs, so a call only goes out if its claims check out; hooks the HTTP libraries, logs each outbound call, and blocks endpoints not on the trusted allow-list.” Its MLSecOps relevance is the security of agent identities, tool permissions, memory, credentials, approval paths, sandboxes, runtime actions, or MCP integrations. The linked first-party source is the ProvablyAI/sourcerykit repository on GitHub. A technical review should test the project's documented evidence across four criteria: Tool-level authorization, Memory and context controls, Sandbox boundaries, and Audit and approval workflows. Compare that evidence with the intended architecture and threat model. Catalog inclusion establishes relevance to this security category; it is not a certification, comparative ranking, or endorsement. Confirm current capabilities, maintenance, licensing, limitations, and deployment assumptions in the first-party documentation before adoption.

Verifies an AI agent's outbound requests and MCP handoffs against a source of truth using zero-knowledge proofs, so a call only goes out if its claims check out; hooks the HTTP libraries, logs each outbound call, and blocks endpoints not on the trusted allow-list

Neutral catalog description synchronized from the Awesome MLSecOps README

Before adoption

What should teams verify about SourceryKit?

Answer these questions from current first-party documentation and testing evidence rather than relying on the directory listing alone.

  1. 01

    Are identities and least-privilege permissions enforced for every tool action?

  2. 02

    How are memory, untrusted context, credentials, and indirect prompt injection controlled?

  3. 03

    Which filesystem, process, network, and service boundaries are isolated?

  4. 04

    Which actions require approval, and do unavailable policy services fail closed?