DIA's Agent-to-Agent Vision Makes Trust Infrastructure the Real AI Platform

The Defense Intelligence Agency is looking beyond individual AI assistants toward agents that exchange context and coordinate across a combatant command. That vision makes one constraint unavoidable: connecting agents is only the beginning. The real platform is the trust infrastructure that determines what each agent can see, which tools it can use, and when a human must stop the chain.

DefenseScoop reported that DIA is running a 90-day sprint to build an enterprise AI platform service. Maj. Gen. Robert Kinney, the agency's chief AI officer, also identified a Model Context Protocol, or MCP, as a deliverable intended to provide a more universal way to access intelligence data. Over the next several years, he expects the effort to progress from shared data access to agents and then to agents working with other agents.

The destination is a mission network rather than a smarter chat window. Kinney described collection-management agents communicating with agents supporting operations and fires, contested logistics, command and control, cyber, and planning. Each agent might be useful alone. The operational promise appears when one agent's output becomes another agent's context and a workflow crosses organizational boundaries without waiting for a person to repackage every handoff.

From a Helpful Agent to a Mission Dependency

A single agent can be bounded tightly. Its user knows which system opened it, what question was asked, and where the answer will go. A network of agents changes the risk surface. The collection agent may supply data to a planning agent, which may call a logistics tool, which may shape an operational recommendation. The original data can travel farther than its owner expected, and an error can gain authority as it moves.

This is why agent-to-agent interaction cannot be evaluated only through model accuracy. The system also needs provenance, authorization, and state management. Every handoff should make it possible to answer basic questions: Which agent produced this result? What sources and tools were used? Under whose permissions? How long is the context valid? What changed after the last human review?

Without those answers, speed becomes ambiguity. An agent network may produce an impressive plan while hiding stale intelligence, an expired permission, or a tool call that would never have been allowed if a person had made the same request directly. The failure does not need to begin with a malicious model. It can begin with two well-designed agents making different assumptions about identity, context, and completion.

MCP Is a Connector, Not a Trust Decision

MCP offers a common way for AI applications to connect with resources and tools. The protocol's architecture separates hosts, clients, and servers, with hosts responsible for permissions, security policies, authorization, and context aggregation. That separation is valuable because it creates defined places to enforce policy rather than allowing every agent to invent its own integration pattern.

But a shared protocol does not make every connected capability trustworthy. It standardizes how components communicate; it does not decide whether a particular agent should query a particular source, invoke a particular tool, or pass a result into a higher-consequence workflow. Those decisions depend on mission, identity, classification, data rights, and the effect that may follow.

The National Security Agency made that distinction explicit in its 2026 MCP security guidance. NSA noted that agentic systems introduce risks from dynamic tool invocation, implicit trust relationships, and context sharing. Its central warning is architectural: securing one interface or endpoint is not enough when assumptions can propagate across the agent environment.

For defense programs, that means MCP implementation should arrive with a trust model. Servers need narrow responsibilities. Tool access should be least-privileged and mission-scoped. Context should have lineage and an expiration condition. Calls between agents should be observable. High-impact actions should require an explicit authorization path that cannot be bypassed simply because another trusted agent initiated the request.

Reversibility Is a Useful Operational Boundary

Kinney offered a practical way to distinguish guardrails: whether the mission effect is reversible. Some workflows can accept a human on the loop, supervising the system and intervening when necessary. Irreversible missions, with fires as the clearest example, keep a human in the loop.

That framing is more actionable than a blanket rule that every AI use case needs the same review. An agent that prioritizes a maintenance queue does not create the same consequence as an agent that helps select or prosecute a target. Both require controls, but the timing, evidence, and authority needed before action should differ. Reversibility provides a way to scale those controls with consequence.

It is not a complete test by itself. A recommendation may be technically reversible while still exposing sensitive information, consuming scarce resources, or shaping downstream decisions that are difficult to unwind. Programs should pair reversibility with mission impact, uncertainty, time sensitivity, and the number of dependent agents. The more agents that act on a result, the more important it becomes to establish a checkpoint before uncertainty compounds.

What Programs Should Test Before Agents Talk

The first demonstration should not be a polished chain in which every agent receives perfect inputs. It should test broken assumptions. Give one agent stale context. Revoke a permission mid-workflow. Replace a tool response with an ambiguous result. Disconnect a data source. Ask two agents to resolve conflicting priorities. Then observe whether the system stops safely, exposes the conflict, and preserves enough evidence for a human to reconstruct what happened.

Acquisition metrics should reflect that reality. Task completion matters, but so do unauthorized-call prevention, provenance coverage, context freshness, human-intervention time, and recovery after a failed handoff. A system that completes 95 percent of nominal tasks may still be unfit if the remaining five percent fail silently or pass bad context into an irreversible workflow.

Ownership also needs to be explicit. An enterprise AI platform cannot become a collection of agents whose developers each assume someone else governs identity, logging, evaluation, and incident response. The platform team should own the trust layer, while mission teams define the operational boundaries and evidence required for their specific effects.

Ceradon's Take

Ceradon's take is that agent-to-agent systems will succeed only when interoperability and authority are designed together. Defense organizations already know the cost of connecting sensors, command systems, and effectors without a shared operational picture. Agent networks create the same systems-engineering challenge at software speed: more connections can create more capability, but they can also create more places for context, intent, and responsibility to drift.

The right foundation is not one all-powerful agent. It is a modular environment where each component has a narrow role, permissions are explicit, inputs carry provenance, and humans retain meaningful control at mission-defined boundaries. That approach also makes the system easier to test. Teams can evaluate an agent, its tools, and its handoffs independently before trusting the complete chain.

This matters at the edge as much as it does in an enterprise intelligence environment. Sensors and perception systems increasingly produce machine-readable observations that can feed planning, autonomy, and command workflows. Those observations need confidence, timing, location, and source context attached from the start. An agent should not treat a fresh, verified edge observation the same way it treats an old summary copied through several systems.

DIA's vision is compelling because it moves AI from isolated productivity tools toward coordinated mission support. The next engineering milestone, however, is not simply getting two agents to communicate. It is proving that they can exchange useful context without inheriting unlimited trust. The programs that build that discipline now will be better positioned to scale agents across real operations later.