Trust elements

Two canvas elements operate on trust registries. Trust Check runs TRQP queries against a registry at request time and exposes the results to OPA policies. Trust Recorder writes agent-registration records into registries as requests pass through the surface.

For conceptual background, see Trust registries.

Trust Check

Drop a Trust Check element on a surface edge to run a TRQP query against a trust registry at request time. The Trust Check stage runs all configured queries in parallel and writes results into input.trust_check_results for OPA evaluation.

Three placements are available, each checking a different agent:

Caller-leg results are written to input.trust_check_results.caller. Results from either target leg are written to input.trust_check_results.target.

Each Transit Point has its own Trust Check, and a request sees only the results of the Transit Point it goes through. A Transit Point with no Trust Check runs no target-leg check: the gateway does not fetch the destination’s agent card for trust, verify its identity, or query a trust registry for it. Trust Check audit records for these requests name the Transit Point by its alias.

A Trust Check on the Managed Agent’s own target leg runs only for an A2A proxy or gateway target. On a Direct URL target, its panel shows This Trust Check blocks Save on a URL target: remove it, switch the target, or move the checks to a Transit Point edge.

For the OPA fields these results populate, see OPA policies reference.

Trust Checks copied to Transit Points

A surface with copied Trust Checks shows a banner above the canvas that counts the Transit Points to review, for example 2 Transit Points need Trust Check review. When some of them belong to other variants, the banner says so, and you switch to each variant to review it. Each copied Trust Check carries a warning badge on the canvas, and its panel and fullscreen editor show Review this migrated Trust Check with a Keep button.

Save the surface to apply either action.

On an MCP Transit Point, a copied Trust Check is read-only. Its panel shows “Trust Checks can’t be changed on an MCP Transit Point; keep or remove this migrated copy.”, and its button opens the queries as View Queries…. New Trust Checks cannot be added to an MCP Transit Point.

Removing a copy stops that Transit Point’s checks, so a policy that denied on their results now allows its traffic. A rule that only looks for failed results also allows a request when no checks ran. To require that checks ran, see Require target-leg checks in policy.

Panel

The sidebar panel lists the configured queries by number and record type, with each query’s name when it has one. On a Transit Point it notes Applies to this Transit Point only. Open the fullscreen editor to add or edit queries. Each Trust Check allows a maximum of 10 queries.

Query fields

Each query in the fullscreen editor has these fields.

The id field is auto-generated for each query and used by OPA to address results in input.trust_check_results.{caller|target}[]. It is not editable in the UI.

Validation constraints

• Each Trust Check allows a maximum of 10 queries.
• Authority ID must be non-blank on the target leg.
• On the caller leg, a stored {{ … }} template other than the verified-issuer default is invalid. Replace it with an explicit Issuer or Authority selection.
• Action and Resource are required for Authorization queries and must not be blank.
• Query id values are auto-generated and must be unique within a Trust Check.

Template syntax

All four query fields accept {{ }} templates resolved against the input.* JSON the gateway builds for the same request. Templates follow the OPA input namespace, so a value from the policy input is available using the same path you would use in a Rego rule.

{{ input.agent.provider_did }}         → resolved DID of the agent's department/provider
{{ input.agent.did }}                  → effective caller DID
{{ input.source_auth.claims.sub }}     → JWT subject claim (jwt_bearer auth only)
{{ input.http.path }}                  → request path

A || fallback operator is supported for fields that may be absent:

{{ input.extension_identity.did || input.agent.did }}

The right-hand side is used only when the left-hand side is missing or null. A non-scalar value (array, object) or a malformed template short-circuits with TEMPLATE_RESOLUTION_FAILED and does not fall through to the right-hand side.

When a template fails to resolve, the element produces ok = false with error.code = TEMPLATE_RESOLUTION_FAILED and no TRQP network call is made.

Result fields

Each element in input.trust_check_results.caller and input.trust_check_results.target has this shape:

{
  "id": "tc-caller-1",
  "trust_registry_id": "tr-main",
  "query_type": "recognition",
  "ok": true,
  "error": null,
  "name": "Verify caller department",
  "authority_id": "did:web:authority.example.com",
  "entity_id": "did:web:caller.example.com",
  "action": "is",
  "resource": "ownedAgent",
  "query_resolved": true
}

Error codes

Rego patterns

Address a result by id rather than array index:

# Allow only when the named element passed
allow if {
  some r in input.trust_check_results.caller
  r.id == "tc-caller-1"
  r.ok == true
}

Deny on any stage failure:

deny if {
  some r in input.trust_check_results.caller
  r.error != null
}

Branch on a registry-level problem report code:

deny if {
  some r in input.trust_check_results.caller
  r.error.code == "TRUST_REGISTRY_PROBLEM_REPORT"
  r.error.message == "AGENT_NOT_RECOGNIZED"
}

Require target-leg checks in policy

Attach the policy below with a Policy element on the Managed Agent → Transit Point edge. Inbound requests carry no Transit Point results, so the same rule on the Access Point denies every inbound request. A request through a Transit Point with no Trust Check carries no target-leg results. A rule that only denies on a failed result, such as deny if { some r in input.trust_check_results.target; not r.ok }, therefore finds nothing to deny on a request through that Transit Point. When a policy depends on target-leg checks, also require that they ran:

allow if {
  count(input.trust_check_results.target) > 0
  every r in input.trust_check_results.target { r.ok }
}

To depend on one specific check, address its result by id, as in the first pattern above.

Trust Recorder

The Trust Recorder element writes agent-registration records into one or more trust registries on the response leg (Managed Agent → Access Point). It runs after the managed agent responds, so the agent’s DID from the reply is available to record. Each entry targets one registry and names the Authority that acts as the trust anchor for its records. For the steps to set one up, see Record your agents in a trust registry.

The Trust Recorder’s fullscreen editor has a collapsed How do Issuer, Authority and Entity relate? panel that summarises the fields below:

• Authority: the trust anchor that asserts every record the entry writes.
• Entity: who a record is about, either the agent’s DID or the entry’s Issuer.
• Issuer (this entry): the DID recorded as the Entity of custom records whose Entity Target is Issuer DID. It does not sign records or set the Authority.
• Surface Issuer: the Issuer selected in the Surface node’s Issuer setting. It matters only for entries whose Authority is Use surface Issuer.

Entry fields

Each row in the entry list configures one registry target.

Records written for a managed agent carry the agent’s display name, taken from the surface name, as context. The gateway also publishes Authority and Issuer names to the registry. See How names reach the trust registry.

Custom resources

Each entry can include additional custom records. Custom resources extend the standard owned-agent record with operator-defined registrations.

Last outcome

On a saved surface, the Trust Recorder panel and its fullscreen editor show a Last outcome row: the most recent recording attempt among the surface’s managed agents. It shows the status, the reason when one applies, how long ago the attempt ran, and the record counts across all entries (created, already existed, failed). Before the first attempt it shows No attempt yet.

The status is the recorder’s last known outcome, not a live check of the trust registry. The gateway keeps one status per surface and managed agent. Deleting the surface, or adding, removing, or changing its Trust Recorder entries, clears the status until the next response. The Identities page shows the same status for each managed agent. See How identities are named and listed.

Related

• Access Point reference: Trust Check on the caller leg.
• Managed Agent reference: Trust Check on the Managed Agent leg.
• OPA policies reference: how Trust Check results appear as input.trust_check_results in Rego.
• Trust registries: conceptual background on TRQP queries and trust registry connections.