Collected sources and patterns will appear here. Add from search or the patterns library.
Trust-gated self-extending agent tool runtime. Tools (remote MCP + local functions) are discovered at runtime but admitted only after composite classical+post-quantum signature verification; designated calls are gated by human approval. Runs on a graph substrate with conditional routing and reducer state. Star atom: composite-signature-verification between discovery and admission.
Three scenarios: (A) admit a valid local tool and auto-run it (not on the gate list); (B) block a tool with a bad signature at admission; (C) register a valid gated remote tool and block execution until human approval resolves it.
# Trust-Gated Autonomous Tool Plane (TG-ATP) A trust-gated, self-extending agent tool runtime for regulated and defense-grade environments where agents cannot blindly trust runtime-discovered tools. ## Overview Agents must adapt by acquiring capabilities at runtime, but executing unverified code or calling arbitrary remote APIs is a severe vulnerability vector. TG-ATP enforces a zero-trust model: it discovers both local Python operations and remote MCP endpoints, but admits them to the active toolset only after they pass a dual-layer cryptographic check (classical Ed25519 + post-quantum ML-DSA/Dilithium). Designated high-impact tools are then gated by human-in-the-loop approval. State is maintained by key-wise reducers and navigated by state-based conditional routing. ## Architecture (data flow) Local callables run through type-hint schema extraction; remote MCP URLs run through dynamic MCP discovery. Both yield tool definitions which, with their composite public key and signature, go to composite signature verification. Only verified definitions merge into the safe pool via reducer state merging. The agent plans an action producing a tool call; conditional routing decides whether it needs approval. Designated calls are intercepted by HITL approval (yielding a deferred tool call); approved calls execute and feed results back into state, restarting the cycle. ## Components 1. Dynamic MCP Tool Discovery — MCPServerURL -> List[ToolSchema]. Sources: conductor-oss/conductor, opensumi/core. 2. Type-Hint Schema Extraction — Callable -> ToolDefinition. Sources: camel-ai/camel, modelcontextprotocol/python-sdk. 3. Composite Signature Verification — (CompositePublicKey, CompositeSignature, MessageBytes) -> VerificationStatus. Sequential classical then post-quantum. Source: open-quantum-safe/oqs-provider. 4. Reducer-Based State Merging — (State, StateUpdate) -> State. Sources: langchain-ai/langgraph, langgraphjs. 5. In-the-Loop Tool Approval — ToolCall -> DeferredToolCall. Sources: agno-agi/agno, pydantic/pydantic-ai. 6. State-Based Conditional Routing — State -> NodeId. Sources: langchain-ai/langgraph, langgraphjs. ## Build A self-contained Python reference (tg_atp.py) provides dataclasses (ToolDefinition, CompositePublicKey/Signature, ToolCall, DeferredToolCall, State); DynamicMCPToolDiscovery over a mock registry; TypeHintSchemaExtractor deriving JSON Schema from signatures; CompositeSignatureVerification doing sequential classical+PQC checks; ReducerStateMerging; InTheLoopToolApproval keyed on a designated-unsafe set; StateBasedConditionalRouting (INIT -> PROCESS_REGISTRATIONS -> AUTHORIZE_CALLS -> AWAITING_HUMAN_DECISION -> EXECUTE_APPROVED_CALLS); and a TrustGatedAgentRuntime coordinator. ## Acceptance Check Three scenarios: (A) admit a valid local tool and auto-run it (not on the gate list); (B) block a tool with a bad signature at admission; (C) register a valid gated remote tool and block execution until human approval resolves it. ## Honest status Architecture and atom boundaries are sound. The reference build mocks signature verification with SHA256 digests; production requires swapping in a real composite (Ed25519 + Dilithium) verification library. Star atom: composite-signature-verification inserted between tool discovery and admission.
Generated with Gerolamo — competitive technical intelligence
gerolamo.org