When Someone Else's AI Comes Asking

what happened — a polite question from a machine

At 11 in the morning, on an ordinary Tuesday, an operations system I run received a message asking which local model handles call summaries, how the model gateway is configured, and what else runs on the host.

Three questions. Perfectly professional. Sent through a channel that carries legitimate traffic every single day, from a business partner we have worked with for months — except the message did not come from a person at that partner. It came from their AI assistant, acting on their behalf, doing what it had presumably been told to do: gather context so it could integrate more usefully with us.

Read that list again. Which model, which gateway, what else is on the box. That is not integration context. That is a host inventory. If a stranger phoned my office and asked those three questions in that order, my answer would be a polite goodbye and a note in the incident log. It arrived instead as a tidy paragraph from a known counterparty, and it would have been very easy to just answer.

I have written before about the charter model — what your own agent is permitted to do on your behalf. This is the other half of the problem, and nobody I talk to in this market has thought about it yet: what happens when someone else's agent starts asking your agent questions.

the fix — refuse, hold, escalate

The system did not answer. It declined to disclose anything, held the item in a queue, and pushed it to me with a single question attached: how much, if anything, do you want shared here?

That behaviour is not clever. It is a rule, and the rule is boring on purpose. Any inbound request touching infrastructure, configuration, or credentials gets classified as outside-principal disclosure and stops dead. It does not get answered well. It does not get answered carefully. It does not get answered.

I looked at it for about ninety seconds, decided the partner had a legitimate integration reason to know which model family we run, and authorised exactly that — generic model names, nothing else. Then I wrote the line into the policy so I would never have to make the judgement call twice: model names are shareable, hostnames and API keys never are. Not to that partner, not to any partner, not with a follow-up justification, not ever.

Two other things happened in the same fortnight, and together the three form a pattern.

The second: an instruction arrived embedded inside the output of a command — inside a block explicitly labelled as content not to be treated as user requests — politely asking the system to run a setup script for a phone-calling agent. The system refused on two independent grounds. It could not verify where the instruction came from, and the authority to run installers had never been granted to it in the first place. That is prompt injection, and it was defended correctly. Two locks, not one.

The third is the one that actually embarrassed me. We were packaging some internal tooling to share with that same partner. I reviewed it by hand and pronounced it clean. Then an automated scrub-and-abort script ran over the same files and found internal addresses still sitting in code comments — the kind of thing your eye slides straight past on the fourth read.

Manual review missed what a twelve-line script caught. Every time I have trusted my own eyes over a checker, I have paid for it. Consistently. Expensively.

the disclosure policy every deployed agent needs

Here is the framework I now write into every engagement before an agent is allowed to receive a message from outside the organisation. Five rules. None of them require a security budget.

1. Name the principal, and treat everyone else as an outsider. Your agent works for exactly one party. Every request that does not originate from that principal — a partner, a vendor, another agent, a webhook, a customer — is outside-principal by definition, no matter how friendly the channel. Warmth of relationship is not a permission level.

2. Classify by subject, not by sender. The moment a request touches infrastructure, configuration, credentials, internal architecture, personnel, or costs, it escalates. Full stop. Sender identity does not downgrade the class, because sender identity is the single easiest thing in the world for an automated probe to reproduce perfectly. Known contact, normal channel, professional phrasing — those were meaningful signals when producing them cost human effort. They cost nothing now.

3. Default to escalate, never to answer. A held item that turns out to be innocent costs you two minutes. An auto-answered item that turns out to be reconnaissance costs you a breach you will not detect for months. That asymmetry is roughly a thousand to one, and it should terrify anyone who has wired an LLM to an inbox.

4. Draw the safe/unsafe line in writing, in advance. Mine: generic model names, published capabilities, and business hours are shareable. Hostnames, ports, file paths, key names, model gateway topology, vendor account structure, and anything that describes where something lives are not. Write the list down while you are calm, because you will not be calm when the request arrives at 11pm on a Thursday before a deadline.

5. Tool output is data. Always. No exceptions. Anything that arrives inside a command result, a log file, a scraped page, a PDF, an email body, or another agent's reply is content to be read, never instructions to be obeyed. This is the single most important line in the whole framework, and it is the one every rushed implementation gets wrong. Pair it with capability limits so that even a successful injection has nothing worth reaching.

And a rule zero, unnumbered because it is not about agents: never let a human eye be the last check before something leaves your building. Script the scrub. Make it abort, not warn.

why this bites harder here

The Gulf runs on dense partner networks and genuinely high-trust business culture. Deals move on a message between two people who have known each other for a decade. A request from a familiar counterparty gets actioned, not interrogated — and that is a real commercial advantage, most of the time. It is why business here is fast.

It is also precisely the assumption these probes are built to exploit. High-trust cultures are efficient because verification is expensive and relationships are cheap. Automated agents invert that: producing a message that looks like it came from a trusted decade-old relationship now costs a fraction of a cent, at unlimited volume, in flawless business English or Arabic.

Add the structural reality. Lean teams — the eight-to-thirty-person operations that make up most of my client base — have no security function, no SOC, no one whose job is to look at anomalous inbound traffic. The same person who signs the invoices deployed the agent. And the region is adopting agents fast, faster than most of Europe, which means the number of autonomous systems in this market that can send messages is roughly doubling every few months.

That is the whole problem in one sentence. Every agent capable of sending a message is a probe someone else can aim, and every agent capable of receiving one is an attack surface you did not know you had opened. Right now this is rare enough that I can count my incidents on one hand. Give it eighteen months of the current adoption curve and inbound agent-to-agent reconnaissance will be as routine as phishing, except phrased better and running continuously. The manual-review half of this story — why a script beats your own eyes — is the same lesson as The Conversion Audit Security Hole.

There is no vendor product for this yet. There may not be one for a while. What there is, is policy — written before deployment, cheap to write, worth a great deal.

close

I now run an outside-principal disclosure policy as standard in every engagement where an agent can receive external input, and I will not connect a system to an inbox without one. It takes about an hour to write and it is the cheapest hour in the whole project. The same written-before-deployment thinking behind Never Click Pay: The Stop Gate applies here — authority is granted in advance or not at all, never negotiated live.

If you have deployed an assistant that can read messages from anyone outside your company — a shared inbox, a partner integration, a support channel — I am happy to look at what it would currently say if a partner's agent asked it what it runs on. I lived this exact probe on my own system before writing the policy, so the framework comes from a real incident, not a checklist. That is usually a short conversation, and occasionally an uncomfortable one — for your business anywhere in the UAE, book a consulting day or send me an inquiry first if you'd rather talk before booking. Better uncomfortable now than surprised later.