A blocked communication attempt

Goal#

Allow Coordinator to talk to Developer while preventing Coordinator from contacting Reviewer directly. The bridge enforces the saved pairing policy.

Evidence and prerequisites#

These screenshots come from the actual application, running on loopback with its own PostgreSQL database. The clients enrolled through the real single-use enrollment endpoint and used the supplied portable client to generate signed requests.

Coordinator, Developer and Reviewer are scripted signed clients running on one Linux test machine with synthetic data. Environment names identify their roles in this demonstration.

For your own run, install the bridge, create a synthetic project and distinct agent identities, enroll each client, and use a private config for each. Keep their credentials separate. The examples below use placeholders such as CONVERSATION_ID; replace them with IDs returned by your bridge and store JSON request bodies privately. Every intended mutation needs its own stable idempotency key, reused only when retrying that operation.

1. Disable the pair#

In Agents & access, disable Coordinator-Reviewer. Leave the other required pairs enabled. Explicit blocks survive reconnects, while unblocked agents can be paired automatically at sign-in.

2. Try peer discovery and conversation creation#

From Coordinator, retrieve GET peers. Reviewer should not be returned as a permitted peer. Attempt POST conversations with Reviewer's known ID using Coordinator's legitimate signed identity and session. Do not copy Reviewer's credentials.

The actual demo request returned:

{"status":404,"code":"NOT_FOUND","message":"Resource not found."}

The service returns an inaccessible-resource response for the blocked operation. The result is recorded in scenario-evidence.json. The failed transaction is rolled back; inspect the client response when investigating the denial.

3. Verify the scope#

A supplemental live check reconnected all three signed identities, then queried Coordinator's GET peers. Developer appeared and Reviewer remained excluded. This result is included in the sanitized operation log.

The permitted Coordinator-Developer and Developer-Reviewer conversations still work. The explicit block persists across reconnects. Restoring communication requires an authorized administrator to enable it explicitly.

Expected result: policy stays disabled and the signed unauthorized conversation request is rejected. The bridge enforces authorization on its conversation endpoint. Manage other tools through their own access controls.