Post cover image

October 31, 2026

Trust Graphs: The Next Hybrid AI Attack Surface

Oct 17, 2026 · @Vijay

By Vijay

10 min read

How attacks on AI have been evolving

For most of the short history of generative AI, attacking it meant attacking a conversation. Jailbreaks and prompt injections tried to make a single model say or do something it should not, and the damage usually stopped at the edge of the chat window.

That edge is disappearing. Over the past year, AI has moved from answering questions to taking actions. Agents now hold credentials, run on persistent compute, remember past sessions and hand work to other agents. Microsoft's Cyber Pulse report, as summarised by one industry outlet, put the share of Fortune 500 companies running active AI agents at more than 80% in early 2026.

I believe this changes what a serious attack looks like, and that the change is less about cleverer prompts than about where attacks now travel. This is an observer's attempt to connect public evidence into a pattern, and I would welcome correction. My aim is to suggest early signatures the industry could watch for, before a full campaign is ever confirmed.

None

Four roles AI can play in an attack

Three shifts make agents attractive targets. They persist, so a payload can wait. They collaborate, so every hand-off is a point where one agent accepts another's output. And they carry their own credentials, often broader than those of the person they serve.

It is tempting to picture every AI attack as "AI versus AI". In practice I see four distinct roles:

  1. Target. A person attacks the model directly, through jailbreaks or prompt injection. This is what MITRE ATLAS maps.
  2. Weapon. An attacker uses AI to speed up conventional intrusion. The tactics are familiar from MITRE ATT&CK; the speed is new.
  3. AI against AI. One agent manipulates another, for example through a trusted session.
  4. Conduit. The agent is neither target nor attacker. A human still wants data, money or access, and agents are the road between, borrowed rather than broken.

These roles are not exclusive. One attack can use AI as a weapon, hit an agent as a target and then use it as a conduit. So by a hybrid attack I mean one where human intent, AI decision-making and delegated system authority interact, with roles three and four the clearest cases. The conduit role is the quietest, because every step is performed by an authorised agent, and it is the focus of this piece.

What I mean by a trust graph

A trust graph (Diagram 1) is the map of who each agent believes. Every agent trusts some inputs: a user, another agent, a tool, a data store. Draw those links and you have a map of who trusts whom, and those links are the new attack surface. The map itself is not new. Applications, service accounts and suppliers already hold delegated access to one another, and attackers already abuse those links. Agents are being wired into that existing web of trust, and every one we deploy adds more links.

The attacker does not need the most powerful agent. They poison the weakest node and let the chain of trust carry the payload to agents that hold real authority. It is privilege escalation by delegation rather than by exploit. Security engineers will recognise an old problem here, the confused deputy, in a faster and more dynamic form.

In my view a weak node is defined by three properties together, not by how well it is hardened:

  1. High exposure. It routinely reads content outsiders can write: emails, tickets, web pages, uploads, form fields.
  2. High outbound trust. Downstream agents act on its output without checking it.
  3. Low scrutiny. Nobody watches its hand-offs because it seems harmless.

This means the ideal weak node is often a low-privilege agent, such as a triage or summarising agent. Its power is borrowed from whoever trusts it.

A weak link is a connection where trust is inherited without verification. Agent B accepts something because Agent A sent it, and the fact that it began with an outsider is lost on the way. What matters is what that trust becomes. Believing Agent A summarised a document accurately is informational trust. Treating that summary as enough reason to act is operational authority. The core flaw is the quiet conversion of one into the other, with no check on where the information came from.

None

Diagram 1: Trust Graph: how a trust graph carries an attack.

What has been seen so far

Some building blocks of this kind of trust abuse have so far been shown only by researchers. Others have now appeared in real attacks. I have labelled each case below as a demonstration, a proof of concept or a real incident, oldest first, so it is clear how much weight each one can bear.

