Back to BlogStartups & GTM

The Agent-to-Agent Attack Vector: Why Your Governance Stack Must Evolve

5 min read

Every founder I talk to right now is proud of how fast their AI agents have gone from novelty to infrastructure. Agents are drafting contracts, querying other agents for pricing, negotiating API terms, and increasingly acting on behalf of one company while talking to an agent acting on behalf of another. That last sentence is where most governance stacks quietly stop working. We built our security and compliance programs around a human typing into a chat window. We did not build them for two autonomous systems negotiating on a public network with no human in the loop until after the decision is made.

This is not a theoretical risk. It is an architectural gap. And as a founder or operator, closing it is now a core governance responsibility, not a research curiosity for your AI team.

The Shift From Prompts to Protocols

For the past two years, AI governance has largely meant prompt and output monitoring: red-teaming a model, filtering inputs, logging completions, and reviewing transcripts after the fact. That approach made sense when the unit of risk was a single human-to-model exchange. It breaks down the moment your agent is no longer talking to a person, but to another agent, possibly one your company does not control, built on a different stack, with its own incentives, instructions, and failure modes.

Standards for structured agent communication, such as Anthropic's Model Context Protocol and Google's Agent2Agent protocol, exist precisely because the industry recognized that agents need a common language to discover one another's capabilities and exchange tasks. That is a meaningful step forward for interoperability. It is not, by itself, a security model. A shared protocol tells two agents how to talk. It does not tell either agent whether it should trust what the other one says.

Why Identity Is the New Perimeter

In traditional network security, the perimeter was the firewall. In cloud-native systems, the perimeter became identity: who is this service, and is it authorized to do this specific thing. Agent-to-agent systems need the same evolution, but most startups have not made the leap.

The Handoff Problem

The highest-risk moment in any multi-agent workflow is the handoff: the instant one agent delegates a task, shares context, or accepts output from another. If your agent cannot cryptographically verify who it is talking to and what authority that counterpart actually holds, every downstream action inherits that uncertainty. A compromised, spoofed, or simply misconfigured counterpart agent can inject instructions, exfiltrate context, or trigger actions your own agent was never authorized to take on your behalf.

Verifiable Credentials for Machines

The fix is not more prompt filtering. It is applying the same identity discipline we already use for services and employees to agents themselves. That means every agent should carry a verifiable, revocable credential tied to its operator, its permitted scope of action, and an auditable chain of delegation. Concepts like SPIFFE/SPIRE for workload identity and mutual TLS for service authentication were not designed with AI agents in mind, but the underlying principle translates directly: never trust a counterpart based on what it claims about itself in plain text. Trust what can be cryptographically verified.

What a Modern Agent Governance Stack Looks Like

I think about agent governance in four layers, and most companies I advise are strong in one and weak in the other three.

  • Identity and authentication: every agent, internal or external, has a unique, verifiable credential and a defined, revocable scope of authority.
  • Policy enforcement at the handoff: permissions are checked at the moment of delegation, not assumed from the prior step in the chain.
  • Immutable provenance logging: every inter-agent exchange is logged with enough fidelity to reconstruct who instructed whom, and why, after the fact.
  • Kill-switch and containment: the ability to revoke an agent's credential or isolate it mid-workflow without taking down the entire system.

Notice what is missing from that list: prompt-level content filtering. That control still matters, but it addresses a different threat. It cannot substitute for identity and authorization controls at the network layer where agents actually interact.

The Founder's Responsibility

I have sat across the table from enough boards and enterprise buyers to know what is coming. The question will shift from "how do you secure your model" to "how do you secure the agent that your model dispatches into the world, and how do you know what it agreed to on your behalf." If you cannot answer that with specificity, you will lose deals to a competitor who can.

A governance stack built only for human-to-model interaction is a governance stack designed for a world that is already behind us.

This is also a legal exposure question, not just an engineering one. If your agent transacts with a counterparty's agent and the outcome is disputed, your ability to demonstrate authorization, scope, and provenance will determine whether that is a minor incident or a material liability. Treat agent identity architecture with the same seriousness you treat your cap table or your customer contracts.

Practical Steps to Start Now

  • Inventory every agent in your environment that can initiate action or exchange data with an external system, and assign each one a formal identity.
  • Define explicit, minimal scopes of authority for each agent and enforce them at the point of delegation, not just at deployment.
  • Require cryptographic verification, not self-reported identity claims, before any agent acts on instructions from another agent.
  • Build provenance logging into the handoff layer now, while your agent workflows are still simple enough to instrument comprehensively.

The companies that win the next phase of this market will not be the ones with the most capable agents. They will be the ones whose agents can be trusted to interact with anyone else's, because the identity and authorization layer underneath them was built correctly from the start. That is a governance decision, and it belongs on the founder's desk.