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 elements in parallel and writes results into input.trust_check_results for OPA evaluation.

Two placements are available, each checking a different agent:

• Access Point → Managed Agent edge (caller leg): verifies the inbound caller. Available on all protocols.
• Managed Agent → Transit Point edge (target leg): verifies the downstream agent at the Transit Point destination. The drop slot is available on A2A and AP2 Transit Points only. MCP Transit Points do not offer this slot.

Results are written to OPA under input.trust_check_results.caller and input.trust_check_results.target respectively.

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

Panel

The sidebar panel shows the configured queries as a read-only list (query type and trust registry name). Open the fullscreen editor to add or edit queries. Each leg 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 leg 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 leg.

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"
}

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 specifies the Issuer that signs the records and the Authority that acts as the trust anchor.

Entry fields

Each row in the entry list configures one registry target.

Custom resources

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

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.