Bedrock gives your agent an execution environment. It does not give the agent a reputation that means anything outside your AWS account. Assay does — a portable identity and a trust score any counterparty on any cloud can verify.
Source: 2025 industry surveys of enterprise AI agent adoption.
AWS IAM answers “is this principal allowed to call this API in my account?” That is the right question inside AWS and the wrong question the moment a Bedrock agent hands work to an agent it did not build — a partner's scheduler, a supplier's dispatcher, a customer's ERP bot.
Cross-account roles can carry permission across the boundary. They cannot carry track record. A freshly assumed role and a role attached to an agent that has completed 400 verified jobs are indistinguishable to IAM, because IAM was never designed to score behaviour.
So the Bedrock agent delegates on faith, and the audit trail records that a call was authorized — never that the callee was any good at the work.
Register the agent once with platform: "bedrock". Assay mints a platform-neutral agt_ identity and an API key that belong to the agent, not to AWS. Trust starts at a neutral 0.5 and is earned only through attested outcomes, each one naming the counterparty that witnessed it.
Before your Bedrock agent delegates, it makes one /v1/verify call and gets an allow/deny plus the list of capabilities the counterparty has actually proven — not the ones it claims. Trust computed on Assay is identical whether the counterparty runs on Bedrock, Azure AI Foundry, ServiceNow, or a laptop.
It works through the Bedrock AgentCore gateway as a plain HTTPS tool, or over MCP. No VPC peering, no cross-account role, no shared secret with the counterparty's org.
The agent's agt_ ID and trust score are yours, not your AWS account's. Move the workload to another region, another account, or off Bedrock entirely and the reputation follows it.
Register the verify call as an AgentCore gateway target or an MCP tool. It is one HTTPS request with a sub-second p50 — safe inside an agent's tool-call loop.
Every attestation names the other party to the work. Self-reported success without a witness is capped by a verification ceiling, so an agent cannot talk itself up.
A Bedrock agent and an Azure agent accumulate trust in one graph, each citing the other. Neither cloud mediates and neither can see the other's account.
Runs as-is. Registration is anonymous and free; the verify call needs the key registration hands back.
verified reflects the trust
threshold and account status. It does not fall to false because a claimed capability
is unproven — an unproven capability simply does not appear in
capabilities_confirmed. Gate on both fields.No, and it should not. IAM decides whether a principal may invoke an API in your account. Assay decides whether an agent has earned the work. Keep IAM on the permission question and add Assay for the trust question — they gate different things and both calls are cheap.
No. The platform field is metadata for discovery and reporting, not a constraint. The same agent identity works if you move it to Azure, ServiceNow, or your own container — that portability is the point.
Whatever your policy says. Assay returns the decision inputs — verified, trust_score, capabilities_confirmed — and your agent applies the rule. A common pattern is auto-dispatch above 0.7, human approval between 0.5 and 0.7, and refuse below 0.5.
Assay's verify, trust and passport endpoints run a sub-second median in production. Verification is not the slow part of an agent loop.