Token Observe vs Zenity
Zenity gets into the path the agents are already on. Token Observe is the path the agents are pointed at.
2 September 2026
- Zenity — platform
- Zenity — home
- Zenity — Runtime Boundaries
- Zenity — MCP Security
- Zenity — cloud and home-grown agents
- Zenity — coding and personal agents
- Zenity — Claude Enterprise
- Zenity — AI agent compliance
- Zenity — government
- Zenity — trust centre
- Zenity newsroom — inline agent runtime security for Microsoft Foundry
- Zenity newsroom — security and governance for Claude Enterprise
- Zenity newsroom — FedRAMP “In Process” status
Their claims, not our testing. Verify anything that decides it for you.
On this page
On estate coverage and on assurance, Zenity is the better purchase for most readers, and the gap is not close
The decisive advantage is that Zenity does not need the agent to be re-pointed. Their published integrations reach the agent where it already runs: natively inside the Foundry execution path, through Anthropic’s Compliance API for Claude Enterprise, and through native agent hooks and their own MCP gateway on developer machines running ChatGPT Codex, Claude Code, Cursor and GitHub Copilot. Their material also names Salesforce Agentforce, Copilot Studio, AWS Bedrock, Google Vertex AI and ChatGPT Enterprise, and describes the platform as spanning SaaS, home-grown platforms and end-user devices. Almost none of that traffic would ever present a Token Observe credential. A licensed copilot inside a SaaS suite, an agentic browser on a laptop, a Copilot Studio flow built by someone in finance — Token Observe cannot see any of it, and its own documentation lists agents that never route through the gateway under what the product does not evidence. If the brief is the estate rather than the fleet you personally issued credentials to, this is not a close comparison.
The second advantage is detection engineering, which is Zenity’s product and is not Token Observe’s. Their home-grown page describes AI Detection and Response monitoring cloud agent execution step by step, mapped to OWASP and MITRE ATLAS, and blocking unsafe actions in real time, with the platform reconstructing the full decision chain when something gets through. Their Foundry announcement lists inline prevention for sensitive data leakage, secret and credential exposure and jailbreak attempts, with tool misuse marked as coming soon, and describes behavioural enforcement that evaluates chained actions rather than isolated prompts. Token Observe’s equivalent is nine weighted regular expressions over sanitised text, scored 1.25 times higher when the text arrived as a tool result, and eleven sensitive-data classes of which three are checksum-validated. That is a compensating control published with its confidence scores, not a detection product, and its false negatives sit on a register with named acceptors — the CISO for the injection heuristics, the Data Protection Officer for the personal-data matching — neither of which counts as accepted until that person dates it. Against a maintained detection product it should lose, and the product’s own documentation concedes the point rather than arguing it.
The third advantage is procurement, and it ends some evaluations on its own. Zenity’s trust centre states SOC 2 Type II, ISO 27001 and ISO 27701 compliance and adherence to GDPR, with full reports available on request, and their newsroom announced FedRAMP “In Process” status in March 2026, pursued by deploying inside Knox Systems’ Authority to Operate — ask them for the scope, the report date and where that process now stands, because that is the only version of the answer worth having and this page does not hold it for them. Token Observe holds none of those: no SOC 2, no ISO 27001, no ISO 42001, no independent penetration-test result, no availability SLA, no published price list, and a licence that is a template pending review by counsel rather than an executed grant. It says all of that first rather than under questioning. If a certification is your gate, the comparison ends here in Zenity’s favour.
Token Observe and Zenity, capability by capability
The Zenity column paraphrases Zenity’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
Their platform page describes three layers — Surface “gathers what a decision depends on”, Enforce “acts at the moment a decision gets made”, Protect “watches what happens next” — and their Foundry announcement says Zenity “integrates natively into the agent execution path within Foundry”.
A gateway the traffic passes through. Eleven ordered steps in one process: authenticate, resolve agent, open trace, sanitise, scan, govern, enact, route, call upstream, govern the response, meter and record.
Both are inline. One is inline by integrating into someone else’s execution path; the other is inline because it holds the request.
Per-platform integrations, plus a gateway of their own for MCP. Their Claude Enterprise page describes generating an API key, requesting Compliance API access and creating an integration in the Zenity platform; their endpoint page names “native hooks and OpenTelemetry” and “the Zenity MCP gateway”; and their MCP Security page describes dropping in “without re-architecting” — “publish a server, register one gateway URL, and agents keep working unchanged”.
One environment variable. For supported OpenAI-compatible, Anthropic and Gemini ingress a base-URL change is normally the whole integration, plus one Streamable HTTP endpoint for MCP.
Their home-grown page describes AI Observability inventorying “every agent deployed across an organization’s cloud platforms and frameworks”, naming AWS Bedrock, Azure AI Foundry and Google Vertex AI, and their endpoint page says they monitor “what it sends to external models”. Whether Zenity terminates a direct call to a model provider API is not described in the pages read on 2 September 2026 — ask them.
First-class and terminated: OpenAI, Anthropic, Gemini, OpenRouter, Bedrock and Azure OpenAI, with identical permissions, policy, redaction, budgets and tracing enforced by a table-driven parity test over every provider kind.
A named product area. Their MCP Security page describes one control point over every agent-to-MCP connection built on the same Boundaries engine, tool-level control to “allow or block individual tools per agent, user, or team”, and governing “allow, modify, or block a tool call based on live context, not a static allow-list” — and it names tool drift, or rug pull, “a server quietly changes what a tool does after it was approved”, among the risks it governs. Their Claude Enterprise page adds org-level allowlist and blocklist policy on which extensions may run, and their endpoint page says native agent hooks and “the Zenity MCP gateway” can “block or modify a dangerous tool call before it executes”.
One endpoint in front of every registered upstream server, tools namespaced and filtered to the agent’s grants, every call re-authorised at execution, and each descriptor hashed at approval so an upstream rewrite quarantines the tool until a human approves it again.
Both products name the rug pull. The rows differ in what is published about the mechanism, not in whether the risk is recognised.
Their endpoint page names ChatGPT Codex, Claude Enterprise (Chat, Cowork and Code), Cursor and GitHub Copilot, with visibility into “what code it reads, what commands it runs, what it installs, and what it sends to external models”.
A preview surface with named limitations: a decision made locally inside each vendor’s own administrator hook against an Ed25519-signed policy bundle, with no network call at all, because every vendor fails open when a hook times out.
Token Observe does not claim its endpoint hook is equivalent to an inline control on an unmanaged device, and the surface reports itself as not production-eligible.
Their home page claims comprehensive visibility — “Know which agents exist, who owns them, what they can access, and how they behave across your environment” — and their newsroom describes the platform as spanning SaaS, home-grown platforms (Cloud) and end-user devices (Endpoint).
A registry of agents you declared, each with a named human owner, a team, a purpose, a risk tier and a budget, plus a radar that reconciles five evidence sources for activity outside the gateway rather than discovering it by inspection.
What it enforces
Their home-grown page: Runtime Boundaries “evaluate every action a cloud agent takes in real time and let it through, block it, or shut the agent down”.
Five actions resolved to one verdict — block, require a human approval, redact, warn, suspend the agent — in which a block beats an approval and an approval beats a redaction, plus a kill switch scoped to one agent, a team or everything.
Their endpoint page describes “contextual, deterministic policy” covering which agents are allowed, which tools and MCP servers they can reach and how risky modes like auto-run are handled; the platform page describes one rule enforced across every platform automatically. Their Boundaries page adds a prebuilt rule library, an AI assistant that “turns a plain-language request into a working rule”, conflict detection over the rule set, and a dry run — “see exactly what a rule would have caught before it can block anything”.
A trigger, an action and a scope. Seven trigger kinds — tool and argument values, model and estimated size, spend, rate, detected data classes, injection score and its source, hour of day in UTC — evaluated by one pure function shared by the model path, the tool path and the backtest.
Their government page says Zenity applies secure-by-design policies that “enforce zero trust principles, least privilege, and secure defaults”, and their compliance page describes “enforcing least privilege” for GDPR; their Claude Enterprise page describes org-level allowlist and blocklist policy on which extensions are permitted to run. Their MCP Security page frames tool governance as live context “not a static allow-list”. What the shipped default is where no rule matches is not stated in the pages read on 2 September 2026.
Deny-by-default at the action level: an action no role names is refused, and an explicit deny beats every allow wherever it is written, so a narrow guardrail cannot be outvoted by a broad grant.
Their platform page describes Agentic Identity and Access Management that “correlates identity from Okta and Microsoft Entra with what an agent actually does”; their home-grown page adds that this catches “a role that’s been deactivated or over-scoped” before it is exploited.
Action-level roles on the agent itself, with delegation chains that intersect rather than union, so a low-privileged agent gains nothing by routing work through a higher-privileged one. Masking an agent’s authority with a named human’s directory groups is built but off until you switch it on.
Token Observe does not replace an identity provider, and its roadmap names doing so as a strategic non-goal.
Their Boundaries page states the design directly: it “makes it possible to let agents run unsupervised, stepping in while an agent is deciding what to do next, not after it’s already done, without losing what a human reviewer used to catch”, and their endpoint page describes governing how risky modes like auto-run are handled. An approval routed to a named human and bound to a specific proposed action is not described in the pages read on 2 September 2026 — ask them what exists today.
A policy can park one action for a named human: the approval is bound to the SHA-256 of the canonical action plus its execution context, is single-use through a compare-and-set, and expires — 60 minutes by default, one minute to seven days by policy.
Not described in their published documentation as of 2 September 2026: no budget, USD ceiling or rate limit appears on the pages read, which are written to a security brief rather than a spend one. Ask them.
Hard USD ceilings per request, per rolling hour, per UTC day and per UTC month, reserved before egress in one per-agent transaction, alongside requests, tool calls and tokens per minute. A budgeted route with an unpriced reachable target is refused rather than priced at zero.
What it records
Their compliance page describes “audit-ready reports with real-time logs, risks mapped to violations, and automated controls”, and their platform page describes assembling the evidence needed to investigate anything that gets through.
Evidence for a decision: a hash-chained audit log in which every governance-plane change is an entry, a named approver against each gated action, and an export sealed with a SHA-256 digest that carries the chain verdict with it.
Exports are digest-sealed rather than signed, and Token Observe says so in the export itself.
Their Claude Enterprise page describes sessions “recorded with complete fidelity, including prompts, model responses, tool invocations, file operations, and terminal commands”, with Claude Code sessions correlated “back to pull requests and commits”.
One trace row per governed request plus append-only events, opened before the verdict so a blocked request is recorded too, carrying the policy decisions, the route taken, the normalised usage and the priced cost.
Their Claude Enterprise page describes the audit trail as “immutable and structured for SOC 2, ISO 27001, and GDPR”, and their government page offers “tamper-proof logs of agent behavior and decisions”. The construction behind those words is not set out on the pages read on 2 September 2026 — ask them what it is, because the answer is what the record is worth against an insider.
Three layers, weakest named first. Unkeyed SHA-256 by default, which an operator with write access can rewrite and recompute; HMAC-SHA256 under a key held off the database when you set one; Ed25519 anchoring of the head to an off-box sink when you set a signing key. Verification reports which of the three you hold.
Tamper-evident, not tamper-proof. The repository ships a forgery test asserting that a rewrite-and-recompute passes on a default install.
OWASP and MITRE ATLAS are named on their home page and their home-grown page; their compliance page adds NIST’s AI Risk Management Framework and Cybersecurity Framework 2.0 alongside GDPR, SOX, FDIC, HIPAA and PCI-DSS mappings; their government page claims alignment with NIST and FISMA and NIST-aligned controls on agent configurations, permissions and tool access.
Published mappings to the EU AI Act, ISO/IEC 42001, NIST AI RMF and the OWASP LLM and Agentic lists, alongside an explicit section on what the product does not evidence.
Their compliance page describes real-time logs and audit-ready reports; their platform page describes Guardian Agents that triage and investigate new security events, returning a verdict on each one; and their Boundaries page ships a plain-language AI assistant, though for authoring policy rather than querying the record. A natural-language query surface over the record itself is not described in the pages read on 2 September 2026.
Plain-English search translated into a schema-validated filter object — never into SQL — shown back as editable chips, degrading to a deterministic keyword parser when no model is configured, so search still works after the budget circuit breaker has tripped.
How it deploys
A vendor-operated platform. The structured data published on their platform and MCP Security pages lists the operating environment as “Cloud, SaaS, Web”, and their FedRAMP announcement says Zenity is “pursuing authorization by deploying within Knox Systems’ precertified platform as part of Knox’s Authority to Operate”, which is a federal hosting route rather than a customer-run one. Their government page describes covering “cloud, SaaS, and on-prem environments”, which is what the platform reaches rather than where it runs, and adds that the platform is “built for high-availability and performance”. Whether a customer-hosted or air-gapped deployment exists is not stated on the pages read on 2 September 2026.
Self-hosted at every tier: one Node process, one SQLite file, five surfaces, with PostgreSQL available behind the store ports as an evaluation alternative rather than a supported high-availability topology.
Their trust centre states that “Customer data belongs to customers”, with full reports available on request from their trust centre address. What the platform ingests and retains is not set out on the pages read on 2 September 2026 — ask for the data-flow description.
Nothing. No product telemetry, no phone-home, no prompts, no keys, no trace database. Governed payloads leave your network only for the model and tool providers you configure, after policy and redaction, and the runtime flow is documented for you to verify.
SaaS, home-grown platforms and end-user devices, with Salesforce Agentforce, Copilot Studio, AWS Bedrock, Google Vertex AI, Microsoft Foundry, ChatGPT Enterprise, Claude Enterprise, ChatGPT Codex, Cursor and GitHub Copilot named across their pages.
Six first-class model upstreams and any OpenAI-compatible endpoint of your own, under one set of permissions, policies, redaction, budgets and tracing — narrower, and identical across every provider by test.
Reaching agents on SaaS suites, cloud platforms and end-user devices is the stated design of the platform, so traffic that presents no gateway credential is inside their model.
Outside the gateway there is only the radar, reconciling vendor bills, network egress, service-account keys, IDE and CLI telemetry and Token Observe’s own caller and price consistency into findings. The support boundary says chasing those agents down inside your organisation is your work.
What it costs, and what assurance comes with it
Their trust centre states SOC 2 Type II, ISO 27001 and ISO 27701 compliance and adherence to GDPR, with full reports available on request; their compliance page describes the SOC 2 Type 2 attestation as covering security, availability, integrity, confidentiality and privacy. Their newsroom announced FedRAMP “In Process” status in March 2026, pursued by deploying inside Knox Systems’ Authority to Operate, with authorisation expected in upcoming review cycles. Ask them for the scope and the report date, and for where the FedRAMP process now stands.
None. No SOC 2, no ISO 27001, no ISO 42001. Stated on the first call rather than under questioning.
No test report is described on the pages read on 2 September 2026, but their trust centre says full reports are available on request, their SOC 2 Type II and ISO certifications involve third-party assessment, and a FedRAMP authorisation requires an independent assessor. Ask which reports they will release and under what terms.
None has been carried out, said plainly in the repository’s security policy. A pre-purchase test by your own team is expressly permitted by the licence, with no gag clause and no pre-approval of results.
None of the pages read on 2 September 2026 publishes a price or a packaging tier, and their site navigation routes to “Get a Demo” rather than to pricing; their Foundry announcement points Foundry customers at an Azure Marketplace listing. The shape of the commercial agreement is a question for them.
No published price list either, so neither side of this row helps you build a business case without a conversation.
Their government page describes the platform as “built for high-availability and performance” and as ensuring “system availability”, and their compliance page says the SOC 2 Type 2 attestation covers availability. A numeric availability target and the licensing terms themselves are not described in the pages read on 2 September 2026 — ask for the contract.
Commercial source-available: use, modify and self-host under a licence that forbids redistribution and competing hosted offerings, and expressly permits security research and publication of results. That licence is a template pending review by counsel, and there is no availability SLA yet — the support document states why.
Both are inline, and the word is doing different work in each case
Zenity is inline by integrating into an execution path that somebody else owns. Their Foundry announcement is the clearest statement of it — Zenity “integrates natively into the agent execution path within Foundry”, and “integrates where agents actually operate” — and the same shape recurs on each platform: Anthropic’s Compliance API for Claude Enterprise, native agent hooks and their own MCP gateway on developer machines. The consequence a buyer should care about is that the model traffic does not get re-pointed. Agents already running inside Foundry, Bedrock, Vertex AI, Agentforce, Copilot Studio or an engineer’s copy of Cursor come under governance without anybody editing a base URL, which is why the reach extends to parts of the estate no gateway would ever see. The one place they do ask for an endpoint change is the same place Token Observe does: their MCP Security page describes publishing a server and registering one gateway URL, with agents otherwise working unchanged.
Token Observe is inline in the older sense: it holds the request. An agent is pointed at it, and eleven ordered steps run in one process before anything leaves your network — authenticate, resolve the agent, open a trace so even a refusal is recorded, sanitise the Unicode, scan for sensitive data and injection, take one governance verdict, enact it, resolve the route, call upstream, evaluate any tool call the model proposed on the way back, then meter and record. The order is load-bearing and it is the reason the refusal can be deterministic: the decision is a function of the payload the product is physically holding, not a signal about a payload it observed.
Neither position is better in the abstract, and an estate can hold both. What the two positions decide is coverage and certainty. Zenity trades a per-platform integration for reach across platforms Token Observe cannot enter. Token Observe trades reach for the fact that a request which has not been allowed cannot proceed, because there is nowhere for it to go — and that its own documentation states the boundary in the same breath: it can only refuse a proposal it is shown, and an agent that routes around it is a radar finding or nothing at all.
The three rows Zenity’s published pages do not describe
Assume the detection worked. Assume it also missed something, because sometimes it will. What remains on the Token Observe side is a set of gates that do not depend on recognising anything, and they are the reason to read this page rather than the category page it rolls up to.
The approval is the first. A policy can park a proposed action for a named human, and the approval that comes back is bound to the SHA-256 of the canonical action plus the execution context it was proposed in, is spendable exactly once through a compare-and-set, and expires. A retry with one argument changed is refused as a mismatch rather than waved through as near enough, and the agent learns nothing from the approval until it retries — the approval takes effect on the retry, not by pushing anything at the agent. Zenity’s Boundaries page states its own design plainly and it is a coherent one: the engine steps in “while an agent is deciding what to do next, not after it’s already done, without losing what a human reviewer used to catch”, which is enforcement standing in for the reviewer rather than routing to one. A gate that parks a specific payload for a named person is not described in the pages read on 2 September 2026; that is a question to put to them rather than a finding about their product.
The spend ceiling is the second, and it is the control most often missing from a security platform because money is not a security team’s brief. Hard USD limits per request, per rolling hour, per UTC day and per UTC month are reserved before egress inside one per-agent transaction, after permissions, rate and policy have been decided and the route resolved, priced at the most expensive rate any provider or fallback on that route could charge. A budgeted route with an unpriced reachable target is refused with a 409 rather than priced at zero, because an empty price table is exactly how a ceiling was once silently disarmed. Budgets and spend ceilings are not described in the Zenity pages read on 2 September 2026, which are written to a security brief rather than a spend one.
The third is the audit construction rather than the audit claim. Their Claude Enterprise page describes an “immutable” audit trail structured for SOC 2, ISO 27001 and GDPR and their government page offers “tamper-proof logs”, and the mechanism behind those words is not set out on the pages read — worth asking about, because the answer determines what the record is worth against an insider. Token Observe publishes its own construction in three layers and names the weakest first: unkeyed SHA-256 by default, which an operator with database write access can rewrite and recompute, and the repository ships a forgery test asserting exactly that; HMAC-SHA256 under a key held outside the database when you configure one, with the head sealed at every boot by a checkpoint MAC; and Ed25519 anchoring of the head to a sink off the box, worth something only if that sink is somewhere the database administrator cannot reach. Every verification result and every export reports which of the three you are holding.
- Approval binding
- SHA-256 of the canonical action plus its execution context, single-use via compare-and-set, expiring between one minute and seven days with a default of 60.
- Budget windows
- Per request, per rolling hour, per UTC day and per UTC month, projected and reserved in one per-agent transaction before egress.
- What the chain claims
- Any copy of an anchor kept off-box beats any rewrite made after you took it. That is the whole claim, and it is narrow on purpose.
Detection is Zenity’s product, and Token Observe’s roadmap tells it not to compete there
This is not modesty for the sake of a balanced page; it is written into the product’s strategy. A generic AI firewall, prompt scanner or red-team platform is a named strategic non-goal, and the instruction that follows names Zenity among the vendors whose threat and identity verdicts should be consumed rather than reproduced. So the honest account of Zenity’s detection here is their own. Their home-grown page describes AI Detection and Response monitoring cloud agent execution step by step, mapped to OWASP and MITRE ATLAS, blocking unsafe actions in real time, and reconstructing the full decision chain when something gets through. Their Foundry announcement describes inline prevention for sensitive data leakage, secret and credential exposure and jailbreak attempts, with tool misuse marked as coming soon, and behavioural enforcement that evaluates decisions and chained actions rather than isolated prompts. Their endpoint page adds secret exfiltration, malicious package installs, unsafe tool chaining and an agent working around a security control.
What Token Observe ships against that is deliberately modest and published with its numbers. Nine weighted injection heuristics over Unicode-sanitised text, scored 1.25 times higher when the text arrived as a tool result, because indirect injection arrives through tool output far more often than through the user turn. Eleven sensitive-data classes, three of them checksum-validated — Luhn for cards, mod-97 for IBANs, mod-11 for NHS numbers — with confidence scores published per kind so a policy can set its own threshold rather than inherit one. Free-text personal data written in a sentence is not detected at all. It is not a model and it has false negatives on both counts, and the register names a different acceptor for each: the CISO for the injection heuristics’ false negatives, the Data Protection Officer for the limits of the regex personal-data detection — neither counting as accepted until that person dates it.
The reason for the modesty is stated rather than hidden. Blocking on a classifier with a meaningful false-positive rate, on the hot path of every request, breaks legitimate work — so detection is one of seven policy trigger kinds rather than the control itself, and the controls that actually bound the damage are the deterministic ones. If detection quality is the requirement you are buying against, buy it from the vendor whose product it is.
The two coverage statements, side by side
Zenity’s coverage claim runs outward: SaaS, home-grown platforms and end-user devices, with a list of named platforms that grows on their newsroom faster than any comparison page can track. That includes the copilots inside suites your staff already licence, the agent builders your business teams already use, and the coding agents on laptops — the parts of an AI estate that a security team usually discovers exists rather than commissions.
Token Observe’s coverage claim runs inward and is stated as a limit rather than a feature: it governs what presents a credential to its gateway. Model calls through the OpenAI, Anthropic and Gemini dialects; tool calls through its own MCP endpoint; tool calls the model merely proposes, evaluated on the way back as defence in depth, which is why a rule about refunds over a threshold binds even when the agent executes the tool itself. Everything else is the radar’s problem, and the radar reconciles evidence you feed it rather than inspecting anything: vendor bills, network egress, service-account key audits, IDE and CLI telemetry, and the product’s own caller and price consistency checks. A source may only clear a finding when its run actually completed, so a failed or truncated pass leaves every finding standing rather than silently resolving the estate.
Put the two beside each other and the pairing is arithmetic rather than argument. Zenity tells you which agents exist across an estate you did not build and stops the unsafe action wherever it finds one. Token Observe tells you, for the agents you did commission, exactly what each one was permitted to do, what it cost, who approved the action, and whether that decision is still in a record that verifies. Neither answer substitutes for the other, and the second is much smaller in scope.
Where each one is the right answer
Choose Zenity when
- The brief is the estate rather than a fleet you issued credentials to — SaaS copilots, agent builders in the hands of business teams, agentic browsers, and coding agents on laptops, none of which will be re-pointed at a gateway.
- Detection quality is what you are buying: step-level runtime monitoring mapped to OWASP and MITRE ATLAS, behavioural enforcement over chained actions, and a maintained threat model rather than nine published heuristics.
- Procurement requires SOC 2, ISO 27001 or ISO 27701 from the vendor, or a federal authorisation path. Zenity’s trust centre states all three and their newsroom announced FedRAMP “In Process” status in March 2026; Token Observe holds none of it and will say so on the first call.
- You want governance of agents on platforms whose execution path only the platform vendor can open — Foundry, Bedrock, Vertex AI, Agentforce, Copilot Studio — without an engineering change in each agent.
Choose Token Observe when
- The gap you have found is the action rather than the content: which permission allowed it, which named human approved that exact payload, what it cost, and whether the record still verifies.
- A hard USD ceiling has to stop the call before egress rather than appear on next month’s invoice, per request, per hour, per day and per month.
- Self-hosted with zero vendor egress is a requirement, including air-gapped environments — no prompts, no keys and no trace database leaving your network, with the runtime data flow documented so your security team can verify it rather than take it on trust.
- You need one policy set to mean the same thing across OpenAI, Anthropic, Gemini, OpenRouter, Bedrock and Azure OpenAI, with that equivalence enforced by a test rather than asserted.
When you would run both
Running both is the normal answer, and the product’s own strategy is written to make it the expected one: a complete AI security platform, a generic prompt scanner and a red-team platform are named strategic non-goals, with the instruction to consume threat and identity verdicts from vendors including Zenity rather than reproduce them. In that arrangement Zenity owns discovery and detection across the estate — which agents exist on SaaS suites, cloud platforms and end-user devices, how they behave step by step, and what to block when behaviour turns unsafe — and keeps the coverage of everything that will never hold a gateway credential. Token Observe owns the fleet you commissioned: deny-by-default action-level permissions, an approval bound to one exact payload, a hard spend ceiling reserved before egress, and a hash-chained audit log you can key and anchor off the box. Their verdicts can become policy inputs on the Token Observe side through the radar’s connectors, and the direction of that integration is the point — you configure an outbound feed in a console you already administer, delivering on a credential Token Observe issued, so Token Observe holds no credential into your security stack. The honest caveat is that this is a division of labour rather than a shipped integration: there is no Zenity-shaped connector in Token Observe today, only the generic receiver shape for any tool that can export on a timer, and anyone running both would be operating two policy sets and deciding which owns which rule.
The category argument sits above this one: Token Observe and ai security platforms 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
Keycard
Keycard decides whether the agent gets a credential. Token Observe decides the call and then proves what the call actually did.
Palo Alto Prisma AIRS
Prisma AIRS decides whether the content is malicious. Token Observe decides whether the agent that sent it was allowed to.
Cisco AI Defense
AI Defense attaches a policy to an application’s connection and inspects what crosses it. Token Observe attaches permissions to an agent and decides what it may do.
Noma Security
Noma decides from what the agent appears to be doing. Token Observe decides from what the agent was allowed to do, before anything is scored.
Lakera
Lakera tells your application the content is an attack. Token Observe is the thing that refuses to send it.
WitnessAI
WitnessAI stands in front of the interaction and classifies the intent. Token Observe stands in front of the API call and decides the action, its cost and its evidence.
Is Token Observe an alternative to Zenity?
For most readers, no. Zenity’s published platform spans discovery, posture, detection and inline prevention across SaaS agents, cloud agent platforms and end-user devices, and Token Observe’s own roadmap names a complete AI security platform as a strategic non-goal and lists Zenity among the vendors whose verdicts it should consume rather than replicate. Where the two genuinely overlap is inline refusal on an agent action, and even there they refuse differently: Zenity’s Runtime Boundaries evaluate an action in the platform’s own execution path and let it through, block it or shut the agent down, while Token Observe returns a typed refusal on a request it is physically holding. If securing the AI estate is the brief, Zenity is the product built for it.
Both say they enforce inline. What is the actual difference?
How each one gets into the path. Zenity integrates into an execution path owned by the platform — natively inside Foundry, through Anthropic’s Compliance API for Claude Enterprise, through native agent hooks and their own MCP gateway on developer machines — so the model traffic does not have to be re-pointed and the reach covers agents that hold no credential you issued. Token Observe is the endpoint the agent is addressed to, normally after a base-URL change, so a request that has not been allowed simply has nowhere to go. The trade is legible: Zenity buys reach with a per-platform integration; Token Observe buys a deterministic refusal and a priced, recorded request with a much narrower estate, and its own documentation states that an agent routing around it is a radar finding or nothing.
What does Token Observe do that Zenity’s published pages do not describe?
Three things, as of 2 September 2026, and each is an instruction to ask them rather than a finding about their product. A human approval bound to the SHA-256 of one exact action plus its execution context, single-use and expiring, so a retry with one argument changed is refused as a mismatch. Hard USD ceilings per request, per rolling hour, per UTC day and per UTC month, reserved before egress in one per-agent transaction, with an unpriced reachable target refused rather than priced at zero. And a published audit construction — unkeyed SHA-256 by default, HMAC under an off-box key when configured, Ed25519 anchoring above that — where their pages state the property, describing the trail as immutable and structured for SOC 2, ISO 27001 and GDPR and the logs as tamper-proof, without setting out the mechanism. A capability that is merely undocumented reads identically to one that does not exist, so put all three to Zenity in writing rather than reading any of them as an absence.
Zenity has SOC 2 Type II and ISO 27001. What does Token Observe have?
Nothing of that kind, and this is the row where the comparison most often ends. Zenity’s trust centre states SOC 2 Type II, ISO 27001 and ISO 27701 compliance and adherence to GDPR, with full reports available on request, and their newsroom announced FedRAMP “In Process” status in March 2026 pursued inside Knox Systems’ Authority to Operate; ask them for the scope, the report date and where that process now stands, because that is the only version of the answer worth having. Token Observe holds no SOC 2, no ISO 27001, no ISO 42001 and no independent penetration-test result, offers no availability SLA, publishes no price list, and its licence is a template pending review by counsel rather than an executed grant. What it offers instead is different in kind: the software runs entirely inside your network with no vendor egress, its governance domain is pure functions with zero runtime dependencies that a reviewer can read in a day, its known-defect list is published on purpose, and a pre-purchase security test by your own team is expressly permitted with no gag clause and no pre-approval of results. Whether that substitutes for a certification is your risk committee’s decision, not this page’s.
Have you tested Zenity against Token Observe?
No. Every claim about Zenity on this page is a paraphrase of their own published pages read on 2 September 2026 — the platform, home, Runtime Boundaries and MCP Security pages, the cloud, endpoint, Claude Enterprise, compliance and government use-case pages, the trust centre, and three newsroom announcements — and none of it has been independently tested. There has been no witnessed comparison, and one is named in the product’s own launch gates as evidence that does not yet exist. Where a cell says a capability is not described in their published documentation, read it as an instruction to ask Zenity rather than as a conclusion: their product moves quickly, their newsroom adds platforms faster than a comparison page can track, and the accurate account of what Zenity does today is the one you get from Zenity. Ask in writing, and ask for the scope and the date.
Prefer to ask a person? Write to us →
Tell us which one you are already running.
If Zenity 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