Token Observe vs MuleSoft Omni Gateway

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 a page saying otherwise would be wrong from its first sentence.

The difference is grammatical. A MuleSoft policy is a rule about an endpoint: it is applied in API Manager to an API instance, or to an agent and tool instance for an MCP or A2A server, 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.

Start with the hedge: a human approval gate that parks one exact action on a named person is not described in MuleSoft’s published documentation on the twelve pages read on 5 October 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 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.

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 5 October 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. 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 5 October 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.