Share fraud signals, not data

Fraud rarely stays inside one company. A mule account flagged by one bank, or a device used in a scam at one retailer, often turns up at a partner days later. Sharing what you know usually means sending customer records to another company, and data protection rules, contracts, and your customers’ trust all argue against that.

Your own fraud systems produce the signals, such as a risk score or a reason code. Agent Gateway carries those signals between partner companies and enforces what each message may contain, rather than detecting fraud or scoring risk itself.

What you can do

• Send risk signals from your agents to a partner’s agents over an encrypted, sender-authenticated gateway-to-gateway connection so that signals reach the partner without a shared database or a custom integration.
• Check every outbound signal against your own policy so that a message carrying a field you have not approved, such as a name or an account number, is blocked before it leaves your gateway.
• Check every inbound signal against the receiving company’s own policy so that each side decides what it accepts.
• Prove which agent sent each signal with a signed presentation of its verified identity so that the partner can trust the source without trusting your network.
• Keep a record of the policy decision for each signal on each gateway, linked to the signal’s signed presentation where it carries one, so that either company can show which signals were allowed, from which agent, and when.

How it works

Each company’s fraud system publishes its findings through an agent, for example a risk score, a reason code, and a reference to the account or device that both companies can match without exchanging customer records. The two gateways connect once, by invitation and approval, as described in Let agents work across companies. Each agent then sends its signals as A2A messages to an A2A surface on its own gateway. That surface’s Managed Agent element has its Endpoint Type set to via Gateway Connection and points at the partner’s surface. Each message travels inside DIDComm v2.1, encrypted for the partner’s gateway and authenticated as coming from yours.

Policy is where “signals, not data” is enforced. Because the signal enters your gateway on that surface, an OPA policy there reads the A2A message itself, including its parts and metadata, as input.a2a.message. A policy can allow only messages that match the signal format both companies agreed and deny anything else, so a message carrying an unapproved field is blocked at your gateway. It can also match patterns in the message text with regex.match, such as an email address or a national ID number format, and block any message that contains one. The receiving gateway’s surface policy reads the same message when it arrives, so each company enforces the agreement from its side.

With a Workload Binding element on the surface’s leg to the partner, each signal carries a signed presentation of the sending agent’s verified identity claims. The partner’s policy can require that presentation before it accepts the signal. A Trust Check can also confirm, against a trust registry, that the sending gateway belongs to the fraud-sharing network. While VP Auditing is on in Settings › Security, each gateway records the policy decisions and presentations for every signal it sent or received, signed with its own key.

A policy allows or blocks a message as a whole. The gateway has no step that removes or masks individual fields, so build signals without personal data at the source and let the policy reject any message that does not match the agreed format. Free-form personal data, such as names and addresses, needs model-backed detection, which Agent Stream applies to the LLM calls your agents make, as described in Keep PII safe in every LLM call. Replies from the partner’s agent are not checked by a response policy on a gateway-to-gateway connection, so agree with the partner what its replies may contain.

Related

• Let agents work across companies: How two gateways connect and carry identity and policy across the boundary.
• OPA policies reference: The input.a2a fields a policy can read, and where each input is available.
• Apply OPA policies to your gateway and surfaces: Create a Rego policy definition and apply it to the surface that carries your signals.
• Workload binding: What the signed presentation carries and how the receiving gateway verifies it.
• Audit log: The record of policy decisions and presentations on each gateway.