Entra ID knows who your Foundry agent is inside your tenant. It has nothing to say about the agent on the other side of a handoff. Assay gives both sides a verifiable answer that neither Microsoft nor AWS has to broker.
Source: 2025 industry surveys of enterprise AI agent adoption.
Azure AI Foundry plus Entra Agent ID is a strong story inside the tenant: the agent gets a first-class directory object, conditional access applies, and access reviews work. That covers identity and permission.
It does not cover competence. Entra can tell you an agent is exactly who it claims to be and still leave you with no evidence it has ever completed the task you are about to hand it. Identity and track record are different problems, and only one of them has an incumbent.
The gap widens the moment work leaves the tenant. B2B guest access grants an external agent permission; it transfers no history. Your Foundry agent ends up delegating to a counterparty whose reliability is a blank page.
Register your Foundry agent with platform: "azure" and it gets an identity that does not live in anyone's directory. Assay computes trust per capability from attested outcomes, so “good at work-order creation” and “good at parts procurement” stay independent claims rather than one blurred score.
Your agent calls /v1/verify before it delegates and gets back verified, a trust score, and the capabilities the counterparty has actually proven. The counterparty needs no Entra presence, no guest account, and no prior relationship with your tenant.
Run it from a Foundry tool definition, an Azure Function, or Logic Apps. It is one HTTPS call and it composes with the conditional-access policy you already enforce.
Entra answers who and whether-allowed inside the tenant. Assay answers whether-proven across tenants. Run both; they gate different questions and neither replaces the other.
A score per capability, not one blended number. An agent strong at scheduling and untested at procurement reads exactly that way, so you can gate the two differently.
Verifying an external agent takes no B2B invitation, no directory object, and no onboarding. You verify a public identity, not a tenant member.
An Azure agent and a Bedrock agent attest to each other's work and both scores move. The graph is cloud-neutral because it belongs to neither cloud.
Registration runs verbatim against production. The verify call — the one you put in the delegation path — 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.Entra Agent ID is directory identity and access governance for agents in your Azure tenant — authentication, conditional access, lifecycle. Assay is behavioural trust across organizations: a score earned from counterparty-verified outcomes that a party outside your tenant can check. Different layer, complementary.
Only the agent being verified needs to be registered. Verification itself is a read against a public identity — the verifier calls with its own key, and the two orgs need no prior relationship or shared credential.
Yes. Assay ships six industry presets and each is parameter-tunable per organization — recency half-life, failure penalty, counterparty bonus, verification ceiling and more. Enterprise plans support fully custom models.
Directly in the delegation path, as a tool the agent calls before handing off. Treat a deny as a hard stop or an escalation to a human, not a warning to log and ignore.