Loading ToolBench
Security proxy for inter-agent communication. Exposes tools for scanning messages, verifying agent identity, querying audit logs, and managing quarantined messages.
oktsec provides 6 security-focused tools with complete JSON schemas and actionable descriptions. All tool names follow verb_noun convention (scan_message, list_agents, audit_query, get_policy, verify_agent, review_quarantine). Descriptions are well-crafted (130-220 chars) and explain the security purpose clearly. However, there are gaps in parameter validation, missing output schema documentation, and limited error handling guidance. The review_quarantine tool has a complex action-based design that conflates multiple operations into one tool. Error responses are not documented, leaving agents without recovery guidance. Parameter descriptions are present but lack format constraints, enums, and range specifications for numeric fields.
Query the oktsec audit log. Returns recent inter-agent messages with status, policy decisions, and security findings.
Get the security policy for a specific agent, including which agents it can message and what content restrictions apply.
List all agents configured in the oktsec policy, including their access control rules.
Review and manage quarantined messages. List pending items, view details, or approve/reject messages held for human review. Agents cannot approve or reject their own quarantined messages.
Scan an inter-agent message for security threats. Checks for prompt injection, credential leaks, PII exposure, relay injection, and 140+ other threat patterns.
Verify an Ed25519 signature from an agent. Checks that the message was signed by the claimed sender using their registered public key.
review_quarantine conflates multiple operations (list, detail, approve, reject) into a single tool with a string 'action' parameter. This violates the single-responsibility principle and forces the LLM to reason about which action to perform.
Output schemas are not documented for any tool. LLMs cannot predict return structure, field names, or types. This forces agents to reason about response shape blindly and risks incorrect field extraction.
No error handling guidance or recovery instructions in tool descriptions. If audit_query returns no results or verify_agent fails signature validation, the agent has no guidance on what to do next.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
numeric parameters (limit, timestamp) lack min/max bounds or format specifications. audit_query accepts 'limit' with no stated default or maximum, risking unbounded result sets.
status parameter in audit_query accepts free-form strings ('delivered', 'blocked', 'rejected', 'quarantined') but is not declared as an enum. LLMs may invent invalid status values.
verify_agent requires 'timestamp' as a parameter but does not specify the expected RFC3339 format in the schema, only in the description. LLMs cannot parse natural-language format hints reliably.
review_quarantine action parameter is not enumerated. Valid actions (list, detail, approve, reject) are mentioned only in the description; LLMs will frequently hallucinate invalid actions.