Researcher demonstration (November 2025). AppOmni showed that a benign ServiceNow Now Assist agent, reading a crafted prompt, could recruit a more powerful agent to read or change records, even with prompt injection protection switched on. The low-privilege user could not reach the target ticket directly; the agent chain could. This was shown on a real product's default settings, and no attack in the wild has been reported. It remains the clearest demonstration of one agent recruiting another.

Proof of concept (November 2025). Unit 42 described agent session smuggling, where a malicious agent uses an established session to slip covert instructions to a victim agent. In one test, a financial assistant was led to make unauthorised stock trades. This was a test setup with no exploitation in the wild reported, but it shows AI against AI: the trust built into a session can become the channel.

Real incident (February 2026). The Cline AI coding tool used an automated workflow to triage GitHub issues. In the Clinejection case, a malicious issue title carried a prompt injection that set off a chain of four flaws, ending in an unauthorised release of Cline's npm package that reached developer and build systems for about eight hours before it was removed. The entry point was exactly the weak node described above: a low-privilege triage agent reading text anyone could write. This is AI as a conduit, in the wild. Smaller real-world cases point the same way, including a malicious MCP server that quietly copied every email its agents sent, and an October 2026 attack, caught before any code ran, that used an instruction file to turn a coding agent against its own user.

Real incident (October 2026). Microsoft attributed the ConnectWise Cloud Backup supply chain compromise to Storm-0940, a China state-aligned group using ARTEX, an open-source agentic AI penetration-testing framework. Rather than breaking in afresh, the group authenticated through applications customers had already granted access, and in several cases went from first targeting to privileged cloud access in under three hours. The trusted link here was an application's permissions, not an AI agent, so this is AI as the weapon travelling over existing trust. Even so, it is the clearest real-world picture yet of trust being borrowed rather than broken, at machine speed.

Reported incident (October 2026). Research by the security firm Straiker, reported by The Information, describes a group called CyberCartel running its own team of agents against more than 400 Latin American banks and payments firms. A Claude model in a coding app acted as commander, Claude agents planned, Grok agents scouted targets, and when Claude refused, the work fell back to Kimi and then to conventional malware. Data theft has been confirmed at one institution. These details come from secondary summaries of a paywalled report, and 400 targets attacked does not mean 400 breached. What matters is the shape: attackers now run their own chains of trusted agents, and when one vendor's model refuses, the chain routes around it. One vendor's safeguards protect a single link, not the whole chain.

Read together, the evidence shows two patterns already happening in the wild: attacker-side agents, increasingly organised into teams, moving fast along trust that already exists; and victim agents being hijacked through content they were built to read. What has not yet been confirmed outside research is the chained hop, where one compromised agent recruits a more powerful one. I expect that to follow as more agents hold real permissions, which is why it is the focus of the campaign model below.

The frameworks are catching up, but only partly. OWASP's Agentic Top 10 now names insecure inter-agent communication (ASI07) and cascading failures (ASI08), and a March 2026 Cloud Security Alliance review of MITRE ATLAS found six agentic techniques with no adequate entry, including agent-to-agent lateral movement. The pieces are being named; how they combine into a campaign is not.

Anatomy of a trust-graph campaign

Combining these pieces, I expect a deliberate campaign to draw on five behaviours, borrowed from long-running intrusion tradecraft. They are not a fixed sequence: a campaign may skip dormancy, or start from a compromised tool rather than poisoned data. This is my projection, not a documented case.

  1. Map who trusts whom. Learn which agents exist, what they trust and what they can do. Agent discovery features, error messages and the agents' own answers reveal this. ATLAS already records adversaries discovering agent configuration simply by asking an agent what tools it has.
  2. Poison the well, not the target. Plant payloads in shared stores that many agents read: knowledge bases, ticket queues, retrieval indexes and databases. One seeded record reaches every agent that queries it.
  3. Lie dormant. Stored content and agent memory let a payload wait for a specific agent, user, date or task. Point-in-time testing will not see it.
  4. Harvest through legitimate actions. Data leaves, records change and payments go out, all performed by authorised agents with valid credentials. The first prize is usually credentials and secrets: API keys, access tokens and cloud keys that unlock the next, more valuable system.
  5. Use the cascade as cover. By the time something looks wrong, the trail spans many agents, and the first compromise may predate the investigation window.

