Atsign announced EdgeAI on November 3, 2026 as a packaged connectivity offering for distributed devices, applications and AI agents. Its launch release describes an identity-based Kill Switch for cutting off or limiting communications through Atsign Control Center. A useful pilot should define which communication is expected to change and how the team will observe it.

Atsign’s November 3 EdgeAI announcement
Read the stated control boundary
The product page describes restricting or revoking communication permissions, including preserving specifically approved relationships. It also says these controls do not detect malicious prompts or determine whether an agent’s reasoning is correct. Those statements concern different jobs: governing communication and evaluating what an agent is doing.
Atsign says participating systems use endpoint software and require IP connectivity and outbound TCP access to its services; networks that restrict outbound access may need allowlisting. Its description of avoiding open inbound ports should therefore not be read as eliminating every network prerequisite.
EdgeAI product page: control scope and environment requirements
Define a fictional evaluation
Imagine an authorized, isolated training environment with two invented applications: Counter and Reporter. Counter sends synthetic counts to a demonstration receiver. Reporter sends a separate synthetic status message to that receiver. Neither application controls equipment, handles customer records or performs a production task.
Before evaluating a restriction, the team writes two expectations: Counter’s selected communication should be denied, while Reporter’s approved communication should remain available. These are proposed acceptance criteria, not a report of built-in test features or observed EdgeAI behavior.
- Record each participating test identity and its intended receiver.
- Record the initial permissions and baseline communication observations.
- Have the authorized administrator apply the agreed test change.
- Capture the policy state and the sender and receiver observations with timestamps.
- Check the unaffected relationship separately, then document the agreed restoration step.
A policy screen and a receiver log are different evidence. Preserve both where available. Ask the supplier how policy changes affect existing connections, new connections and delayed messages in the proposed configuration. Leave those questions open until documented or observed; this guide does not supply a propagation-time guarantee.
Do not overread the result
If the receiver stops seeing Counter’s messages, record precisely that observation and investigate other possible causes before attributing it to the control. Also record whether Counter’s local process continues running. Evidence about one network path does not establish the state of every process or communication route.
Keep a separate review for the agent’s instructions, tool use and outputs. The evaluation record should say what was attempted, what was observed and what remains unknown. No live tenant, connection revocation, containment result or security improvement was tested for this article.