Local Development
In progress.Integration Platforms
Protecting Against Lethal Trifecta
This guide explains how connector platforms can integrate with Oso to:- automatically classify tools into Lethal Trifecta / Rule of Two capability buckets,
- let agent authors configure expected behavior on violations, and
- enforce decisions at runtime.
Concepts
Integration A connector namespace (e.g. “Slack”). Tool An action an agent can invoke (e.g.,chat.postMessage, conversations.list).
Capability buckets (Rule of Two / Lethal Trifecta)
untrusted_content(A): inputs that may contain attacker-controlled instructionsprivate_data(B): access to sensitive systems or dataexternal_or_state_change(C): network egress, sending messages, writing data, side effects
deny(default)require_approvalignore(not recommended except for testing)
Step 1: Register an integration and its tools
When a customer creates or installs an integration in your platform, send Oso the tool catalog (names + descriptions + schemas if available).- Oso can auto-classify tools, and you can provide manual overrides for edge cases.
- If you have OpenAPI specs / MCP manifests, include them. Schemas improve classification quality.
Step 2: Configure enforcement behavior for an agent
Agent authors choose what should happen if Oso detects a Rule of Two / Lethal Trifecta risk.- Production:
denyorrequires_approval - Development:
requires_approval
Step 3: Stream session context (messages + tool events)
Oso’s decisions are stateful: whether a tool call is safe often depends on what happened earlier in the same session (for example, whether the agent has recently ingested untrusted content, accessed sensitive data, or is now attempting an external/state-changing action). To enable this, send Oso a lightweight event stream for eachagent_id + session_id:
message_from_user/message_to_user(what the agent saw and said)tool_call_request/tool_call_response(what the agent tried to do and what the tool returned)
- Minimum to gate tool sequences:
tool_call_request - Recommended for higher-quality decisions and better investigations: include messages and tool call responses too
agent_id and session_id, with timestamps applied when the event is received by Oso, via methods such as tool_call_request, tool_call_response, message_from_user, and message_to_user.
Step 4: Enforce at runtime (tool execution gate)
At runtime, call Oso before executing a tool. Oso returns a decision that you enforce in your tool runner.requires_approval:
- pause execution
- present a review UI to the user (tool name, parameters, risk reason)
- resume only after approval
deny:
- block execution
- return a safe error to the agent (and optionally suggest an alternative flow)