Token Observe vs cloud-native controls
If every agent, model and tool lives in one cloud, use that cloud’s controls. The argument here is for the estate that does not.
Inside one cloud, the native control is closer, cheaper and better attested.
A control inside the provider’s own runtime has advantages no external proxy can match. There is no extra hop and no extra process to operate; the decision happens in the same trust boundary as the workload; identity, key management and audit are the ones you already run; and it arrives under the certifications that provider publishes, which Token Observe holds none of. If your agents call Bedrock models through an AgentCore gateway and nothing else, a second control plane buys a second failure domain in exchange for portability you are not using.
Microsoft is stronger still on identity, and this product’s market analysis says so: the recorded consequence is to federate Entra and Agent 365, not to rebuild them. The third advantage is direction of travel — generic gateway and policy features are being bundled by the hyperscalers, and a buyer whose estate the bundle already covers should take the bundle. Cloud AI features change preview status quickly, so verify availability and policy semantics with the provider during procurement rather than from a comparison page.
Token Observe and cloud-native controls, row by row
Where these two differ, one row at a time.
Policy expressed in that cloud’s language, enforced by that cloud.
One policy set, with equivalence enforced by a table-driven test over every provider kind.
Authoritative. The directory is the source of truth.
Federated. OIDC sign-in, directory groups mapped to roles, taken as a snapshot with a 24-hour default staleness, not a live directory read.
The residency and sovereignty commitments that provider publishes and contracts for.
Three independent flags — retention, training, region — checked on every fallback. Nothing verifies a provider’s claim; a Bedrock region binding proves configuration consistency, not residency.
That cloud’s audit log, inside that cloud.
One hash-chained audit log across every provider, anchored off-box with Ed25519. Tamper-evident, not tamper-proof.
The certifications and regional attestations that provider publishes.
None. No SOC 2, no ISO 27001, no ISO 42001, no independent penetration test — stated first, not on request.
- beat 01Name the caller
- 1Authenticate
- 2Resolve the agent
Nothing is decided for an anonymous caller. The key resolves to one registered agent with a named owner, and its roles, its ceilings and any stop switch in force are read live from the store on every request, not from a cached copy, so a suspension takes effect on the next call instead of after a redeploy.
- beat 02Start the record, then read what is being sent
- 3Open the trace
- 4Sanitise
- 5Scan
The trace is opened before anything can refuse the request, which is why a blocked call is recorded as thoroughly as one that went through. Only then is the text normalised and scanned, in that order, so the detectors see what the model will read rather than what a human reviewer can see.
- beat 03Decide once
- 6Govern
- 6bIntersect with the named human
- 7Enact
One function returns one verdict: allow, block, or hold it for a named person to approve. Every check lives in that one place rather than scattered along the path, which is what makes it possible to read your rules and know what they do.
- beat 04Send it, and only then spend the money
- 8Route
- 9Call upstream
Routing fixes which provider and model will serve the call, so where an agent has a USD ceiling it is tested against the price you will pay, not the one the caller typed. Routing is also the last step that can still refuse locally: after it, the request has left your network.
- beat 05Govern the answer, then count the cost
- 10Govern the response
- 11Meter and record
A tool call the model proposes is judged before it reaches your agent. Metering runs last and on every ending, including the refusals and the streams a client abandoned halfway, because the tokens were spent either way and a partial trace is still evidence.
Step names and their grouping are the product’s own, and the order is encoded in the evaluator rather than drawn for the page.
Apply your data policy across providers.
One agent can be routed across OpenAI, Anthropic, Google Gemini, OpenRouter, Amazon Bedrock and Azure OpenAI, and the same permissions, policies, redaction, budgets and tracing apply whichever one serves the request. That equivalence is enforced by a table-driven test over every provider kind. Carry this into any evaluation of a multi-provider control: a policy that fires on OpenAI but not on Gemini is worse than no policy, because it produces a governance report describing coverage you do not have.
Routing carries the same discipline into failover. Every fallback candidate is filtered through the agent’s data policy first, so failing over cannot bypass a zero-retention, no-training or region constraint, and failover is typed rather than counted: a timeout, a 429 or a 5xx moves on, while a content-policy refusal, an authentication failure and a malformed request stop. Otherwise the chain launders a refusal into a success.
What Token Observe chooses not to rebuild.
Two of the seven strategic non-goals are about this category: do not build a replacement enterprise identity provider or credential vault, and do not build a broad CMDB-style AI inventory. Implement adapters and evidence exchange for those layers instead. So the identity surface is short — OIDC sign-in, directory groups mapped to roles, bounded SCIM provisioning — and the registry is a system of record for governed agents rather than an estate-wide inventory. It does not discover agents for you.
- What federation means here
- OIDC sign-in for console users, directory groups mapped to roles, and an optional on-behalf-of mask that intersects a named human’s authority with the agent’s. The mask can only narrow, never grant.
- The staleness you are accepting
- Group claims are a snapshot taken at sign-in, aged out on a 24-hour default window. A revoked group keeps granting until the next sign-in or that expiry, and that residual risk requires the CISO’s written acceptance.
- What region binding proves
- A declared Bedrock policy region is bound to the region proven by an AWS-owned runtime endpoint, and contradictions fail closed. That proves configuration consistency, not data residency and not your network path.
Which of the two to put in.
Read the left one first. If two of those describe you, buy the other thing. If the right column describes you, the next step is thirty days with the source on your own hardware.
When to choose cloud-native controls
- Every agent, model and tool you govern is inside one cloud, and portability is a cost rather than a requirement.
- Your control has to inherit that cloud’s certifications, regional attestations or FedRAMP posture. Token Observe holds no independent certification of any kind.
- Identity is the requirement rather than action assurance: agent identity, sponsorship, lifecycle and Conditional Access belong in the directory that already governs your people.
- You need the enforcement point inside the workload’s own trust boundary, with no external process to run and no second failure domain.
When to choose Token Observe
- You run more than one model provider (or one cloud plus one frontier lab), and the same rule now has to bind identically on all of them.
- You need one evidence chain that spans providers, rather than one audit log per cloud and a spreadsheet reconciling them.
- A data-policy constraint has to survive failover, so a fallback that silently routes around a no-training or region requirement is unacceptable.
- Self-hosting in your own network is a requirement, including an air-gapped environment, which the licence is drafted to permit.
If the left-hand column describes you, that is still worth an email: a short reply costs both of us less than an evaluation that ends in the same place.
See the thirty-day evaluationThe 4 named products in this category
This page argues about the category. If you have already shortlisted a product, these go head to head with it.
Amazon Bedrock AgentCore
AgentCore enforces Cedar on tool calls at its own gateway boundary. Token Observe enforces one rule set on model and tool calls across six providers, from a process you run. The estate decides which you want.
Microsoft Entra Agent ID
Entra decides which identity the agent holds and whether it may be issued a token. Token Observe decides the individual call that token does not cover.
Microsoft Agent 365
Agent 365 governs the agent as an identity in your tenant. Token Observe governs the payload that agent sends to a model provider.
ServiceNow AI Control Tower
AI Control Tower governs your AI estate and who may use each part of it. Token Observe reads what one call carries and rules on it before governed provider egress.
The other comparisons
The other 6 categories, each opening with the case for the alternative.
Does Token Observe replace Entra or our identity provider?
No, and a replacement enterprise identity provider or credential vault is one of the seven strategic non-goals. Console sign-in federates your OIDC provider, directory groups map to roles, and bounded SCIM provisioning handles viewer lifecycle; that is the whole identity surface, and it attaches authority and effect evidence to identities your directory already owns. The recorded consequence for Microsoft is to federate Agent 365 identities rather than rebuild Entra.
Can Token Observe policies be compiled to Cedar for AgentCore?
Not today. The shipped compiler target is OPA Rego, emitting digest-locked policy and data with reproducible witnesses for scope and trigger matching, and it refuses to translate tool-argument matchers rather than weakening their semantics. AWS AgentCore and Cedar are named as a future target. Even for the target that exists, the artifact excludes permissions, budgets, approval consumption, kill switches, action precedence and side effects; Token Observe stays authoritative for those.
Can Token Observe prove our data stayed in a region?
No. An agent carries three independent data-policy flags (zero retention, no training, a serving region), and every routing candidate including every fallback is filtered through them. What that enforces is your configuration. Nothing verifies a provider’s own claim: those flags are unverified operator assertions, and that residual risk has a named acceptor on the register. The strongest thing available is the Bedrock region binding, which fails closed on a contradiction — configuration consistency, not data residency.
Tell us which way you are leaning, and why.
Create a cloud account and workspace. No card or server installation. Model calls and Google BigQuery scans can incur separate provider charges.