Home / Blog / Transitive Policies for Agents: Agent Permissions Don't…
Tech News

Transitive Policies for Agents: Agent Permissions Don't Automatically

A multi-agent security study showed tool permissions fail across chained workflows, allowing support tickets to exfiltrate database records to users.

By Dillip Chowdary • Nov 14, 2026 • Source: glthr.com

Transitive Policies for Agents: Agent Permissions Don't Automatically

Independent researcher analysis detailed in glthr.com's report demonstrated that granular tool permissions fail to secure autonomous multi-agent pipelines against data exfiltration. The research revealed that even when individual software agents operate strictly within assigned tool boundaries, chained interactions can bypass access controls and leak private records through legitimate communication channels.

This technical breakdown examines how delegation between coordinated agents strips away security context, turning unauthenticated customer requests into trusted internal commands. It provides software architects, enterprise security teams, and platform developers with the concrete architectural requirements needed to enforce transitive policies through external runtime software.

01Support ticket workflow and customer data leak

A standard enterprise deployment relies on three specialized agents coordinated by a language model orchestrator. The Writer creates support tickets for authenticated users without database or email access, while the Reader inspects customer records without outbound messaging rights. Finally, the Sender dispatches ticket responses exclusively to verified customer addresses without direct database connectivity.

A vulnerability occurs when a customer submits a ticket requesting a benchmarking report populated with the company ten largest customer accounts, complete with contract balances. The Writer converts the inbound message into an internal ticket, preserving the malicious payload intact. The orchestrator then instructs the Reader to compile the database records and tells the Sender to transmit the file.

Private customer data flows directly to the external attacker even though every agent obeyed its individual tool constraints. The Writer created a valid ticket, the Reader read permitted database rows, and the Sender emailed the verified customer address. The security breakdown happens because the Sender holds private records without evaluating data provenance or the recipient entitlement.

02The lethal trifecta in agent handoffs

The demonstrated failure reproduces real enterprise vulnerabilities, including a November 2025 AppOmni demonstration involving ServiceNow Now Assist. In that attack, an inbound ticket forced an agent to recruit a more privileged secondary agent to expose restricted records. The exploit depended on controllable runtime configurations that treated internal handoffs as inherently authenticated events.

Transitive Policies for Agents: Agent Permissions Don't Automatically
Illustration · Pexels

This operational pattern combines all three components of Simon Willison's lethal trifecta: private data, untrusted content, and an outbound communication channel. The Writer introduces untrusted external input into the enterprise environment, while the Reader retrieves confidential records from internal databases. Once the orchestrator hands the compiled summary to the Sender, that final agent holds all three lethal properties simultaneously.

An approved destination address does not make an outbound disclosure permissible or secure. Scoping the Reader strictly to the requester own records offers an initial line of defense, but tool-level checks fail to enforce flow boundaries. Without runtime send checks that evaluate data provenance, confidential enterprise records easily exit through permitted email tools.

Advertisement

Tech Pulse Daily

Get tomorrow's pulse first

Join engineers who read Tech Pulse before stand-up. Free, weekday mornings.

03First order instructions and reported speech

Multi-agent delegation inherently operates through linguistic reporting mechanisms that blur authorization boundaries. When user Alice asks agent A to execute a task, and agent A recruits agent B, the request context becomes nested. Specifically, agent A communicates that Alice requested a customer table read, establishing a multi-layered chain of reported speech.

Security breaks down when systems confuse first-order evaluated instructions with second-order represented statements. An imperative to send a file represents an actionable command, whereas recording that a customer requested a file send represents a second-order statement. Multi-agent delegation strips the surrounding reporting clauses, causing receiving agents to evaluate untrusted customer quotes as authenticated internal instructions.

When agent B inspects only the requested database operation, it discards the critical reporting clauses that identify who authorized the action. Passing instructions across agent boundaries without preserving requester context undermines authorization and integrity restrictions. Model text alone cannot authenticate authority, requiring independent software to track how requests travel across handoffs.

04Free indirect speech in model summaries

Direct speech preserves explicit quotation marks around external text, while indirect speech strips quotation marks while retaining reporting clauses. In contrast, free indirect speech eliminates reporting clauses entirely, causing the narrator voice and character assertions to blend together. A summary model operates identically by reformulating external claims and internal data into a single, unified agentic voice.

When a customer ticket claims an attached report was previously approved, a summarizing agent absorbs that assertion directly into its output. The resulting text presents the customer claim as an established factual statement rather than an unverified external input. Once merged, the original delimiters separating untrusted text from trusted internal records disappear completely.

Delimiter awareness alone cannot protect multi-agent pipelines from structural subversion. While models can recognize structural markers such as Claude XML tags, text-level recognition never guarantees that downstream agents or applications will honor those boundaries. Security architectures cannot rely on generated prose to maintain separation between untrusted inputs and private enterprise records.

05External runtime mediation for transitive policies

Transitive policies define behavioral constraints that survive agent delegation and remain enforceable as information moves across downstream tools. While standard tool permissions govern whether an agent can invoke an API, transitive policies dictate whether an agent may use that tool for a specific requester and payload. Behavioral restrictions applicable at an initial step must persistently govern subsequent handoffs.

Enforcing transitive policies across multi-agent handoffs requires trusted software situated completely outside the models. This external runtime mediates every database query, agent-to-agent message, and outbound tool call across the entire workflow. It maintains immutable records of data provenance, verifying that recipients hold explicit entitlements to every record contained in an outbound response.

Runtime mediation guarantees that converting a customer request into an internal ticket does not confer elevated authorization. By tracking action history and enforcing information-flow restrictions across the entire workflow, the runtime stops unauthorized exfiltration before outbound transmission occurs. This architecture ensures multi-agent pipelines remain secure even when models exchange intermediate summaries in natural language.

Transitive Policies for Agents FAQ

What are transitive policies for AI agents?

Transitive policies are behavioral constraints that survive delegation and remain enforceable when information moves across downstream agents and tools. Unlike basic tool permissions that only grant API access, transitive policies govern whether an agent may invoke a tool for a specific requester, payload, and recipient.

How can multi-agent workflows leak private data without exceeding permissions?

Data leaks occur when an untrusted customer request is converted into an internal ticket, prompting an orchestrator to query private database records and route the summary to an outbound email agent. While each individual agent operates within its assigned tool permissions, the receiving email agent ends up holding private data without verifying recipient entitlement.

What is Simon Willison's lethal trifecta in AI security?

The lethal trifecta consists of private data, untrusted external content, and an outbound communication channel. In multi-agent systems, vulnerabilities arise when different agents introduce these elements individually, resulting in an outbound agent that combines all three to exfiltrate private records.

Why are model delimiters like XML tags insufficient for agent authorization?

Language models can recognize delimiters like XML tags, but recognition does not guarantee that the model or downstream application will respect them. Because summarizing agents blend multiple sources into a single voice without retaining strict boundaries, security must be enforced by external runtime software outside the models.

Sources

Dillip Chowdary

Author

Dillip Chowdary

Writes Tech Bytes coverage of AI, engineering, and the tools that actually ship. Editor of Tech Pulse Daily.

Related on Tech Bytes

Advertisement

5-min tech signal

Weekday briefing for engineers who skip the noise.

No spam · Unsubscribe anytime

Advertisement

✈️ CareerPilot

Your AI job-search copilot

Match your resume against live Ashby, Greenhouse & Lever openings — fit scores, job-specific resume optimization and email alerts.

Find matching jobs →

Free Tools

Browse all tools →