Get started
How Immiscible compares
Immiscible beside the kinds of tool it is most often mistaken for: AI gateways, LLM observability, corporate card controls, agent frameworks’ built-in guardrails and wallet policy engines. By category, factually, including where each is the better fit.
Each category below solves a real problem well. This page says what each one is for, where Immiscible overlaps, and where it does something different. It compares categories, not products: individual products vary, and many combine more than one category.
#At a glance
| Decides before an agent acts | Asks a person for one action | Payments, data and tool calls | Model spend and budgets | Signed, verifiable record | Across agents from any vendor | |
|---|---|---|---|---|---|---|
| AI gateways | model requests | rarely | no | yes | usually logs | yes, for model traffic |
| LLM observability | no, records after | no | sees them in traces | reports | traces | yes |
| Corporate card controls | card payments | sometimes | card payments only | no | issuer records | any holder of the card |
| Framework guardrails | inside the framework | sometimes | what the framework wraps | no | varies | one framework |
| Wallet policy engines | on-chain transfers | often | crypto transfers | no | on-chain and logs | any holder of the wallet |
| Immiscible | every consequential act and model request | yes, in the console, email, Slack or Teams | yes | yes, through its gateway | Ed25519 receipts and a hash-chained ledger | yes |
#AI gateways
What they are for: one endpoint in front of model providers, for routing, failover, caching, rate limits, cost tracking and budgets.
Overlap: Immiscible’s gateway speaks OpenAI-shaped and Anthropic-shaped traffic, routes under a policy (cost, capability, compliance, jurisdiction), checks budgets before the call and records cost per request, task and team.
Difference: a gateway governs what goes to the model. Immiscible also governs what the agent does with the answer: the payment, the data release, the tool call. Its gateway records which untrusted content entered a session, so the decision about the next action is judged on what the agent actually read.
Better fit for a gateway alone: you only need routing, caching and cost reports for model calls, and agents take no consequential actions. Immiscible can also route through OpenRouter, keeping a gateway you already use.
#LLM observability
What it is for: traces, prompts, latency, cost and evaluations, so engineers can debug and improve an AI application.
Overlap: Immiscible joins every record to a W3C trace and can export to a SIEM as OCSF or OpenTelemetry.
Difference: observability records after the fact; Immiscible decides before, and can refuse or hold an action for a person. Its record is evidence: signed, chained and verifiable offline by someone who does not trust the operator. What entered a session and what a proxied tool returned are kept as digests, never as content.
Better fit for observability: you want to inspect prompts and completions, run evaluations or tune answer quality. The two sit side by side.
#Corporate card controls
What they are for: limits on a card or cardholder: amounts, merchant categories, single-use cards, freezes, and receipts matched to spend.
Overlap: Immiscible’s card rail makes the issuer ask before money moves, applies merchant categories with dual control, and matches charges to the receipts that allowed them (for example with Ramp).
Difference: a card control sees a card and a merchant. Immiscible sees the agent, its mandate, its autonomy tier, what influenced the request (a person, an email, a web page) and whether the domain is a lookalike, and it covers data releases, tool calls, crypto and x402 as well as cards.
Better fit for card controls alone: people, not agents, hold the cards, or agents only ever pay by card within fixed limits nobody needs to approve one by one.
#Agent frameworks’ built-in guardrails
What they are for: checks inside one framework or vendor’s agent: input and output filters, tool approval prompts, and policies configured by whoever built the agent.
Overlap: both can stop a tool call and ask a person. Immiscible’s SDKs wrap framework tools (OpenAI Agents SDK, LangChain, Vercel AI SDK) so they can be used together.
Difference: built-in guardrails live inside the agent and answer to its builder. Immiscible sits outside every agent, so one set of rules, one kill switch and one record cover Claude, ChatGPT, your own agents and the rest. With the MCP proxy and the Claude Code hook, the agent cannot route around it.
Better fit for built-in guardrails: one agent, one framework, one team, and no need for a record that someone outside that team can check.
#Wallet policy engines
What they are for: rules on a crypto wallet, enforced by the custodian or signer: allowed addresses, amounts, networks and approval quorums.
Overlap: Immiscible decides crypto payments before the wallet signs, prices them at the rate of the moment, stops lookalike addresses, and answers the Fireblocks Co-Signer callback; there are guides for Turnkey, Privy, Circle and Coinbase CDP wallets too.
Difference: a wallet policy governs one wallet’s transfers. Immiscible holds the agent’s whole authority across cards, crypto, data and tools, with limits kept in pounds. It never holds keys or signs; the wallet still does.
Better fit for the wallet’s own policy: a treasury team moving funds by hand, with no agents involved.
#Where Immiscible is not the answer
- You need a model host or a reseller of inference: Immiscible uses your own provider contracts.
- You need evaluations or answer-quality scoring: use an observability or evaluation tool.
- The agent’s inference runs in a vendor’s own backend: it can be reconciled from the vendor’s API, not enforced. See what the gateway cannot see.
Questions this page does not answer are probably in the FAQ.