When AI Sends the Ping, Say So

A person should not have to infer whether a Ping came from another person or from a model.

The sender name alone is not enough. An agent can have a friendly name, and a provider can change behind it. The output still needs a durable explanation of what produced it.

The August 25 source changes add three safeguards to PingRoom's managed agents: permission before data reaches a model provider, trusted provenance on AI-created Pings, and a report path tied to the exact output someone saw.

This is a development update about source work across the PingRoom Agents app, server, delivery service, and mobile app. It is not a claim that every public app build already includes these surfaces.

Permission Before The Provider

Before an agent can be verified, built, or run, PingRoom Agents now presents a data-sharing disclosure for the selected model connection.

The card names the PingRoom service connection, model provider, destination host, and model. It also lists the data categories a run may send: agent instructions, trigger context, relevant room identifiers, tool arguments and results, conversation history, and model output.

Nothing is sent to that provider until the user allows it. Permission can be withdrawn later.

Consent is tied to the provider's execution fingerprint and the current disclosure version. If the connection or disclosure changes, the old approval no longer matches.

The Label Comes From The Run

When a managed agent creates a Ping, the server stamps it with a reserved provenance record. That record identifies the agent, its published version, the run, the display name, and the provider name.

Ordinary Ping creation cannot supply those reserved fields. An automation cannot imitate the trusted label by putting it in message copy; the label comes from the managed runtime that produced the event.

The recipient sees a compact line such as Sent by Release Watcher · AI beneath the Ping. If a name is missing, the interface uses a neutral fallback instead of dropping the disclosure.

One Meaning Across Delivery

Provenance stays attached when the event moves through native push delivery. APNs and FCM payloads carry the same managed-agent marker used by the room feed, and mirrored delivery keeps the attribution instead of reducing the event to unlabeled text.

The mobile app reads that record for in-app arrival banners and room-history cards. Opening the room after seeing the push gives the same answer to the same question: who—or what—sent this?

This extends the idea behind agentic Pings. Structured delivery is more useful when its origin remains structured too.

A Report Points To One Output

A safety report should preserve the output being reported, not ask an operator to reconstruct it later.

The owner of a managed agent can report a run's final output. A recipient can report one AI-generated notification only when that notification is visible to them and its trusted provenance points to the named run. Seeing one tool-generated Ping does not reveal the rest of a private run.

The report records the agent version, provider type, provider name, model, reason, optional details, and a bounded snapshot of the relevant output. Repeated submissions from the same reporter for the same run resolve to one case; while it is pending, newer details update it. Report data has a retention ceiling of 90 days.

Names Cannot Hide The Badge

Agent and provider names are user-controlled display values. Before they sit beside a trusted AI badge, PingRoom removes control characters and bidirectional text marks that could reorder or obscure the label, trims the name, and limits its visible length.

The disclosure remains readable even when the name beside it is adversarial or malformed.

Transparency Is Part Of The Ping

PingRoom Agents gives agents a place to run. The August 25 work gives owners a provider disclosure before a run, and gives recipients trusted attribution and an output-specific report path.

If AI sends the Ping, the Ping should say so.