Skip to content
Docs
Start free

Answers

What kinds of tool control what AI agents spend and do?

Seven kinds, each good at something different: the controls built into the agent, LLM gateways, MCP gateways and proxies, guardrail libraries, card and payment controls, wallet policy engines, and an independent control layer such as Immiscible. Which to use depends on what the agent can do and who needs to see the record.

Seven kinds of tool do this, and most teams use more than one: the controls built into the agent itself, LLM gateways, MCP gateways and proxies, guardrail libraries, card and payment controls, wallet policy engines, and an independent control layer such as Immiscible. Pick by what the agent can do (spend, share data, call tools, run up model bills) and by who needs the rules and the record: one team, or finance, security and an auditor across every agent.

This page compares categories, not products. Products vary, and many combine more than one category. The longer version, with a table, is how Immiscible compares.

#The controls built into the agent

Claude Code’s permission rules and hooks, the OpenAI Agents SDK’s tool approvals, LangGraph’s interrupts, Cursor’s terminal settings, and providers’ own project spend limits. Best when one team runs one agent and the person watching it is the person approving. Start here; keep them on. They are configured by whoever built the agent, and each covers its own agent.

#LLM gateways

One endpoint in front of model providers, for routing, failover, caching, rate limits, cost tracking and budgets. Best when the question is model spend and reliability and agents take no consequential actions. A gateway sees the prompt, not the payment the agent makes next.

#MCP gateways and proxies

One front door for the tool servers agents use, with authentication, tool allowlists and logs. Best when the risk is in which tools an agent can call. Most decide by tool name; deciding by what a call does (a payment of this amount, an email to this domain) needs a tool map and a rule.

#Guardrail libraries

Checks on what goes into and comes out of a model: prompt injection detection, content filters, output validation. Best when the risk is in the text. They run inside the application and do not decide whether an action may happen or ask a person.

#Card and payment controls

Limits on a card or account: amounts, merchant categories, single-use cards, freezes. Best when people hold the cards, or an agent pays only within fixed limits nobody needs to approve one by one. They see a card and a merchant, not the agent, its rule or what it read.

#Wallet policy engines

Rules at the custodian or signer: allowed addresses, amounts, networks, quorums. Best when a treasury team moves funds by hand. They govern one wallet’s transfers.

#An independent control layer

A decision before every consequential act and model request, against rules a person wrote, held outside every agent: allow with a signed receipt, ask a named person, or refuse, with one kill switch and one verifiable record across agents from any vendor. This is what Immiscible is. Best when agents pay, share personal data or act on other systems, more than one agent or vendor is involved, or someone outside the team (finance, security, an auditor, a regulator) needs the rules and the record. It works alongside the six above: its gateway can route through OpenRouter, its card rail sits behind the issuer, and its SDKs wrap framework tools.

#Which should I start with?

#When is Immiscible not the answer?

When you need a model host or reseller of inference, evaluations or answer-quality scoring, or control over inference that runs inside a vendor’s own backend, which can be reconciled but not enforced. See where Immiscible is not the answer.