Token Observe vs MuleSoft AI Gateway
Both refuse the call inline. One refuses on behalf of an endpoint, the other on behalf of an agent that has an owner.
2 September 2026
- Omni Gateway Overview
- Creating and Managing Model Proxies
- Sending Requests to Model Proxies
- LLM Token Based Rate Limit Policy
- LLM PII Detection Policy
- Azure Content Safety Policy
- Omni Gateway Agent Policies
- Outbound Policies Directory
- Applying Policies for Managed Omni Gateways and Connected Mode
- Audit Logging in Anypoint Platform
- Self-Managed Omni Gateway High Availability, Disaster Recovery and Multi-Region Deployments
Their claims, not our testing. Verify anything that decides it for you.
On this page
If you already run Anypoint Platform, MuleSoft is the better purchase and it is not close
The strongest argument for MuleSoft is that the gateway is already there. Their documentation describes Omni Gateway as an Envoy-based, ultrafast lightweight API gateway designed to manage and secure APIs running anywhere, and lists HTTP, WebSocket, SOAP, gRPC, GraphQL and OAS3 REST instances alongside Model Context Protocol and Agent2Agent traffic on the same data plane. A Model Proxy is documented as a unified access layer for multiple LLM providers deployed to that same gateway. For an organisation whose APIs already terminate there, governing LLM and agent traffic becomes a policy applied through API Manager rather than a new vendor, a new network hop, a new security review and a new failure domain. Token Observe has no answer to that and does not pretend to: it governs model calls and MCP tool calls, and it is not a general API gateway.
They also publish an operational posture this product has not earned. Their multi-region page describes cross-regional active-active failover where each region services traffic at all times, an active-passive arrangement where a standby region receives traffic only if the primary becomes unhealthy, and replicas distributed across regions and availability zones, with Anypoint Platform acting as the control plane that registers gateways and consolidates their logs and metrics. Token Observe at its current target scale is a single-writer process on one host, with no replica, no clustering and no vendor-operated availability commitment, and the product’s own support document explains why no uptime number is offered — the vendor does not operate your deployment and has no telemetry from it. If the control has to be highly available on day one, that decides the question before any policy comparison begins.
Two more advantages are worth naming because they are specific. Their content moderation is an integration with hosted services rather than a set of local patterns: the Azure Content Safety policy exposes Prompt Shield, per-category severity thresholds, blocklists, groundedness detection and protected-material detection, and an Amazon Bedrock Guardrails policy sits beside it. Token Observe’s injection detection is nine weighted regular expressions scored inline, which is a heuristic and is described as one. And their outbound credential injection is further along on identity propagation than anything here: OAuth 2.0 On-Behalf-Of using token exchange, Microsoft Entra ID On-Behalf-Of or CIBA, alongside API key, basic, JWT generation and AWS Signature Version 4 signing. Token Observe’s on-behalf-of mask is off by default and can only narrow what the agent was already allowed.
Every sentence above about MuleSoft is a paraphrase of a page listed in the sources, read on 2 September 2026, and none of it has been independently tested here. There has been no witnessed bake-off between these two products. Where a row below reads as an absence in theirs, read it as a question to put to Salesforce in writing rather than as a finding: these products change quickly, and a capability that is merely undocumented reads identically to one that does not exist.
Token Observe and MuleSoft AI Gateway, capability by capability
The MuleSoft AI Gateway column paraphrases Salesforce’s own published material as it stood on 2 September 2026. None of it has been independently tested here, products in this category ship quickly, and a capability that is absent from a vendor’s documentation is not the same thing as a capability the product lacks. Check anything that decides it for you against their own current documentation.
Where it sits in the request path
Omni Gateway, documented as an Envoy-based, ultrafast lightweight API gateway designed to manage and secure APIs running anywhere, and noted on the same page as formerly Flex Gateway.
A single Node process holding the model and tool request path, reached by changing OPENAI_BASE_URL, ANTHROPIC_BASE_URL or an MCP server URL.
HTTP, WebSocket, SOAP, gRPC, GraphQL and OAS3 REST API instances, plus Model Context Protocol and Agent2Agent, on one gateway.
Model calls in the OpenAI, Anthropic and Gemini dialects and MCP tool calls over Streamable HTTP. Not a general API gateway and not offered as one.
This row is the clearest reason to buy theirs: one data plane for an existing estate is a category of value this product does not have.
A Model Proxy, described as a unified access layer for multiple LLM providers deployed to Omni Gateway, addressed at the public endpoint plus base path plus /chat/completions or /responses.
The same shape on your own host: /v1/chat/completions, /v1/messages, /v1/models and /v1/embeddings, plus /mcp.
client_id and client_secret headers on the request to the Model Proxy, per their request documentation; the Anthropic format additionally requires an anthropic-version header.
A bearer token hashed with SHA-256 and compared in constant time, resolving to an agent record with a named human owner, a team, a purpose, a risk tier, a lifecycle status and a budget.
Managed Omni Gateway and self-managed Connected Mode. The three LLM policy pages listed in sources each state that the policy is not supported in Local Mode, and the Model Proxy page names the same two modes.
Self-hosted only, one mode, with no vendor-operated option. The vendor receives no telemetry, prompts, keys or trace database from it.
What it enforces inline
The Azure Content Safety policy evaluates the user prompt against the Azure service before forwarding to the upstream LLM and returns 403; their page states that rejected prompts never reach the LLM.
One verdict at step 6 of an eleven-step path — allow, block, redact or require approval — after Unicode sanitisation and detection at steps 4 and 5. A block closes the trace as blocked and returns ACP_POLICY_BLOCKED.
Both refuse inline. The comparison worth making is what the rule is written about, not whether refusal happens.
LLM PII Detection inspects OpenAI and Anthropic format JSON bodies on POST for email, US SSN, credit card, phone number and custom regular expressions, with an action of Reject returning 403, Log, or Log and mask.
Eleven data classes, three of them checksum-validated — Luhn, IBAN mod-97 and NHS mod-11 — tokenised or blocked before the payload leaves your network.
Their PII policy page states that responses are not blocked regardless of the configured action. The Azure Content Safety policy separately evaluates the LLM response before it returns to the client and answers 403 in its place.
Response-side redaction, with a hold-back buffer on streams whose floor is 64 characters so a card number split across two SSE chunks cannot escape masking, and an in-band ACP_POLICY_BLOCKED frame when a blocked class appears mid-stream.
Named policies attached to an API instance through API Manager. The LLM set is documented as six: Azure Content Safety, Amazon Bedrock Guardrails, LLM PII Detection, LLM Token Based Rate Limit, Model Proxy Request Compression and Regex Prompt Guard.
A trigger, an action and a scope evaluated by one pure function, with seven trigger kinds and five actions resolved to a single verdict in which a block beats an approval and an approval beats a redaction.
The Azure Content Safety policy exposes a Prompt Shield setting alongside groundedness and protected-material detection, evaluated against the Azure AI Content Safety service.
Nine weighted regular expressions scored inline and weighted 1.25× when the text is a tool result, which is the channel that actually gets agents hijacked. A heuristic, not a classifier: a novel phrasing matching none of them scores zero.
Theirs is a call to a hosted moderation service, so it carries that service’s cost, latency and data-handling terms; this one runs locally and is weaker.
The LLM PII Detection policy has actions of Log, and Log and mask, which forward the request while recording what was found rather than rejecting it. A shadow or dry-run mode across the LLM policy set as a whole is not described on the pages listed in sources as of 2026-09-02.
Every rule can run in shadow mode first, recording what it would have done without stopping anything, and where the deployment turns the gate on no rule may begin enforcing until a backtest against recorded traffic has been acknowledged by a named person.
Identity, authority and the human gate
An API instance, with a policy applied to it in API Manager. The token rate limit’s counters are grouped by a DataWeave key selector such as the client_id header or the request principal.
An agent. Permissions are action-level and deny-by-default: an allow on tool:orderdb/get_details and model:gpt-5o-mini, while tool:payments/issue_refund is simply absent and therefore denied. An explicit deny beats every allow in any role.
A2A traffic has its own policy set — agent card URL rewriting, schema validation against the A2A specification, PII detection and prompt decoration — with a parallel A2A v1 set that adds token-based rate limiting, quality evaluation and the Azure and Bedrock guardrail policies.
A delegation chain that intersects at every hop rather than unions, so an agent gains nothing by asking a higher-privileged one to act for it. The chain arrives as a header and is asserted, so the only safe thing a forged chain can do is add links that must also allow.
Outbound credential injection, including OAuth 2.0 On-Behalf-Of via token exchange, Microsoft Entra ID On-Behalf-Of or CIBA, plus API key, basic authentication, JWT generation and AWS Signature Version 4 signing.
An on-behalf-of header whose roles, mapped from the named human’s identity-provider groups, are appended to the delegation chain and can only narrow the agent’s own verdict. Off by default, and two of its three settings refuse nothing.
MuleSoft is further along here. Their feature exchanges a real token with the upstream; this one masks authority and records attribution.
An MCP policy set of eight, including attribute-based access control, global access restrictions, progressive tool disclosure, schema validation, payload optimisation and tool mapping.
Action-level allow and deny per tool, with tool descriptors hashed at approval so that a description or schema drifting afterwards quarantines the tool rather than being served.
Not described in their published documentation as of 2026-09-02 on the pages listed in sources. Their policies resolve to allow or refuse; a pending state awaiting a person is not among the outcomes those pages describe.
A 403 carrying an approval id, bound to the SHA-256 of the canonical action plus the execution context it was proposed in, single-use through a compare-and-set, expiring at 60 minutes by default and configurable from one minute to seven days.
Approving pushes nothing to the agent. There is no callback: the agent redeems the approval by repeating the identical request with its id.
What it records
Anypoint Platform audit logging, described as a queryable history of actions performed within the platform with timestamps — logins, API lifecycle events including policy changes, and role and permission modifications.
A hash-chained audit log over the same class of act: an agent created, a policy widened, the kill switch engaged, an approval decided.
Their audit logging page describes retention, the permissions required to read it, payload truncation above 30KB compressed, and export. Hashing, signing and tamper detection are not described in their published documentation as of 2026-09-02.
Each entry’s digest covers the previous entry’s hash plus the canonical JSON of its own content, so an edit or deletion breaks verification at a named sequence number. Tamper-evident, not tamper-proof: without an audit MAC key configured, an operator with write access can rewrite and recompute, and the product ships a test asserting exactly that.
A default retention period of one year, or six years for organisations created before 10 July 2023 that did not change it, and adjustable by a permitted user.
Default trace retention is keep-forever; a shorter window is something you configure rather than something you inherit.
The Audit Log Query API, the audit logging UI for holders of the Organization Administrator or Audit Log Viewer permission, and — on an Anypoint Integration Advanced package or a Titanium subscription — a Telemetry Exporter in Anypoint Monitoring to third-party analytics and observability applications.
An export sealed with a SHA-256 digest that carries the chain verdict. Digest-sealed and not signed: durable origin evidence comes from the keyed chain plus an Ed25519 anchor retained independently of the database.
In Connected Mode, Anypoint Platform consolidates logs and metrics for each Omni Gateway. An SSE Logging policy logs every SSE event while streaming, and an Outbound Message Logging policy logs custom messages from outbound requests and responses.
One trace per governed request with an append-only event list and an FTS5 index over redacted content only, searched in English through a schema-validated filter object shown back to you as editable chips — never generated SQL.
Deployment, providers and what it costs
Managed Omni Gateway on CloudHub 2.0 or Runtime Fabric, or self-managed in Connected Mode or Local Mode. Their multi-region page states that in Local Mode, Anypoint Platform is not present in the deployment model.
Self-hosted only, in your network, on your keys, with no phone-home. The trade is that nobody else operates it for you.
Cross-regional active-active failover where each region services traffic at all times, an active-passive standby that receives traffic only if the primary becomes unhealthy, and latency-based regional routing, with replicas across regions and availability zones.
One writer and one host at this scale. No replica, no clustering and no vendor-operated uptime SLA, stated plainly because the vendor has no access to your deployment and could not measure one.
This is the row most likely to end the evaluation, and it should. A fail-closed control with no replica is a deliberate trade, not an oversight to be argued away.
Named model by model in the Model Proxy documentation: OpenAI and Azure OpenAI, Gemini, Anthropic and Bedrock Anthropic, and NVIDIA Nemotron.
OpenAI, Anthropic, Google Gemini, OpenRouter, Amazon Bedrock and Azure OpenAI as first-class upstreams, plus any OpenAI-compatible endpoint you register, including another gateway.
Model-based static routing where the caller names the model, and semantic routing where the proxy chooses by request content. Multi-routing and fallback are documented as supported in the OpenAI format only; the Gemini and Anthropic formats are documented as not supporting them.
Typed failover across seven failure classes: a 429, a timeout or a 5xx moves to the next provider, while a content-policy refusal, an authentication failure, an over-long context and a malformed request stop where they are.
Semantic routing has no equivalent here. The failover distinction is the one worth testing on either product: a fallback chain that retries a content refusal launders it into a success.
The LLM Token Based Rate Limit counts request, response and reasoning tokens per key selector in a fixed window, returns 429 when the quota is exhausted, adds x-token-limit, x-token-remaining and x-token-reset headers, and supports streaming and non-streaming responses.
Requests, tool calls and tokens per minute, plus hard ceilings in US dollars per request, per rolling hour, per UTC day and per UTC month, reserved in one per-agent database transaction before egress.
A currency budget per agent is not described on the pages listed in sources as of 2026-09-02. Their published ceiling is counted in tokens.
Policies for Managed Omni Gateway and Connected Mode are applied through API Manager, an Anypoint Platform component. The pages listed in sources do not state prices, and no MuleSoft or Salesforce pricing page was read for this comparison.
Commercial source-available: use, modify and self-host under a licence, with redistribution and offering it as a competing hosted service not permitted, and security research and publication expressly allowed. The published licence is a template pending review by counsel, not an executed grant of rights.
Both products refuse. The question is what they refuse on behalf of
The lazy version of this comparison would claim that a gateway watches and this product decides, and their own documentation makes that claim false. The Azure Content Safety policy runs in a request phase and a response phase, answers 403, and the page says that rejected prompts never reach the LLM. The LLM PII Detection policy with its action set to Reject blocks the request and returns 403. The token rate limit returns 429 and blocks the call until the window closes. That is inline enforcement described in the same terms this product uses about itself, and any page pretending otherwise would be wrong on its first substantive sentence.
The real difference is grammatical. A MuleSoft policy is a rule about an endpoint: it is applied to an API instance in API Manager, and where it needs to distinguish callers it does so through a DataWeave key selector over the request, such as the client_id header or the request principal. That is a good design for an API estate, because an API estate is a set of endpoints and the thing you are protecting is the endpoint. An agent estate is not a set of endpoints. It is a set of actors, each of which should have an owner who can be named in a meeting, a purpose written down before it was switched on, a risk tier, a lifecycle status, and an authority that shrinks when it delegates.
So Token Observe’s controls are written about the actor. The permission set is action-level and deny-by-default, which means the interesting facts are the absences: a support agent holds an allow on tool:orderdb/get_details and nothing anywhere names tool:payments/issue_refund, so the refund is denied without anyone having written a deny. An explicit deny still beats every allow wherever it appears, so a narrow guardrail role cannot be outvoted by a broad grant, and the precedence does not depend on the order roles happen to be listed in. When one agent delegates to another the chain intersects rather than unions, so routing work through a higher-privileged agent yields nothing. None of those sentences can be expressed as a property of an endpoint, which is why they are not a criticism of MuleSoft’s model so much as an observation that it answers a different question.
- Their subject
- An API instance and a policy applied to it, with per-caller behaviour derived from a key selector over the request. Their token rate limit documents exactly this, giving the client_id header and the request principal as the worked examples.
- This product’s subject
- An agent record with an id, a named human owner, a team, a declared purpose, a risk tier, a lifecycle status and a budget — the same record the gateway enforces against and the same one a named reviewer recertifies.
- Why it matters at audit
- The question an auditor asks is who owned the thing that did this, and a key selector answers with a client id. The registry answers with a person, and records that the person’s recertification was made stale by the authority change that followed it.
A verdict with a third outcome, and the honest hedge about theirs
The capability this comparison turns on hardest is the one that is easiest to get wrong in public, so here it is with the hedge attached: a human approval gate that parks one exact action on a named person is not described in MuleSoft’s published documentation on the eleven pages read on 2 September 2026. The policies on those pages resolve to allow or refuse — 403 from the content and PII policies, 429 from the token ceiling — and a pending state that waits for a human decision and then resumes is not among the outcomes those pages describe. That is a statement about what was published and read, not a statement about what the product contains. Salesforce ships quickly and the sensible move is to ask them in writing whether an approval flow exists, and if it does, what the approval is bound to.
What Token Observe does here is specific enough to be checked. A policy whose action is require_approval refuses with 403, mints an approval record, and holds the trace open. The approval carries the SHA-256 of the canonicalised action plus the execution context it was proposed in — this subject, with these grants, through this delegation chain, making this call with these arguments — so changing one argument produces a different hash and the retry is refused as a mismatch rather than allowed as near enough. Consumption is a compare-and-set, so two concurrent retries cannot both execute, and the approval expires, at 60 minutes by default and anywhere from one minute to seven days by policy.
The limit belongs in the same paragraph as the claim, because it changes how the feature is operated. Approving pushes nothing to the agent. There is no callback and no way to call an agent back; the approval is a permission the agent redeems by repeating the identical request with its id. An operator who approves something and then goes back to their day has not unblocked the work, and the console says so, because it once said the opposite and that was worse than saying nothing. The binding itself was also wrong once: the hash was salted with the trace id, a value minted fresh on every attempt, so an approved retry could never match its own approval. It failed closed and nothing unsafe ran, but the feature had never worked and the queue filled with rows nobody could spend.
Tokens are a ceiling; currency is a budget; and neither is the same as evidence
Their published ceiling counts tokens. The LLM Token Based Rate Limit counts request, response and reasoning tokens per key selector inside a fixed window, answers 429 when the quota is gone, and returns x-token-limit, x-token-remaining and x-token-reset so a caller can see where it stands. That is a real control and it is well specified, including for streaming responses, which is where token accounting usually goes quiet. A ceiling denominated in currency per agent is not described on the pages listed in sources as of 2 September 2026, which again is a statement about the pages rather than about the product.
Token Observe’s ceilings are in US dollars, per request, per rolling hour, per UTC day and per UTC month, and the money verdict is deliberately taken last: permissions, rate limits and policy first, then routing, then every provider and fallback the resolved route could execute is priced and the most expensive of those rates is reserved against the agent’s windows inside one per-agent transaction. A budgeted agent whose resolved route has an unpriced reachable target is refused with a 409 before egress rather than priced at zero. That rule exists because of a defect the product documents against itself: the shipped price rows once loaded only under the demo seeder, which the setup guide tells production operators not to run, so the documented production install had an empty price table, every trace recorded nothing, and every ceiling admitted every request. A control that is off while appearing to be on is worse than an absent one.
The record is the third piece, and the comparison there is narrow and worth stating precisely. MuleSoft’s audit logging page describes a queryable history of platform actions with timestamps, a default retention of one year — six for organisations created before 10 July 2023 that never changed it — access gated on the Organization Administrator or Audit Log Viewer permission, and export through the Audit Log Query API or, on an Anypoint Integration Advanced package or a Titanium subscription, a Telemetry Exporter into third-party observability tools. Hashing, signing and tamper detection are not described in their published documentation as of 2 September 2026. Token Observe hash-chains the same class of administrative act so that an edit breaks verification at a named sequence number, and that guarantee is tamper-evident rather than tamper-proof: leave the audit MAC key unset and the chain is plain SHA-256, which an operator with database write access can rewrite and recompute, and the repository ships a forgery test asserting that a default install passes verification after exactly that attack. Configure the key and the digests become HMACs under a key held off the box; configure an Ed25519 signing key as well and the head is signed on a schedule and published to a sink outside the database administrator’s reach. The claim that buys is the only one made: any copy of an anchor you kept off-box beats any rewrite made after you took it.
- Their ceiling
- Tokens per key selector per fixed window, 429 on exhaustion, with limit, remaining and reset headers, for streaming and non-streaming responses.
- This product’s ceiling
- US dollars per request, rolling hour, UTC day and UTC month, plus requests, tool calls and tokens per minute, with a 409 before egress when the route cannot be priced.
- Their evidence
- A queryable, exportable platform audit log with configurable retention. Tamper-evidence is not described on the page read on 2026-09-02.
- This product’s evidence
- A hash chain that reports which of two guarantees you are holding in every verification result, and an export sealed with a SHA-256 digest carrying that verdict. Sealed, not signed.
Where each one is the right answer
Choose MuleSoft AI Gateway when
- Your APIs already terminate on Anypoint Platform, and adding LLM and agent traffic to the gateway you already operate is a policy applied in API Manager rather than a new vendor, a new hop and a new security review.
- You need one governed data plane across HTTP, SOAP, gRPC, GraphQL, REST, MCP and A2A traffic, which their documentation describes and this product does not attempt.
- You need high availability now: their published topologies include cross-regional active-active failover and an active-passive standby, and Token Observe is a single-writer process on one host with no replica and no uptime commitment.
- Your moderation requirement is best met by a hosted service — Azure AI Content Safety with Prompt Shield, groundedness and protected-material detection, or Amazon Bedrock Guardrails — rather than by local heuristics.
- You need a real token exchanged with the upstream on a user’s behalf, which their outbound OAuth 2.0 On-Behalf-Of, Entra ID and CIBA credential injection is built for.
Choose Token Observe when
- The unit you need to govern is an agent rather than an endpoint: an actor with a named owner, a declared purpose, a risk tier and an authority that shrinks when it delegates.
- An action has to stop and wait for a named person, bound to that exact payload rather than to an action type, single-use and expiring, with the approver recorded against the trace.
- Finance has asked for a ceiling in currency per agent, enforced before the call, rather than a ceiling in tokens per caller key.
- Somebody will eventually ask who says the record you are showing me has not been edited, and a queryable log with a retention setting is not an answer to that question.
- You want the whole thing inside your own network on your own keys, with no vendor telemetry, and you are willing to accept a fail-closed dependency with no replica to get it.
When you would run both
Running both is the normal answer, and the arrangement is straightforward: leave Omni Gateway where it is as the estate’s data plane and route only the agents that take consequential actions through Token Observe, either in front of the MuleSoft proxy or behind it. Any OpenAI-compatible endpoint can be registered as an upstream here, so a Model Proxy becomes a routable target and you keep MuleSoft’s provider credentials, regional topology and moderation integrations exactly as they are; equally, an Omni Gateway route can forward to Token Observe for the agents that need an owner, a currency budget and a payload-bound approval before they act. Two proxies in series is a second failure domain and a second hop of latency, so decide this deliberately rather than by default — a drafting assistant does not need both, and an agent that can issue a refund might. Where you need another enforcement point to be shown to agree with the rules written here, scope and trigger matching can be compiled to digest-locked OPA Rego with reproducible positive and negative witnesses, though that artifact deliberately excludes permissions, budgets, approval consumption, kill switches and action precedence, which stay authoritative in one place.
The category argument sits above this one: Token Observe and llm gateways covers what the whole category does and does not do, which is the better page to read if you have not yet shortlisted a product.
The others in the same slot
LiteLLM
If you already run LiteLLM, keep it. The question that decides whether you need anything more is about the actions your agents take, not about the proxy.
Portkey
Both hold the payload before it reaches a provider. One is built to carry it to more than 250 models; the other is built to refuse it and prove afterwards who said it could go.
Kong AI Gateway
Kong governs the traffic. Token Observe governs the action. If you already run Kong, the first one is nearly free and the second one is the only reason to read further.
Cloudflare AI Gateway
Cloudflare’s gateway decides what the payload contains. Token Observe decides whether the agent that sent it was allowed to.
Envoy AI Gateway
Both hold the request. One charges the token budget once the response completes; the other reserves the money before the request leaves your network.
Does MuleSoft only observe LLM traffic, or does it block?
It blocks, and any comparison claiming otherwise is wrong. Their Azure Content Safety policy evaluates the prompt against the Azure service before forwarding upstream and returns 403, and the page states that rejected prompts never reach the LLM. Their LLM PII Detection policy blocks the request and returns 403 when its action is set to Reject. Their LLM Token Based Rate Limit returns 429 and blocks the call until the window closes. Two limits are documented alongside those: the PII policy’s page says responses are not blocked regardless of the configured action, and each of these policies states that it is not supported in Local Mode. Everything in this answer is a paraphrase of pages read on 2 September 2026 and has not been tested here.
Is MuleSoft’s AI Gateway the same thing as Omni Gateway?
Their current documentation uses the name Omni Gateway for the component and notes on the overview page that it was formerly Flex Gateway, with the LLM entry point documented separately as a Model Proxy that is deployed to that gateway. The AI Gateway name is what most buyers still search for, which is why it is the title of this page, but when you read their documentation expect to find the capability under Omni Gateway, Model Proxy and the LLM, MCP and A2A policy sets. If a name on this page has moved again since 2 September 2026, treat their documentation as authoritative and this page as dated.
We already run Anypoint Platform. Is there any reason to add this?
Only if the agents take actions somebody has to answer for. If the traffic is drafting, summarising or search — output a human reads before anything happens — then MuleSoft’s token ceilings, PII detection and content-safety integration are a proportionate control and adding a second proxy buys you a failure domain and not much else. The question that changes the answer is whether a call can end in a refund being issued, a deployment going out, an email being sent or a row being written. At that point the useful controls are an authority that belongs to a named agent rather than a client id, a ceiling in currency, a human decision bound to one exact payload, and a record that breaks visibly if it is edited. Those are what this product is for, and they sit beside the MuleSoft gateway rather than replacing it.
Have you benchmarked the two products against each other?
No. Every claim on this page about MuleSoft is a paraphrase of one of the eleven pages listed in the sources, read on 2 September 2026, and none of it has been independently tested. There has been no reference deployment and no witnessed bake-off, and where a cell reads as an absence it says that the capability is not described in their published documentation rather than that it does not exist. The claims about Token Observe are checkable in a different way: the licence sets out a 30-day evaluation so a prospective customer’s security team can read, run and attack the software before a purchase order is raised, with no gag clause and no pre-approval of results. That licence is a template pending review by counsel, so read it as the intended terms rather than the signed ones. There has also been no independent penetration test of this product, which is stated in its own security document rather than left to be discovered.
What happens to our agents if Token Observe is unavailable?
They cannot call models, because it fails closed and it is in the path. That is deliberate — a control you can bypass by turning it off is not a control — but it makes this product’s availability a governance property of your environment, and it is the strongest single argument for MuleSoft in an estate that already runs Omni Gateway with the multi-region topologies their documentation describes. Token Observe at this scale is a single-writer process on one host with no replica, no clustering and no vendor-operated uptime SLA, and the reason none is offered is that the vendor does not operate your deployment and has no telemetry from it. Run it close to the agents, watch the readiness endpoint, and decide in advance, with a named owner, what happens when the fail-closed gateway is down.
Prefer to ask a person? Write to us →
Tell us which one you are already running.
If MuleSoft AI Gateway is already in your stack, the useful question is not which to buy but what each is for, and where the seam between them sits. Say what you have and you will get a straight answer — including when the answer is that you do not need a second thing.
no form · no qualification step · no sales desk · the other three ways in