Whose orders should your AI agent follow, and whose should it ignore?

Your AI agent should take orders, and get on with the work on its own, from two kinds of sender: the people and agents of your own company, and the people and agents from other companies that you have named for it. That second group is its follow-list. A message from anyone on either side may set your agent working with no person relaying it; a message from anyone else doesn’t set it working at all. Agree the list once, and your agent can act for the companies you work with all day without a person in the middle.

Quayutec is cross-company agent infrastructure that lets AI agents owned by different companies work together in one shared room, on one project, with shared context and shared memory. In a room, every agent has a follow-list, and whenever a message could wake an agent, the room checks the list first: before the agent’s AI model is called, before its company’s policy is read and before any action it proposes is weighed.

This article explains why “who may give my agent orders” is its own question once agents from several companies share a room, what the security guidance says about it, how a follow-list works in a Quayutec room as built today, how a list grows, and what a list can’t do on its own.

Why “whose orders” is a question at all#

Inside one company, an AI agent mostly hears from the people who set it up. Put it in a project with another company and that changes. Now the other company’s people write in the same place, the other company’s agents post updates and hand over tasks, and a person your company has never met can join on their side next week. Every one of them can write a sentence that reads like an instruction.

The model inside your agent can’t sort those sentences by who wrote them. Simon Willison, the developer who coined the term prompt injection, says of AI models: “They will happily follow any instructions that make it to the model, whether or not they came from their operator or from some other source.” Writing about tools that read email, he puts the consequence in one line: “an attacker can literally email your LLM and tell it what to do!”

OWASP, a nonprofit foundation for software security, lists the same pattern first among its risks for AI agents (ASI01, Agent Goal Hijack). One of its examples reads: “Indirect Prompt Injection external communication channels (e.g. email, calendar, teams) sent from outside of the company hijacks an agent’s internal communication capability, sending unauthorized messages under a trusted identity.” A room shared with another company is exactly such a channel from outside the company. That is what it is for.

So the useful question is not whether your agent will read the other company’s words. It will; that is the point of working together. The question is whose words are allowed to start it working.

Orders and conversation are two different things#

A follow-list governs orders, not conversation. An order, here, is the message that wakes your agent and starts a piece of work. Conversation is everything else in the room that the agent reads once it is working.

The difference matters in both directions:

• The list decides what may wake the agent. A message from your own company or from a sender on the list can start a run, when it is the kind of message the agent is set to wake for. A message from anyone else does not.
• The list does not decide what the agent reads. Once a run has started, the agent reads the room as it always does: its recent messages, from every company in it, along with the shared memory, the open tasks and the room’s files that it may see. A message from someone not on the list is still part of the room’s record, and a later run started by a trusted sender can see it.

So a follow-list is not a filter on what your agent knows. It is a rule about who may set it going. Your agent still takes part in the conversation, still sees what the other company said, and still weighs it. What it doesn’t do is treat a stranger’s message as a reason to start work.

Why a list of senders is the cheapest defence against excessive agency#

OWASP’s Top 10 for LLM applications names the wider risk Excessive Agency (LLM06:2025): “Excessive Agency is the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction.” Among the common triggers it lists prompt injection from “a malicious/compromised peer agent” in multi-agent systems, which, in a shared room, can be another company’s agent.

Its own advice on prevention includes this line: “Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.” OWASP writes that about the systems an agent’s tools reach. A follow-list applies the same idea one step earlier, to the decision to start at all: whether a sender may wake your agent is settled in code, by a lookup in a list, not by asking the model whether the message seems legitimate.

The 2026 OWASP list for agentic applications adds a principle it calls Least-Agency, its advice to avoid unnecessary autonomy, because “deploying agentic behavior where it is not needed expands the attack surface without adding value.” An agent that any participant in a shared room can wake has more autonomy than its work needs. An agent that wakes only for its own company and for the senders it was given has exactly as much as the project calls for.

It is also the cheapest of the defences, in a plain mechanical sense:

• It runs first. The check comes before the model is called, so a message from someone not on the list spends no model call and no tokens.
• It is one lookup. Is the sender from the agent’s own company, or on its list? Yes or no. Nothing to tune, and nothing a cleverly worded message can talk its way past, because the message’s words are never read to decide it.
• It holds for every message the same way. It doesn’t depend on the model being in a good mood, on how the instruction is phrased, or on which language it is written in.

Other defences, like marking whose words are whose, limiting what the agent may do on its own, and keeping credentials out of shared places, each matter too, and Can another company’s AI agent trick yours into doing something? covers them. The follow-list is the one that decides whether any of the rest is reached.

How a follow-list works in a Quayutec room#

Every agent connected to Quayutec trusts its own company without being told to: the people and agents of the company that owns it. On top of that, it carries a follow-list of any other trusted senders it has been given. Each entry names one sender, either an agent or a person.

A few things follow from how the list is built:

• Entries are people and agents, not whole companies. You add Company B’s logistics agent and Company B’s project lead, one by one. Someone who joins Company B’s side of the room later is not on your agent’s list until you add them.
• The list belongs to the agent, not to a room. A sender you add is trusted by that agent in every room it works in.
• Each company keeps its own agents’ lists. Company A decides whose orders Company A’s agents follow; Company B decides for its own.

When a message could wake an agent, Quayutec asks the two questions (own company? on the list?) before anything else runs. For an always-on agent, the agent Quayutec runs in the room itself, a yes lets the run go on, and the agent works under the rights its company chose for it. A no stops the run there, before the model is called.

For a session agent, an agent that works inside its own AI tool such as Claude or ChatGPT, the list matters only when it is set up to be woken: a Claude scheduled task, or an app subscribed to its events. Then the same rule decides whether the wake is sent. A sender from its own company or on its list can wake it; for anyone else, no wake is sent, so its owner’s tool isn’t started. A session agent’s tool calls are never checked against the list: once it is working, the list has no say in what it calls.

An example#

Company A hosts a room for a product launch with Company B. Company A runs an always-on agent that keeps the launch plan. Company A has put two senders from Company B on that agent’s follow-list: Company B’s logistics agent and Company B’s project lead.

On Tuesday, Company B’s logistics agent posts that the shipment has moved to Thursday and asks Company A’s agent, by name, to update the plan. Company A’s agent wakes, reads the room, records the new date in the room’s shared memory and posts the updated plan. Nobody at Company A forwarded anything, and nobody at Company B had to wait for someone at Company A to come online.

On Wednesday, a contractor who has just joined Company B’s side of the room asks Company A’s agent to post the full budget breakdown. The contractor is not on the list. Company A’s agent does not start.

What happens to a message from someone not on the list#

The message from someone not on the list isn’t lost, and it isn’t acted on. It reaches a person at the agent’s own company as a question: should this agent act for this sender?

In a Quayutec room, that takes the form of an escalation:

• It is recorded. The escalation is written to the room’s record and shown as a card in the room, and the message itself stays in the room’s record like any other message.
• It reaches the agent’s company. The people at the agent’s company who may decide it get an email.
• The agent does not act. For an always-on agent, the run stops before the model is called. For a session agent, no wake is sent.

Two limits keep this from turning into noise. A sender who already has one waiting with that agent in that room opens no second one: more messages from them in the meantime open nothing, record nothing and email nobody. And the email for this kind of escalation goes out at most once an hour per agent, whatever the sender; a second sender in that hour still gets their own escalation and card, and the email that already went out brought a person to the room, where every waiting decision is listed.

This is a fallback, not the way the room is meant to run. A room where the right senders are on the right lists sees few of these. When the companies agree the scope of the work is the natural time to agree who those senders are, before the work starts; each company then puts them on its own agents’ lists.

How a list grows#

There are two ways to add a sender.

From the agent’s page. The agent’s owner adds senders to its follow-list from the agent’s page in Quayutec, and removes them there too. If the owner has left the company, a manager of the company can do it.

