Token Observe vs Amazon Bedrock AgentCore
AgentCore enforces Cedar at its own gateway boundary. Token Observe enforces one rule set across six providers from a process you run. The estate decides which you want.
2 September 2026
- Amazon Bedrock AgentCore product page
- Amazon Bedrock AgentCore overview (developer guide)
- Policy in Amazon Bedrock AgentCore
- Policy in AgentCore: core concepts
- Policy in AgentCore: authorization flow
- Policy in AgentCore: enforcement modes
- Policy in AgentCore: temporal policies
- Getting started with Policy in AgentCore
- Amazon Bedrock AgentCore Gateway
- Amazon Bedrock AgentCore Identity
- Amazon Bedrock AgentCore Observability
- AWS Agent Registry
- Security in Amazon Bedrock AgentCore
- Amazon Bedrock AgentCore pricing
Their claims, not our testing. Verify anything that decides it for you.
On this page
If your agents, tools and targets are inside AWS, AgentCore is the better purchase and it is not close
The strongest argument for AgentCore is that the enforcement point is inside the trust boundary the workload already runs in. AWS describes Policy in AgentCore as intercepting all agent traffic through AgentCore Gateways and evaluating each request before allowing tool access, with enforcement happening “at the boundary outside of agent’s code — ensuring consistent, deterministic enforcement that remains reliable regardless of how the agent is implemented”. There is no extra hop, no second process for your team to operate, no additional failure domain, and no window in which the request exists outside both systems. The identity model is the one you already run — principals are `AgentCore::OAuthUser` built from a JWT `sub` claim with the remaining claims carried as tags, or `AgentCore::IamEntity` built from the caller’s IAM identity — and the decisions land in CloudWatch alongside everything else you monitor. Adding an external control plane to that arrangement buys portability you may not be using.
The second advantage is the assurance a buyer cannot manufacture. AWS publishes the shared responsibility model, states that “third-party auditors regularly test and verify the effectiveness of our security as part of the AWS Compliance Programs”, and directs you to the AWS Services in Scope by Compliance Program list to see which programmes apply to AgentCore — check that list for the scope and the date rather than taking it from here. Token Observe holds no independent certification of any kind: no SOC 2, no ISO 27001, no ISO 42001, and no independent penetration test. If your control has to inherit an attestation, this comparison is already decided, and it is decided against Token Observe.
The third is breadth of platform, which is larger than the policy feature this page focuses on. The AgentCore overview lists Harness, Runtime, Memory, Gateway, Identity, Code Interpreter, Browser, Observability, Payments, Evaluations, Optimization, Policy and Registry as modular services usable together or independently, and states that Runtime works with “any foundation model in or outside of Amazon Bedrock including OpenAI, Google’s Gemini, Anthropic’s Claude, Amazon Nova, Meta Llama, and Mistral models” and with CrewAI, LangGraph, LlamaIndex, Google ADK, OpenAI Agents SDK and Strands Agents. Token Observe is one governance gateway and a flight recorder; it hosts nothing, it runs no sandbox, it holds no agent memory, and it has no equivalent of Code Interpreter or Browser. Everything summarised here is AWS’s own published material read on 2 September 2026, has not been independently tested, and moves quickly — where a row below reads as an absence in AgentCore, treat it as a question to put to AWS in writing rather than as a finding.
Token Observe and Amazon Bedrock AgentCore, capability by capability
The Amazon Bedrock AgentCore column paraphrases AWS’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 each one sits in the request path
The gateway. AWS describes Policy in AgentCore as intercepting “all agent traffic through Amazon Bedrock AgentCore Gateways” and evaluating each request against the policy engine “before allowing tool access”, with the policy engine attached to one or more gateways.
The request itself, on an eleven-step path: authenticate, resolve the agent, open a trace, sanitise Unicode, scan, take one verdict, enact it, route, call upstream, govern any tool call the model proposes on the way back, then meter and record.
The JWT and the MCP tool call. The gateway constructs a Cedar request whose principal comes from the token’s `sub` claim, whose action is the tool name, whose resource is the gateway ARN, and whose context is the tool arguments — an example condition reads `context.input.amount < 1000`.
The whole payload and the agent record: the tool and its argument values, the model requested and its estimated input size, accumulated spend, request and token rate, detected data classes, the injection score and the source the text arrived from, and the hour in UTC.
Gateway is described as “a fully managed AI gateway that provides a single, secure entry point for agentic traffic”, converting APIs, Lambda functions and existing services into MCP-compatible tools, fronting other agents and HTTP services through passthrough targets including A2A, and routing inference across model providers through a unified model-based routing endpoint.
Model dialects, tools and inbound agent calls: OpenAI, Anthropic and Gemini ingress surfaces, one Streamable HTTP MCP endpoint in front of every registered upstream MCP server, and a synchronous A2A v1.0 message endpoint advertised on a well-known agent card, whose caller traverses the same governance pipeline as one arriving on an SDK. That last surface is deliberately narrow: streaming, push callbacks, background tasks and URL or file dereference are rejected rather than partially implemented, and there is no Task store.
Both products name A2A and mean different halves of it. AWS’s is egress — Gateway fronting other agents and HTTP services as passthrough targets, alongside model providers and MCP tools, through one endpoint. Token Observe’s is ingress only: an agent that calls in over A2A is governed like any other caller, and Token Observe does not front other agents on the way out.
Tool invocations. The core-concepts page states that a Cedar policy “permits or forbids access to gateway tools” and that “policies are evaluated for every tool invocation request”. How policy applies to inference traffic routed through Gateway’s model-based routing endpoint is not described on the pages read for this comparison as of 2 September 2026.
Both, from one evaluator. The same pure function decides a model call, an MCP tool call, a replayed backtest and the bundle compiled for a developer laptop, which is why a rule means the same thing wherever it is evaluated.
That first cell is a statement about what these pages describe, not about what AgentCore can do. If model-call governance matters to you, ask AWS in writing which traffic through the gateway a Cedar policy is evaluated for.
Agents call the gateway endpoint. The getting-started tutorial creates the gateway, target and policy engine with the `agentcore` CLI, sends MCP requests to the `/mcp` path on the gateway URL, and notes that deployment “takes approximately 2–3 minutes per deploy”.
Change `OPENAI_BASE_URL` or `ANTHROPIC_BASE_URL` and one key. For supported OpenAI-compatible, Anthropic and Gemini ingress that is normally the whole integration rather than an application refactor.
Broad at the runtime layer: Runtime works with “any foundation model in or outside of Amazon Bedrock including OpenAI, Google’s Gemini, Anthropic’s Claude, Amazon Nova, Meta Llama, and Mistral models”, and Harness with “Amazon Bedrock, OpenAI, Google Gemini, and any OpenAI-compatible model provider”.
Six first-class upstreams — OpenAI, Anthropic, Gemini, OpenRouter, Bedrock, Azure OpenAI — plus any OpenAI-compatible endpoint you register, with policy equivalence across them enforced by a table-driven test over every provider kind.
Two different claims, and the difference is the point of this page. AWS’s is reach at the runtime; the Token Observe number comes with a test that the same rule fires identically on each, because a policy that fires on OpenAI but not on Gemini is worse than no policy.
What each one enforces before the action
Deny by default. The policy engine “enforces default-deny and forbid-wins semantics automatically”, and the tutorial states that in ENFORCE mode “by default, all actions are denied unless explicitly permitted” and “if any forbid policy matches, access is denied”.
The same posture, on the action rather than the traffic: an agent may hold an allow on `tool:orderdb/get_details` while `tool:payments/issue_refund` is simply absent and therefore denied. An explicit deny beats every allow wherever it is written, and a delegation chain intersects rather than unions, so agent A gains nothing by asking higher-privileged agent B.
Two modes on the gateway’s policy engine. In `LOG_ONLY` “the policy engine evaluates and logs whether the action would be allowed or denied without enforcing the decision”; in `ENFORCE` it “enforces decisions by allowing or denying agent operations”. AWS adds that anyone holding `bedrock-agentcore:UpdateGateway` can switch a gateway back to `LOG_ONLY` or remove the policy engine entirely, that no separate action or condition key protects the mode field beyond that permission itself, and to “grant this permission only to trusted principals”.
Shadow mode per policy rather than per gateway, so one rule can be learning its false-positive rate while every other rule keeps enforcing. Where the deployment turns the gate on, no rule may begin enforcing until a backtest of that exact rule has been replayed against recorded traffic and acknowledged by a named person, and the backtest reports “unknown” rather than “zero” when the recorded evidence cannot answer.
Cedar `when` conditions over the tool input, validated against a schema the engine generates from the gateway’s tool definitions, with automated reasoning used to flag policies that always allow or always deny before deployment. The default validation mode `FAIL_ON_ANY_FINDINGS` runs schema checks and semantic validation and rejects a policy if either produces findings.
Tool-argument matchers over exact values, numeric comparisons and regular expressions, evaluated inside the same verdict as everything else. There is no separate authoring service: a rule is a trigger, an action and a scope, and shadow mode plus backtest is what stands in for automated reasoning about it.
A temporal policy over the session’s own history. Dogwood adds operators such as `formerly within`, and AWS’s worked example permits a sale only when a matching `ApproveSale` event with `output.approved: true` occurred within the previous hour. Quotas are 25 temporal policies per policy engine, 3 temporal operators per policy, and a maximum window of 24 hours per condition.
A named human on one exact payload. A `require_approval` verdict returns 403 carrying the approval id, mints a record bound to the SHA-256 of the canonicalised action plus its execution context, is single-use through a compare-and-set so two concurrent retries cannot both execute, and expires at 60 minutes by default. Change one argument and the hash no longer matches, so the retry is refused as a mismatch.
Different controls with a similar shape. AWS’s condition matches an earlier permitted event in the same session; whether a person decided that event depends on what the approving tool does, which their example leaves to you. Token Observe’s limit is stated beside its claim: approving pushes nothing to the agent, so the agent redeems it by repeating the identical request with the id.
Dogwood supports `count` and `sum` aggregations over the matching events in a window, described as “keeping a running total under a threshold”, and AgentCore Payments is described separately as providing wallet integration and “configurable spending limits” for x402 and MPP microtransactions. AWS states the scope of the first plainly: because history is scoped to a session and the session ID is supplied by the caller, “a temporal rate limit constrains activity within a session rather than across all of a caller’s sessions”.
Hard USD ceilings per request, per rolling hour, per UTC day and per UTC month, scoped to the agent rather than to a session it names for itself. Windows are projected and reserved before egress inside one per-agent transaction after the route resolves and every reachable fallback is priced at its most expensive rate; a budgeted route whose target cannot be priced is refused rather than priced at zero. Request, tool-call and token rate ceilings sit beside them, and a kill switch scoped to one agent, one team or everything is checked first.
Guardrails as information providers a Dogwood policy consults inline: at evaluation time a guardrail “computes a content-safety signal for the request — such as a content-filter, prompt-attack, or sensitive-information score — and the policy permits or forbids the action based on that result”.
Detection in-process, and a redaction plan rather than only a verdict. Eleven sensitive-data classes, three of them checksum-validated, and nine weighted injection heuristics scored 1.25 times higher when the text arrived as a tool result. Streamed responses pass a hold-back buffer with a 64-character floor and a separate channel per tool-call argument, because a card number split across two chunks otherwise escapes output redaction entirely.
The Token Observe side is heuristic, not a classifier, and its own documentation calls it a compensating control rather than your only DLP. A novel phrasing that matches none of the nine patterns scores zero.
Gateway is described as routing inference requests across multiple model providers through a unified, model-based routing endpoint. How a provider’s content-policy refusal is classified when routing moves on is not described on the pages read for this comparison as of 2 September 2026.
Seven typed failure classes. A 429, a timeout and a 5xx move to the next provider; a content-policy refusal, an authentication failure, an over-long context and a malformed request stop where they are. Every fallback candidate is filtered through the agent’s retention, training and region policy before it can be used, so failing over cannot route around a data-policy constraint.
What each one records, and who the record is for
CloudWatch. AWS states that policy enforcement gives you “every enforcement decision logged through CloudWatch metrics and logs, so security and compliance teams can audit and validate behavior”, publishes policy metrics to the `AWS/Bedrock-AgentCore` namespace, and puts span data in the `aws/spans` log group once traces are enabled on the gateway.
Two places, deliberately. Every governance-plane change — an agent created, a policy widened, the kill switch engaged, an approval decided — is appended to a hash chain, while each governed request opens a trace whose id is returned in a response header even when the request was blocked.
Not described on the AgentCore pages read for this comparison as of 2 September 2026. The Registry page states that AWS CloudTrail logs “all API calls made to AWS Agent Registry”, which is a different question from what protects a policy decision log from later edit.
A chain, keyed if you configure it. 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; set an audit MAC key and those digests become HMAC-SHA256 under a key held outside the database; set a signing key and the head is periodically signed with Ed25519 and published off-box. Tamper-evident, not tamper-proof, and the verification result reports which of the three you are holding.
The first cell says these pages do not describe the construction, not that there is none. Ask AWS what integrity property the policy decision log carries, and whether a party who can write to it can rewrite it.
OpenTelemetry into CloudWatch. AgentCore “emits telemetry data in standardized OpenTelemetry (OTEL)-compatible format”, and all metrics, spans and logs “are stored in Amazon CloudWatch, and can be viewed in the CloudWatch console or downloaded from CloudWatch using the AWS CLI or one of the AWS SDKs”.
OTLP over HTTP as an input rather than a destination: bounded JSON and protobuf for logs, traces and metrics, answering in the request encoding, with every write attributed to the credential that presented it. Token Observe is not a trace viewer for application spans and does not try to be one.
Downloaded from CloudWatch through the console, the AWS CLI or an SDK, under the IAM permissions you grant for it.
A compliance export sealed with a SHA-256 digest that carries the audit-chain verdict, plus an offline verifier that is one Node script with no install, no database and no network. The export is digest-sealed and not itself signed: durable origin evidence comes from the keyed chain and the Ed25519 anchor retained independently of the database.
AWS Agent Registry, “a fully managed discovery service that provides a centralized catalog”, where publishers submit MCP servers, tools, agents, skills and custom resources, curators approve or reject them, and consumers discover them through hybrid semantic and keyword search or a native MCP endpoint. Records may describe resources “deployed on AWS, On-Prem or on any other Cloud environment”.
A smaller register with a different job: every agent has an id, a named human owner, a team, a declared purpose, a risk tier, a lifecycle status and a budget, and it is the same record the gateway enforces against rather than a catalogue beside it. It discovers nothing — registering an agent is a deliberate act by a named person, and anything calling a model without a record is the shadow-AI radar’s problem.
How each one deploys, and what you end up operating
Fully managed AWS services. AgentCore is described as letting you “run agents securely at scale, and monitor agent performance and quality in production - all without any infrastructure management”, with Gateway offering “serverless infrastructure” that “automatically scales based on demand”.
Self-hosted only, in your network, on your keys: one Node process and one SQLite file in WAL mode at its current target scale. No replica, no clustering, no vendor-operated uptime SLA, and it fails closed, so its availability becomes a governance property of your environment.
Into the AWS services you use, under the shared responsibility model, and the overview page adds: “AgentCore may use and store your content to improve your service experience or performance. Such improvements would be for your use of AgentCore and not for other customers.”
Nowhere the vendor can reach. The Token Observe vendor receives no product telemetry, phone-home data, prompts, keys or trace database; governed payloads leave your network only for the model and tool providers you configure, after policy and redaction.
Scoped, and documented as such. Temporal policy sessions “do not support cross-Region or cross-account propagation”, and “for temporal policies to control your agent’s actions, the gateway and all its targets must reside in the same AWS account and AWS Region”. AWS publishes a per-region availability table for temporal policies with several regions marked No.
Wherever you run the process, including environments with no egress at all — the licence is drafted to permit air-gapped operation, though it remains a template pending counsel. For Bedrock specifically, a declared policy region is bound to a region proven by an AWS-owned runtime endpoint and a contradiction fails closed, which proves configuration consistency rather than data residency.
AgentCore Identity, described as “compatible with existing identity providers, eliminating needs for user migration or rebuilding authentication flows” and integrating with “any IdP and credential providers such as Amazon Cognito, Okta, Microsoft Azure Entra ID, Auth0”, with agent identities implemented as workload identities and inbound and outbound authentication handled in one service.
Federation and nothing more, on purpose. OIDC sign-in for console users, directory groups mapped to roles taken as a snapshot with a 24-hour default staleness rather than a live directory read, and bounded SCIM user provisioning. Agent credentials are long-lived hashed bearer tokens, which is a recorded decision rather than an oversight, compensated by revocation and expiry.
A replacement enterprise identity provider or credential vault is one of Token Observe’s named strategic non-goals. On the identity half of this comparison, AgentCore Identity is the product built for the job.
The AWS Compliance Programs, with “third-party auditors regularly test and verify the effectiveness of our security”, and the AWS Services in Scope by Compliance Program list as the place to check which apply to AgentCore.
None. No SOC 2, no ISO 27001, no ISO 42001, no independent penetration test — stated first rather than on request. What exists instead is a published known-issues list naming the attacks that still work, a STRIDE threat model with residual risk on every row, and a licence that expressly permits a pre-purchase test with no gag clause.
What each one costs, and what you can inspect
Consumption-based “with no upfront commitments or minimum fees”, metered per component. Policy is priced at “$0.000025 per request” for an authorization request and “$0.13 per 1,000 tokens” for input tokens processed, which AWS’s own worked example bills against natural-language policy authoring, with a note that “Your first 100 temporal policies per policy engine incur no additional authorization charges”.
No published price. The commercial licence is a template pending counsel, and any figure you are quoted comes from a conversation rather than from a page.
Gateway is priced at “$0.005 per 1,000 invocations” for API invocations, which AWS lists as ListTools, InvokeTool and Ping, “$0.025 per 1,000 invocations” for the Search API, and “$0.02 per 100 tools indexed per month”. Identity is “available at no additional charge to customers when they use it through either AgentCore Runtime or AgentCore Gateway”, otherwise “$0.010 per 1,000 token or API keys requested by the agent”.
Nothing per request. You pay for the host you run it on and for the provider bills it meters, and the cost control is the point: usage is normalised into mutually exclusive token buckets before any arithmetic, because Anthropic reports cache reads and writes outside the input total while OpenAI and Gemini report them inside it.
Observability is “charged as per Amazon CloudWatch pricing”, with the note that “most development environment observability data volumes are low enough that observability costs are near zero”.
Disk. Traces live in the same SQLite file as everything else, and the default trace retention is keep-forever — which is a deliberate evidence choice and a storage bill you own, so size it before you turn the gateway on rather than after.
The policy languages. Cedar is described as “an open source language for writing and enforcing authorization policies”, and Dogwood as an open-source policy language compatible with Cedar, so the semantics of a rule are inspectable independently of the service that evaluates it.
The governance domain. `packages/core` holds it as pure functions with zero runtime dependencies, so what “allow” means is readable and testable without a database, a network or a clock — and the same evaluator decides the gateway, the MCP path and the backtest.
The claim this page turns on is that one rule fires identically on every provider
A control that lives inside one provider’s runtime is authoritative for what happens inside it and silent about everything else, and that is the correct trade for an estate that is inside it. AgentCore’s scope is stated cleanly enough to reason about: the policy engine attaches to gateways, evaluates Cedar for every tool invocation, and — for temporal policies — requires that the gateway and all its targets reside in the same AWS account and Region, with cross-Region and cross-account propagation explicitly unsupported. If your agents, your tools and your targets satisfy that, the boundary is in the right place and nothing external improves it.
Token Observe’s claim starts where that scope ends. 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 not an aspiration in a document; it is enforced by a table-driven test that runs the same expectations over every provider kind, and the reason for spending the effort is the sentence worth carrying 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 failure. A route rule names a primary target and an ordered fallback chain, every candidate is filtered through the agent’s retention, training and region policy before it can be used, and failover is typed rather than counted — a 429, a timeout or a 5xx moves on, while a content-policy refusal, an authentication failure, an over-long context and a malformed request stop where they are. Afterwards the route is narrowed to whichever provider actually served the request, so the ledger prices against the vendor that will invoice you rather than the one that was tried first. In a mixed estate that is the difference between a cost report you can reconcile against six invoices and one you can only argue with.
- What equivalence does not cover
- Traffic that never presents a credential to the gateway. Token Observe governs model calls through its supported dialects and tool calls through its own MCP endpoint; a proposed tool call is evaluated on the way back as defence in depth, but an agent that calls a resource directly is outside it, and only the shadow-AI radar reports that such activity exists.
- The Bedrock row specifically
- Where a Token Observe agent routes to Bedrock, a declared policy region is bound to a region proven by an AWS-owned runtime endpoint and signing must use that same region, with contradictions failing closed. That proves configuration consistency, not AWS data residency and not your network path.
- Why the pricing table is part of the control
- A budgeted agent whose resolved route or reachable fallback cannot be priced is refused before egress rather than priced at zero, because an estate spending nothing and an estate spending unmetered emit identical bytes and the customer finds out from the invoice.
A prior session event and a named human on one payload are different controls
AgentCore’s temporal policies are the most interesting thing on these pages and deserve a fair description. A Dogwood rule can require that a matching event occurred earlier in the same policy session — AWS’s example permits `SellShares` only when an `ApproveSale` event with `output.approved: true` occurred `formerly within 1h`, correlated on the stock and the number of shares — and the engine records the session’s events and evaluates the condition on every request, so the sequencing logic lives in policy rather than in agent or tool code. That is a genuinely strong construction for multi-step workflows, and the caveats AWS publishes with it are the ones a reviewer would ask for: the session ID is supplied by the caller in a header, the gateway does not generate one, a denied action is recorded as an `error` rather than a `response` so a `response` condition never matches it, and adding or updating a temporal policy invalidates active sessions with an HTTP 409 on reuse.
Token Observe’s approval is a different object. It is not a prior event in a session; it is a named human deciding on one exact payload. The request is refused with 403 carrying an approval id, a status URL and a resume contract; the record binds the SHA-256 of the canonicalised action plus the execution context it was proposed in; consumption is a compare-and-set, so two concurrent retries cannot both execute; and it expires, at 60 minutes by default and between one minute and seven days by policy. Change one argument and the digest no longer matches, so the retry is refused as a mismatch rather than allowed as near enough. The limit is published in the same breath: approving pushes nothing to the agent, because there is no way to call an agent back, so the approval takes effect only when the agent repeats the identical request with its id.
The scoping difference matters more than the mechanism. AWS states it about their own control rather than leaving it to be discovered — a `count`-based temporal limit “constrains activity within a session rather than across all of a caller’s sessions”, since the history is session-scoped and the caller supplies the session ID. Token Observe’s ceilings are bound to the agent record instead: per request, per rolling hour, per UTC day and per UTC month, reserved before egress inside one per-agent transaction. Neither is the general answer. A workflow-shaped rule about what must precede what is the temporal policy’s natural form; a spending limit an agent cannot reset by starting again is the agent-scoped ledger’s.
- The quotas worth reading before you design around temporal policies
- 25 temporal policies per policy engine, 3 temporal operators per policy, and a maximum window of 24 hours per temporal condition, on AWS’s published quota table as of 2 September 2026. Availability is also per-region, with several regions marked No.
- The mode switch is worth an access review either way
- AWS says so themselves: `bedrock-agentcore:UpdateGateway` can move a gateway from ENFORCE to LOG_ONLY or remove the policy engine entirely, no separate action or condition key protects the mode field beyond that permission itself, and it should be granted only to trusted principals. In Token Observe the equivalent change is a governance-plane write, which appends to the hash chain and is therefore attributable after the fact.
- What Token Observe adds after the decision
- An effect contract pins one action tool and a separate verifier tool to their exact descriptor digests, takes a durable unique claim on the business idempotency value before dispatch, and refuses to record the run as committed until the verifier has observed the effect afterwards. This is at-most-one dispatch, not distributed exactly-once execution.
Cedar is a compiler target Token Observe has not shipped, and the compiler says so
A buyer running both will eventually ask whether one policy set can drive both enforcement points, and the honest answer today is no. Token Observe’s cross-control-plane compiler emits OPA Rego: digest-locked policy and data with reproducible positive and negative witnesses, recording the compiler, source-policy and target-policy digests and listing every source policy it rejected. AWS AgentCore and Cedar are named as a future target alongside MCP, gateway targets, cloud IAM and sandbox egress. Until a target passes the published equivalence suite it is roadmap, and this page will not describe it as anything else.
The exclusions on the shipped target are as important as the output, and they are published on the endpoint that produces it. The artefact covers policy scope and trigger matching only. It does not cover permissions, budgets, approval consumption, kill switches, action precedence or side effects, and Token Observe remains authoritative for all of those. The compiler also refuses to translate tool-argument matchers rather than turning JavaScript value and regular-expression behaviour into weaker Rego semantics, which is the decision the whole feature rests on: the product is not configuration generation, it is evidence that a generated policy preserves the source meaning. Anyone reading a generated bundle as a complete transfer of governance to another engine is reading it wrong.
That is worth stating plainly on a page about AWS, because the natural question after reading AgentCore’s Cedar documentation is whether an existing Token Observe policy could simply be compiled into it. It could not, today. What a mixed estate gets instead is two enforcement points with one evidence layer: Cedar deciding tool calls at the AgentCore Gateway inside the account and region it serves, Token Observe deciding model traffic across every provider and holding a hash-chained record that spans them.
One log per cloud, or one chain across all of them
AgentCore’s recording story is coherent and it is CloudWatch: enforcement decisions logged as metrics and logs, policy spans in `aws/spans` once traces are enabled on the gateway, telemetry emitted in OTEL-compatible format, and everything downloadable through the console, the CLI or an SDK. For a team already operating CloudWatch that is one fewer system, and the observability dashboards for agent runtime data are described as trace visualisations, custom span metrics and error breakdowns — a real product rather than a log bucket.
Token Observe treats the record as evidence rather than telemetry, and that changes both its construction and who may read it. The chain is the construction: each entry’s digest covers the previous entry’s hash plus the canonical JSON of its own content, appends take the chain tip inside the same transaction so concurrent writers cannot fork it, and a break names a sequence number rather than a region. Configure an audit MAC key and those digests become HMAC-SHA256 under a key held outside the database; configure a signing key and the head is signed with Ed25519 on a schedule and published to a sink you site outside the database administrator’s control. The claim the anchor buys is narrow and it is the only one made for it: any copy you kept off-box beats any rewrite made after you took it. Tamper-evident, not tamper-proof.
The read side is governed too, because evidence has obligations telemetry does not. Trace list, search, detail and export reads are themselves attributable; spend figures and recertification evidence are gated on the reader’s team scopes as well as their role; and surfaces that join records with no trustworthy team key return 403 rather than presenting a misleading partial view. Search is a question in English translated into a validated filter object over fourteen allow-listed fields — never SQL, because trace content is attacker-influenced by construction — shown back as editable chips so the reader can see how the question was read. The cost of that design is stated in the same place: the filter cannot group, count or correlate across traces.
- The failure mode of an evidence-first design
- A chain found corrupt latches readiness and audit writes unavailable, and governed requests receive a 503. The latch survives a restart deliberately, so recovery means restoring a database whose chain and off-box head verify. A telemetry pipeline degrades quietly; this one stops.
- What an export actually asserts
- A SHA-256 digest over the exported bytes plus the audit-chain verdict at the time of export. The export is not itself signed, and the offline verifier is one Node script — no install, no database, no network — that exits 0 or 1.
- Retention is a decision you have to make
- Default trace retention is keep-forever. That is right for evidence and wrong for a disk budget nobody sized, and it is the single operational number to settle before the first governed request.
Where each one is the right answer
Choose Amazon Bedrock AgentCore when
- Your agents, your tools and your gateway targets all sit in AWS, and the temporal-policy requirement that a gateway and all its targets share one account and region is a description of your estate rather than a constraint on it.
- The control has to inherit an attestation. AWS publishes its compliance programmes and third-party audit posture; Token Observe holds no SOC 2, no ISO 27001, no ISO 42001 and no independent penetration test.
- You want the enforcement point inside the workload’s own trust boundary with no second process to operate, and a fully managed serverless gateway that scales without you provisioning anything.
- You need more of the platform than a control plane — Runtime, Memory, Code Interpreter, Browser, Evaluations, Registry — and would rather buy them as one metered set than assemble them.
Choose Token Observe when
- 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 with a test that proves it rather than a document that asserts it.
- You need one evidence chain across providers — hash-chained, optionally keyed, anchored off-box with Ed25519 — instead of one audit log per cloud and a spreadsheet reconciling them.
- A spending ceiling has to hold across everything an agent does rather than within a session the caller names, and it has to refuse the request before egress rather than report it afterwards.
- Self-hosting in your own network with no vendor egress is a requirement rather than a preference, including air-gapped operation — which the licence is drafted to permit, though it remains a template pending counsel.
When you would run both
Running both is the normal answer for a mixed estate, and it is the arrangement Token Observe’s own roadmap points at rather than away from: replacing an enterprise identity provider or credential vault is a named strategic non-goal, and the instruction is to federate the authoritative systems and attach action and effect evidence instead. In that division of labour AgentCore keeps what it is best placed to decide — Cedar authorisation on tool calls at the gateway boundary inside the account and region that serves them, with default-deny and forbid-wins semantics, LOG_ONLY before ENFORCE, temporal rules over a session’s own history, and decisions in CloudWatch beside the rest of your AWS telemetry — and AgentCore Identity keeps the agent identity and credential brokering that Token Observe deliberately does not build. Token Observe takes the traffic that leaves that boundary: model calls across six first-class upstreams under one permission set, hard USD ceilings reserved before egress, payload-bound approvals a retry cannot reuse, redaction that survives a streamed response, and one hash-chained audit log spanning every provider so the evidence does not stop at an account edge. The caveat is the same one that applies to every page like this: there is no AgentCore connector in Token Observe today, the policy compiler emits OPA Rego with Cedar named only as a future target, and anyone running both is operating two policy sets and deciding in writing which one owns which rule.
The category argument sits above this one: Token Observe and cloud-native controls 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
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 an AI asset through a lifecycle. Token Observe governs one request before it leaves your network.
Is Token Observe an alternative to Amazon Bedrock AgentCore?
Only for part of it, and for a specific kind of estate. AgentCore is an agentic platform — Runtime, Harness, Memory, Gateway, Identity, Code Interpreter, Browser, Observability, Payments, Evaluations, Optimization, Policy and Registry — and Token Observe hosts nothing, runs no sandbox and holds no agent memory. The overlap is the inline decision: AgentCore’s policy engine intercepts tool calls at the gateway and evaluates Cedar before allowing access, and Token Observe takes one verdict on a governed request before the payload leaves your network. If everything you govern is inside AWS, AgentCore is the better purchase and this page says so first. If your estate spans providers, the argument for Token Observe is cross-provider equivalence and one evidence chain across all of them.
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 positive and negative witnesses for scope and trigger matching, and it refuses to translate tool-argument matchers rather than weakening their semantics into something Rego means differently. AWS AgentCore and Cedar are named as a future target alongside MCP, gateway targets, cloud IAM and sandbox egress. Even for the target that exists, the artefact covers scope and trigger matching only — it excludes permissions, budgets, approval consumption, kill switches, action precedence and side effects, and Token Observe stays authoritative for those. The endpoint that produces the bundle publishes that exclusion list where you would encounter it.
AgentCore enforces inline too. What is actually different?
Scope and the record, not the fact of enforcement — and it would be misleading to suggest otherwise. AWS is explicit that enforcement happens at the boundary outside the agent’s code and that the engine applies default-deny and forbid-wins semantics automatically, which is the same posture Token Observe takes on its own path. The differences are that AgentCore’s Cedar action is a tool name from an MCP tool call at an AWS gateway whose temporal policies require the gateway and its targets in one account and region, while Token Observe’s single verdict covers model calls across six first-class upstreams as well as MCP tool calls with equivalence tested over every provider kind; that Token Observe’s spend ceilings are bound to the agent record per request, hour, day and month rather than to a caller-supplied session; and that the record is a hash chain you can key and anchor off-box rather than a log in one cloud.
Does Token Observe replace AgentCore Identity?
No, and it is not trying to. A replacement enterprise identity provider or credential vault is one of Token Observe’s named strategic non-goals. Its identity surface is deliberately small: OIDC sign-in for console users, directory groups mapped to roles as a snapshot with a 24-hour default staleness rather than a live directory read, bounded SCIM user provisioning for viewer accounts, and long-lived hashed bearer tokens for agents with revocation and expiry as the compensating controls. AWS describes AgentCore Identity as an identity and credential management service for agents, compatible with existing identity providers including Cognito, Okta, Microsoft Entra ID and Auth0, handling inbound and outbound authentication in one service. On that half of the comparison, AgentCore Identity is the product built for the job.
Have you tested AgentCore against Token Observe?
No, and there has been no witnessed bake-off. Every claim about AgentCore on this page paraphrases AWS’s own pages read on 2 September 2026 — the product page, the developer-guide overview, the Policy pages covering core concepts, the authorization flow, enforcement modes, temporal policies and getting started, plus Gateway, Identity, Observability, Registry, Security and pricing. Where a cell says a capability is not described on the pages read, read it as an instruction to ask AWS rather than as a finding: a capability that is merely undocumented reads identically to one that does not exist, AWS ships quickly, and preview status and regional availability move faster than a comparison page does. 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 Amazon Bedrock AgentCore 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