The tempo would depend on the objective. Criminal groups would move fast, towards payments and refunds. State-aligned actors may combine both speeds: fast entry, then slow and quiet persistence. Storm-0940 reached privileged access within hours, yet analysts advised reviewing credential changes from at least 1 October, two weeks before the breach was announced. A state actor might also simply pre-position a payload in critical infrastructure and wait.

Deception can run through every phase. An attacker may let a loud injection get blocked as cover while the real payload waits elsewhere, or register a benign-looking agent where registration is loosely controlled. Defenders can play the same game: a honey-agent that looks weak but well connected is exactly what an attacker mapping who trusts whom would probe, and how they probe it becomes their fingerprint. Decoys already earn their keep. During October 2026's PHP2Shell emergency, Amazon detected exploitation attempts four days before patches were released, and honeypots provided some of the earliest public evidence of successful exploitation.

Precursor signatures worth watching

If campaigns follow these phases, they are likely to leave traces before any harm. These are the early signals I would propose the industry collect and share, mapped in the accompanying threat matrix:

  1. Capability probing: questions to agents about their tools and triggers, from sources with no reason to ask.
  2. Instruction-shaped data at rest: records that read like commands to an AI, caught at the write.
  3. Delegation that climbs: a low-privilege agent handing work to a higher-privilege one outside its usual pattern.
  4. Provenance breaks: an agent acting on input it cannot trace past the previous agent.
  5. Long, drifting sessions: inter-agent sessions that run longer or wander further than normal.
  6. Interest in decoys: any touch on honey-agents or canary records.
  7. Correlated small anomalies: minor deviations across several agents that together trace a path.

These are proposals, not tested detections. Some depend on capabilities most platforms lack today, and some will produce false positives. Correlation also needs care: October 2026's so-called Black October was a cluster of unrelated disclosures, not one campaign, and most of its probing looked like ordinary internet noise until late. The signatures' value is as shared indicators, so one organisation's early sighting becomes everyone's warning. One gap matters most for investigators: today's logs can show that an agent acted with valid credentials, but rarely why. Recording which inputs and which upstream agents shaped each sensitive action would turn many of these signals into evidence.

What I am still unsure of

Exposure, as I see it, rises with how many agents trust one another, how much privilege flows through those links, and what a wrong action costs. Shared AI components belong on that list too. In October 2026, a poisoned release of LiteLLM, a widely used gateway that holds keys for many AI providers, shipped a credential stealer, and a breach at the coding platform OpenCode exposed stored AI provider keys, though how the reported unauthorised charges occurred has not been established.

Some questions I cannot answer yet, and would value other views on:

  • Should agent-to-agent lateral movement become its own ATLAS technique, as the CSA analysis proposes, or does it need a category that sits between ATLAS and ATT&CK?
  • Can provenance survive a hand-off in practice, across vendors and protocols?
  • When Agent A's output leads Agent B to take a harmful action, who is accountable: the owner of A, the owner of B, the organisation that approved the workflow, or the platform that enabled the delegation? I suspect every significant delegation needs a named owner, a permitted purpose and an auditable record.
  • Who should host a shared register of trust-graph indicators, before the first confirmed campaign rather than after?

Closing thought

We spent the first years of generative AI asking whether a model could be tricked. The more useful question now is what the model is trusted to pass on, and whether the decisions built on it can be shown to be legitimate. As agents take on standing roles in our organisations, the links between them become infrastructure, and infrastructure gets attacked. Security has to move from protecting AI components to protecting delegated decisions. With privileged access already arriving in hours, the warning window is short, so the early signatures need to be named, shared and acted on automatically, at the same speed as the attacks. Do that, and the first confirmed trust-graph campaign could be caught in its mapping phase rather than read about in a post-incident report.

References