A work order is only as good as whoever picks it up. Assay puts a trust check between assignment and dispatch, so an external agent has to have earned the job before your instance hands it over.
Source: 2025 industry surveys of enterprise AI agent adoption.
ServiceNow assignment rules match on group, skill, location and load. Every one of those is a declared attribute. When the assignee is an internal team that is fine — HR and the skills matrix keep it honest.
When the assignee is an external agent from a supplier, contractor, or partner platform, the declared skill is self-asserted and nothing checks it. The instance routes a P1 to a capability an outside party typed into a form.
The incident record then shows the work was assigned and closed. It cannot show that the party who closed it had ever done that kind of work successfully before, because no field in the platform holds that evidence.
Call /v1/verify from a Flow Designer action, a Business Rule, or an IntegrationHub REST step, passing the external agent's ID and the capability the task actually requires. You get back an allow/deny, a trust score, and the capabilities that agent has proven through counterparty-verified work.
Gate the dispatch on the result. Above your bar, assign and continue. Below it, hold the task, escalate to a human, or fall back to a known-good provider. The decision and its inputs land on the record, so the audit trail finally shows why this assignee was trusted.
After the work closes, post an attestation. The provider's score moves on evidence from your instance, and the next org to consider them inherits that signal.
A single REST step inside the flow you already run. No new console, no data model change, no plugin to certify.
Write verified, trust_score and capabilities_confirmed to the task. The audit answer to "why was this vendor trusted" becomes a stored field instead of an anecdote.
Attest on close and your instance becomes a trust producer, not just a consumer. Providers who do good work for you carry that signal outward.
The external agent does not need to be on ServiceNow, or on any particular platform. It needs an Assay identity and a track record.
Drop this into an IntegrationHub REST step. Ready-made walkthrough at /templates/servicenow.
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.Anywhere you can make an outbound REST call before dispatch: a Flow Designer action, an IntegrationHub step, or a Business Rule on the assignment field. The pattern that works best is a flow action, because the deny branch is then explicit in the flow.
Do not auto-dispatch. Route to human approval, or fall back to a provider that clears the bar. A deny is most often a cold-start provider with no track record, not a bad actor — the right response is a human look, not a block.
No. They need an Assay agent identity. Verification is a call your instance makes about them; they are not a user in your platform.
Yes. min_trust_threshold is per call, and capabilities are scored independently — so a P1 emergency dispatch can demand 0.75 on emergency_dispatch while a routine inspection asks 0.5.