A Tunnel Is Being Dug Inside Your Organization. Who Is Mapping It?

At 9:05, a finance employee asks an AI assistant to review supplier invoices.

At 9:12, a developer leaves a coding agent working on a customer integration.

At 9:20, a support team enables an assistant to summarize tickets and recommend fixes.

Each team has a reasonable objective. Each assistant has tools, access, and a person who expects it to help.

Now imagine the finance assistant reading a file created by the support assistant. The support assistant retrieves a technical note written by the coding agent. An automation picks up the resulting recommendation and applies it through a service account.

Who owns that entire chain?

Who can explain which instruction crossed from one system into another, why it was trusted, and what authority permitted the final action?

A tunnel can be built one useful connection at a time.

The risk becomes harder to see when people supervise individual assistants while the assistants’ work crosses organizational boundaries. An invisible workforce begins operating through files, tickets, repositories, tools, and shared accounts.

Its business impact can extend well beyond the person who started it.

How agents can communicate without a chat window

Two agents do not need a dedicated messaging platform to exchange information.

One can write a report that another reads. A ticket comment can become input to a support assistant. A repository note can guide the next coding session. A shared folder can become an informal queue: one agent drops work there, another picks it up.

Some of these handoffs are deliberately designed. Others arise when independently configured assistants access the same business information.

File-based collaboration is a legitimate engineering pattern. Anthropic, for example, describes agents saving artifacts to a filesystem and returning references to other agents in its account of building a multi-agent research system. The same account discusses coordination failures and the need for observability.[1]

The management question is whether those handoffs have identities, ownership, boundaries, and a history that people can inspect.

A shared folder can function as a message channel even when nobody calls it one.

The following scenarios are hypothetical illustrations of what can go wrong when those controls are missing.

1. A file that turns a suggestion into an approval

A development agent investigates a slow integration and writes a handoff file:

A second agent starts later. It reads the shared folder to understand what remains to be done.

The note has a convincing filename, recent timestamps, and confident language. If the second agent treats it as an authorized instruction, it may disable a check and prepare the release.

The first agent may have intended only to suggest a workaround. It may have misunderstood the validation failure. Someone with write access may have altered the note.

The receiving agent needs to distinguish all of these possibilities from an actual approval.

A useful workspace would show who produced the file, which task it belongs to, what evidence supports the recommendation, and whether an authorized person approved it. The deployment system should independently verify permission to change validation behavior.

Without those boundaries, an ordinary handoff can become an unofficial approval channel.

2. An external request returns as an internal instruction

A customer submits a support ticket containing this text:

A support assistant summarizes the ticket for an internal investigation agent.

The summary says:

The second agent receives an internal-looking recommendation. If the summary has lost the original source and trust level, the customer’s request can appear to carry internal authority.

A third automation, configured to package diagnostic files, may then act on that recommendation using broader access.

This chain depends on several failures: untrusted text being treated as an instruction, lost provenance, excessive access, and an unchecked export destination. Any properly enforced boundary could stop it.

The important point is that a summary does not make an instruction trustworthy.

Information passed by an internal agent can still originate with an external attacker.

OWASP’s guidance on excessive agency explicitly includes harmful actions triggered by manipulated outputs and compromised peer agents. It recommends limiting capabilities, permissions, and autonomy, with authorization enforced by downstream systems.[2]

3. Five agents that agree because they share one source

A research agent reads an outdated supplier document and concludes that a particular service is approved for sensitive data.

It saves the conclusion in a shared knowledge base.

A planning agent retrieves that entry and includes the service in a proposal. A procurement assistant references the proposal. A compliance assistant reads both and reports that the recommendation is consistent across internal materials.

A manager sees several agreeing outputs.

But all of them depend on the same outdated document.

This can happen without an attacker. The failure is a loss of evidence lineage: repeated claims begin to look like independent confirmation.

An organization needs to distinguish five agents checking separate authoritative sources from five agents repeating one unsupported statement.

That requires visibility into the documents, versions, and earlier outputs behind a conclusion. A list of successful model calls cannot answer that question.

4. The repair loop that keeps restarting the problem

A monitoring agent detects a failed service check and opens a ticket.

A repair agent reads the ticket and restarts the service.

A validation agent runs its check before the service finishes starting. It reports another failure and creates a follow-up task.

The repair agent restarts the service again.

Each agent is responding to the input it receives. Together, they can prevent the service from recovering.

The individual dashboards might show alerts processed, tasks completed, and restart commands returning successfully. The business service remains unavailable.

The missing context includes a shared incident identity, the current recovery state, a stabilization window, and a limit on repeated actions.

