Where does Ultra13 sit in your stack?
Ultra13 can run inline inside the agent loop, as an LLM-compatible proxy, or as an MCP / tool gateway. The same source-to-sink policy model controls context assembly, memory reads and writes, tool calls, outbound actions, and final output screening. Teams can start in monitor mode, then enforce on high-risk sinks such as exports, shell execution, webhook egress, tenant-crossing actions, and persistent memory writes.
- Three deployment modes: inline SDK, LLM-compatible proxy, or MCP / tool gateway.
- One source-to-sink policy model governs context, memory, tools, egress, and output.
- Start in monitor mode, then enforce on high-risk sinks.
- Every decision is logged with provenance for replay and audit.
Three places Ultra13 can sit
- Inline SDK inside the agent loop — screening context assembly, memory reads/writes, tool calls, and egress.
- LLM-compatible proxy in front of model requests and responses.
- MCP / tool gateway in front of JSON-RPC tool calls and results.
What gets logged
In all modes, policy decisions are logged with source provenance, sink, action arguments, identity, tenant, data class, decision, rule ID, and replay metadata — the basis for the evidence in the Trust Centre and a proof report.
Monitor first, then enforce
Start in monitor mode to observe the agent loop and flag exploit paths without changing behaviour, then enforce on high-blast-radius sinks. This mirrors the fail-open detection / fail-closed enforcement split described on the Context Firewall page.