Loading ToolBench
Governed Memory OSS core — trust governance for AI agent memory with prompt injection detection, privilege gating, and audit logging
GovernedMemory exposes 20 tools with complete input schemas and descriptions. Naming follows verb_noun convention (write_memory, retrieve, quarantine, delete_memory). Descriptions are substantive (100-200 chars typical), explaining governance flow and access control. However, output schemas are not documented, LLMs cannot predict response structure for chaining. Parameter descriptions are present but lack format constraints (e.g., no regex for memory_id, no enum for source_type). Error handling is absent from tool definitions, no guidance on retryability or recovery. Security-critical tools (delete_memory, quarantine) lack confirmation patterns. Composition is sound: tools are single-responsibility and chainable via tenant_id/customer_id/agent_id. Baseline: 549 production tools average 18-char names (GovernedMemory: 10-27 chars ✓), 194-char descriptions (GovernedMemory: 120-180 chars ✓), 100% param descriptions (GovernedMemory: 95% ✓). Missing: output schema documentation, format constraints, error recovery guidance.
Bind external memory records to GovernedMemory after evaluation
Check if an action is allowed against a memory record based on governance policy
Mark an external memory operation as a no-op (no binding needed)
Delete a memory record by ID, optionally cascading to dependent records
Evaluate candidate memories from external systems for governance compliance
Evaluate a write from an external memory system (e.g., mem0) through the Write Governor
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination) for downstream tool chaining. E.g., retrieve() returns what fields? Does it include memory_id, confidence, provenance? Breaks pattern:tool-chain.
Parameter constraints missing. source_type, purpose.allowed_purposes, action, and other enums lack explicit enum definitions in schema. LLMs cannot validate input and may hallucinate invalid values. E.g., source_type: 'USER|TRUSTED_SYSTEM|...' should be an enum, not a free-form string.
Destructive operations (delete_memory, quarantine, fail_external_write) lack confirmation or dry-run patterns. Agents can delete records without a safety gate. Breaks pattern:confirmation-request.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
Mark an external memory write as failed
Get audit log entries for a tenant
Get governance metadata for an external memory binding
Get the provenance graph for a memory record, showing its audit trail and dependencies
Get statistics for a tenant (total memories, total customers)
Health check endpoint
Get the current tenant identity from the API key
List all customers for a tenant with memory counts
List all memories for a specific customer
Quarantine a memory record by ID, preventing it from being retrieved
Quarantine an external memory binding
Governed retrieval — trusted memory only (untrusted/quarantined excluded)
Retry binding of external memories after a failed binding attempt
Write a memory through the Write Governor: provenance → taint → injection scan → dedup → embed → persist
Error handling absent from tool definitions. No guidance on retryability, recovery steps, or error classification. E.g., if delete_memory fails, should the agent retry? Call a recovery tool? Breaks pattern:recovery-guide.
healthz and identity tools have minimal descriptions (<60 chars). healthz: 'Health check endpoint' lacks context on when to call it or what failure means. identity: 'Get the current tenant identity from the API key' is vague, does it return tenant_id, permissions, or metadata?