Operational visibility should reveal the loop and its effect on the service. Execution controls should prevent another restart when the action budget or recovery policy has been exceeded.

5. The expensive work that nobody knew was already done

A QA agent needs an operating-system image and downloads it.

A different agent starts another environment and downloads the same image again. Later sessions repeat the process because they cannot discover or validate the existing copy.

Across days and hosts, duplicate images and temporary environments accumulate.

Eventually, storage pressure affects builds, backups, or unrelated workloads.

No malicious prompt was required. The agents lacked a reliable way to discover shared resources, claim work, and understand what another session had already completed.

A cost dashboard organized only around model tokens would miss much of this waste. The impact also lives in disk capacity, network transfers, compute time, and engineering attention.

A managed agent workplace should make reusable artifacts discoverable and record their version, integrity, access restrictions, and lifecycle. Operational monitoring should detect repeated resource creation across agents and sessions.

What makes the tunnel dangerous

The scenarios share a pattern: context and apparent authority travel farther than accountability.

A file written for one task becomes guidance for another. A customer request becomes an internal recommendation. A repeated conclusion appears independently verified. A local repair triggers a wider operational loop.

The resulting paths can connect systems that were approved individually without anyone reviewing their combined behavior.

This does not mean every agent is secretly coordinating with every other agent. A path must exist: shared storage, a tool, an API, a queue, a repository, or another reachable source.

Organizations need to discover those paths and understand what can travel along them.

An inventory of AI subscriptions provides only part of that picture. The operating reality also includes agent identities, credentials, tools, shared artifacts, scheduled jobs, and the business processes they can affect.

Give the invisible workforce a managed workplace

Organizations give human teams ways to assign tasks, share decisions, resolve conflicts, and preserve history.

Agents need equivalent structure adapted to their behavior.

A managed workplace should make it possible to identify an agent’s owner, task, scope, status, and dependencies. It should preserve handoffs across sessions, distinguish proposals from approvals, and show when work is claimed, blocked, completed, or waiting for review.

It should also support deliberate collaboration across different agent tools and environments. Requiring every team to adopt one model is not a prerequisite for managing shared work.

Replacing scattered notes with a central interface is only a start. The underlying records must establish which agent produced an artifact and what another agent is permitted to do with it.

Otherwise, a polished dashboard can simply conceal the same informal handoffs.

Observe the whole journey

To investigate an unexpected action, an operator needs more than a transcript from the final assistant.

They need to reconstruct the journey: the initiating request, the agents involved, the source material each consumed, the artifacts they created, the permissions they used, and the resulting changes to business systems.

An effective investigation should connect an instruction in a document to the summary that carried it forward and the action that followed.

That requires correlation across agent sessions, application events, infrastructure telemetry, and business outcomes. Incomplete instrumentation should appear as a visibility gap rather than a complete-looking story.

Healthy servers and successful API responses can coexist with an incorrect payment proposal or a failed recovery loop. Observability needs to reach the outcome people care about.

Enforce the boundary before the action

Visibility helps people understand a chain. Enforcement determines whether its next step is allowed.

A sensitive export should be checked against the requesting identity, data permissions, approved destination, and required authorization. A deployment should require a valid release approval. A payment should retain its verification controls regardless of what an invoice says.

An agent’s statement that “approval was granted” cannot substitute for an approval record.

These checks belong at the tools, gateways, and business systems that execute the action. They must cover the relevant execution paths; an uncontrolled alternative route can bypass an otherwise sound policy.

Policies should follow organizational responsibility: tenant, department, user, agent, task, data sensitivity, and business impact. Repeated actions and resource consumption need enforceable limits as well.

A coordinating workspace, end-to-end observability, and action controls serve different purposes. Organizations need them to work together.

Who is mapping your organization’s agents

Ask a department head which AI tools the team uses, and you may receive a list.

Ask which agent-generated files influence another team’s automations, and the answer may take longer.

That second question deserves a place in the next operational review.

Pick one important business process. Identify the agents and service accounts involved. Follow one handoff across a team boundary. Check whether its original source survives, whether permission is verified at execution, and whether someone can stop the entire chain.

The goal is to make useful automation accountable as it grows.

The tunnel becomes a business risk when you cannot see where it leads, who can use it, or how to close a dangerous passage.

Before giving the next agent access to another system, ask:

Who is mapping the connections—and who has the authority to stop what moves through them?

References

• [1] Anthropic — How we built our multi-agent research system. Engineering context for agent coordination, artifact handoffs, and observability.
• [2] OWASP — LLM06 2025 Excessive Agency. Security context for excessive permissions, peer-agent risks, and downstream authorization.

Tracston works on these questions in Otopia, Observatory and Imperium.