TL;DR: Agent-to-agent workflows using A2A and MCP shift AI risk from human-reviewed prompts to millisecond internal handoffs, creating east-west attack paths that traditional edge controls often miss, according to Salt. The governing assumption that a human can still catch bad logic before execution is collapsing as agents act and delegate faster than review cycles can respond.
NHIMG editorial — based on content published by Salt: LLMjacking and agent-to-agent identity risk in autonomous AI workflows
Questions worth separating out
Q: How should security teams govern agent workflows at runtime?
A: Security teams should govern agent workflows with controls that evaluate prompts, tool calls, and outputs during execution, not only after deployment.
Q: Why do AI agents increase non-human identity risk?
A: AI agents increase non-human identity risk because they can execute many actions quickly once they inherit a credential or tool permission.
Q: What breaks when organisations rely only on perimeter controls for autonomous AI traffic?
A: They miss the most dangerous movement, which happens inside the environment.
Practitioner guidance
- Map every agent-to-agent delegation path Document which identities hand work to which downstream agents, which service accounts support each call, and where undocumented or shadow API endpoints exist.
- Classify internal agent calls as security events Set policy so east-west agent traffic is logged, enriched, and reviewed with the same seriousness as external authentication events.
- Add behavioural baselines for agent identities Define normal request patterns for each agent pair, including data volume, timing, sequence, and peer relationships.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- A closer look at the Agentic AI Action Layer and why Salt places detection there rather than at the edge.
- Examples of how internal agent calls can be baselined and flagged when behaviour deviates from normal peer-to-peer patterns.
- The vendor's own discussion of daisy-chained exploits across customer service, billing, and database agents.
- Operational framing for API attack surface assessment in agentic environments.
👉 Read Salt's analysis of agent-to-agent AI identity risk and east-west attack paths →
Agent-to-agent traffic: what identity teams need to govern now?
Explore further
Agent-to-agent governance exposes a trust propagation problem, not just a permissions problem. Once one agent can delegate to another through internal APIs, the security model stops being about isolated identities and becomes about how trust is inherited across the chain. That matters because a compromised upstream agent can confer legitimacy on the next hop without a human approval point. Practitioners should treat delegated agent trust as a first-class governance object.
A question worth separating out:
Q: Who is accountable when an AI agent delegation chain causes an unauthorised action?
A: Accountability depends on whether the organisation can reconstruct the chain. If logs capture sender identity, recipient identity, task ID, delegation depth, and validation results, investigators can pinpoint the failing handoff. Without that trail, responsibility becomes ambiguous across the orchestration layer and the individual agents.
👉 Read our full editorial: Agent-to-agent identity risk is exposing new east-west attack paths