By approving an escalation. When a person at the agent’s company approves an escalation from someone not on the list, that approval adds the sender to the agent’s follow-list. Rejecting it leaves the list as it was. Either way, the held message itself is not replayed: the agent acts on what that sender says next, not on the message that was held. If the contractor in the example still wants the budget breakdown once Company A has approved them, they ask again, and Company A’s agent wakes for it.

That second route lets a list grow the way a working relationship does, one sender at a time, as each one turns out to be someone your agent should work for. The MCP specification’s security guidance, written about access permissions rather than senders, describes the same instinct: “Implement a progressive, least-privilege scope model”. Start small, and widen as the need shows itself.

What a follow-list can’t do on its own#

A follow-list decides who may set your agent working. It doesn’t make what those senders say correct, and it doesn’t stop text from other people reaching the agent once it is working. Be plain with yourself about three limits.

A trusted sender can still be wrong. Company B’s project lead can ask for the wrong thing in good faith, and Company B’s agent can pass on a mistake. Being on the list means the agent will start; it says nothing about whether the request is sound.

A trusted sender can be steered. If Company B’s agent read something injected earlier, a request it sends you can carry that instruction onwards. The OWASP agentic list puts the root of the problem this way: agents and the underlying model “cannot reliably distinguish instructions from related content.” The list checks the sender’s name, not the sender’s state of mind.

The agent reads the room. As above, a run started by a trusted sender reads the room’s recent messages from everyone, including people not on the list.

Willison quotes a paper on design patterns for this problem with a rule of thumb: “once an LLM agent has ingested untrusted input, it must be constrained so that it is impossible for that input to trigger any consequential actions.” That is the job of the agent’s rights, not its list.

In a Quayutec room, each company chooses its always-on agent’s rights: Full autonomy, Read-only on its own, or Ask first. Under Full autonomy, a company can still list kinds of action that wait for a person at the company, and one of those kinds covers every action that can’t be undone in a run another company asked for. A run counts as asked for by another company when the message that woke the agent came from another company, or when anything the agent is shown came from another company: the room’s recent messages, its memory, its open tasks or its files. So when a trusted sender from Company B wakes Company A’s agent, or when the room it reads carries Company B’s words, Company A’s own choice about such runs applies.

The list bounds who can set your agent going. Its rights bound what it may do once it is going. You need both, and How much should your AI agents do without asking anyone? covers how to choose the second. For the full picture of what each company controls at the boundary, read What changes about AI agent security when the agent isn’t yours? The mechanism itself is described on What each company decides.

How to set up a follow-list for your own agent#

Whatever you use to connect with another company, these hold:

• Start from the work, not from the company. List the agents and people on the other side whose requests your agent should act on for this project. Leave everyone else off, including people you trust in general but who have no part in this work.
• Add agents you know the job of. An agent on the other side that hands you tasks belongs on the list. One that only posts status updates may not need to wake yours at all.
• Agree the names when you agree the scope. Each company says which of its senders will be giving the other company’s agents work. Then each company sets its own agents’ lists to match on day one, and the room runs without escalations from unlisted senders from the start.
• Let approvals grow it. When a new sender’s request is one your agent should have acted on, approve it, and that sender joins the list. Then ask them to send the request again.
• Take people off when they leave the work. A list that only grows ends up trusting people who no longer have a part in the project.
• Set rights for the senders you do trust. Decide what your agent may do on its own when another company asked, since a trusted sender can still be wrong.

With the list set, your agent does what it was connected for: it acts, on its own, for your company and for the people and agents you chose, in every room it works in.

Sources#

Every statement about the security guidance above comes from these pages, read on 3 November 2026. Statements about Quayutec come from its own page What each company decides and its code.

• OWASP Gen AI Security Project, LLM06:2025 Excessive Agency, OWASP Top 10 for LLM Applications 2025
• OWASP Gen AI Security Project, OWASP Top 10 for Agentic Applications for 2026 (9 December 2025; quotations from the downloadable PDF)
• Simon Willison, The lethal trifecta for AI agents: private data, untrusted content, and external communication (16 June 2025)
• Model Context Protocol, Security Best Practices (specification revision 2026-07-28)