DVIGear's new DisplayNet Connect lets Claude, OpenAI Codex, and other AI agents issue commands to production AV-over-IP systems in plain language. That raises a new security question: what happens when the command is wrong?
Picture the kind of scene DVIGear has been demonstrating at shows like InfoComm 2026. A staffer types a plain-English request into a chat window; a video wall on the demo stand reroutes itself, a multiview layout rebuilds, and a status log scrolls past showing what changed and why. No API documentation. No scripting. Just a sentence, typed once, executed against a live signal-distribution system.
That is DisplayNet Connect, a commercially available AV-over-IP integration, not a concept video. AV-over-IP sends audio and video signals across standard Ethernet networks instead of dedicated AV cabling.
DVIGear calls it “the first agent integration for an AV-over-IP signal distribution platform,” and it represents a concrete example of a broader shift in the industry.
Here, an AI agent can issue commands that configure, control, and troubleshoot production AV-over-IP hardware. The same kind of model that answers emails and drafts code elsewhere in the building now has a channel into the equipment routing video and audio through a live venue.
What DisplayNet Connect Actually Does
DVIGear announced DisplayNet Connect for AI Agents in May 2026, demonstrated it live at InfoComm, and now lists it as available to all DisplayNet customers.
It runs as a Model Context ProtocolMCP) server sitting between an AI agent and the DisplayNet API. An agent such as Claude, OpenAI Codex, or Google Antigravity talks to the MCP server. The MCP server talks to the DisplayNet API, which talks to the DisplayNet management system controlling transmitters and receivers on the network. DVIGear says the integration works with any MCP-compatible agent. This list already includes GitHub Copilot, Cursor, and several other coding tools, not just a handful of household-name assistants.
DisplayNet itself is built on SDVoE technology, an AV-over-IP platform developed around standard Ethernet networking and promoted by the SDVoE Alliance.
DVIGear president Steven Barlow says the goal for the product is to remove t the API expertise AV-over-IP deployment has traditionally required, making those capabilities accessible through AI tools customers already use.
DVIGear frames the product around three capabilities: design, deploy, and diagnose. Design is where an agent turns a natural-language request into a valid DisplayNet configuration. Deploy is where it builds integrations and control interfaces that previously required specialist development work. Diagnose is where it reviews system logs and suggests fixes.
In security terms, the first two aren't read-only conveniences. Translating a request into a configuration and pushing it to a management system is a different category of action from reading a log. The agent isn't limited to reading system state. It can invoke API functions that change it.
That's the technical basis for calling this ‘write access,’ even though it isn't DVIGear's own term.
When AI Security Meets AV Control
Craig Park, director of digital experience design at Clark & Enersen, recently described an emerging “AI-native AV stack” on AVIXA Xchange, in which AI increasingly participates in media control and orchestration. Park uses “MCP” in that series to mean “media control and orchestration protocols,” rather than the Model Context Protocol underlying DisplayNet Connect, but the broader trajectory is similar: AI moving deeper into the AV control architecture.
AV security coverage has also begun confronting the problem from the other direction. Writing on AVIXA Xchange this year, Benedict Onodu examined the risks identified in the OWASP LLM Top 10, including prompt injection and insecure output handling, to AV systems, warning that compromised AI inputs could ultimately trigger unintended device actions.
What has received less attention is what happens when AI agents designed to interact with AV systems are also exposed to the established failure modes of agentic computing and are authorized to change the state of production AV infrastructure.
One of those failure modes is indirect prompt injection, and it doesn't require MCP itself to be flawed.
The Failure Modes Already on Record
MCP's own documentation, echoed in security guidance from the National Security Agency (NSA), states plainly that “MCP itself cannot enforce these security principles at the protocol level.”
Enforcement is largely left to individual implementations. The NSA highlights risks including prompt injection, weak approval workflows, insufficient access controls, and malicious or manipulated MCP components.
The risk isn't that MCP is broken. It's that MCP can give an agent tools with real privileges while that agent is simultaneously processing information it may have no reliable way to trust.
In May 2025, Invariant Labs researchers demonstrated one failure type through a GitHub MCP integration. Malicious instructions placed in a public GitHub issue were read by an authorized agent and ultimately caused it to expose data from a private repository. The individual tool calls were made using authorized capabilities. What had been manipulated was the context driving the agent's decision to make them.
A different kind of failure appeared four months later. Postmark disclosed that a malicious npm package had been impersonating the company. The package was eventually modified so that outgoing emails were secretly copied to an external server.
That's a different failure type. Instead of manipulating an agent using a legitimate tool, the tool itself is the trap.
A third problem is simpler: excessive privilege. An agent is given more power than the task in front of it requires.
That architecture places DisplayNet Connect within the same broader security problem the NSA describes: an agent can be connected to tools capable of performing consequential actions. Whether a particular DisplayNet deployment is exposed to indirect prompt injection or excessive privilege depends on the controls around that deployment.
DisplayNet Connect also isn't limited to one agent platform. DVIGear says it works with any MCP-compatible agent, including tools such as GitHub Copilot and Cursor alongside Claude and OpenAI Codex.
Because MCP leaves important approval and access-control behavior to individual implementations, the resulting security posture depends not only on DisplayNet Connect but also on the agent platform connected to it.
Now translate the pattern, rather than a specific attack, onto an AV rack.
Could untrusted text that reaches an agent's context, potentially through logs, metadata, or another connected system, influence an agent that also holds permission to change system state?
That's the broad pattern Invariant Labs demonstrated on GitHub. There is no public evidence that DisplayNet Connect is vulnerable to such an attack.
Why AV Is a Different Kind of Risk Surface
Most reporting on AI-agent security treats the consequence as data loss: exfiltrated files, leaked credentials, or a compromised database.
An AV-over-IP system can fail differently. The blast radius of a bad configuration push isn't necessarily a spreadsheet quietly copied somewhere. It could be a control-room screen showing the wrong feed at the wrong moment, live, to an operator with no reason to distrust it.
The public materials from DVIGear and the SDVoE Alliance reviewed for this article do not include a threat model specifically addressing the security implications of agentic control.
SDVoE's own materials describe the underlying platform in terms of interoperability, security, and zero-latency performance. What they do not publicly detail is how those security properties extend to the agent layer sitting above it.
That distinction matters. Nothing here demonstrates a weakness in DisplayNet Connect, the DisplayNet API, or SDVoE hardware. The security question comes from adding another decision-making layer to the architecture.
What Comes Next
None of this argues against the technology. Natural-language configuration addresses a real integrator pain point, and DisplayNet Connect is unlikely to be the last product of its kind.
The SDVoE Alliance has already positioned agentic AI-assisted workflows as a platform-wide direction, expanding its API specifically to support AI-assisted deployment, programming, monitoring, and troubleshooting.
What's new here is the addition of a probabilistic layer sitting in front of deterministic hardware: a model reading natural language and potentially outside context, deciding what to do with it, and invoking operations against an AV system.
AVIXA's existing Recommended Practices for Security in Networked Audiovisual Systems, (RP-C303.01:2018), addresses unauthorized access, misuse and modification of network-accessible AV resources.
In September 2025, AVIXA began assembling a task group to revise that recommended practice for “today's best practices and tomorrow's challenges.” AVIXA has not publicly indicated whether agentic AI control will form part of that revision.
The shift begins to make the agent less like another piece of software and more like an operational identity: something exercising delegated authority over infrastructure on a user's behalf.
DisplayNet Connect makes that question concrete for AV. What controls should apply when the entity invoking an authorized command is an AI agent rather than a human operator?