Layer 2, Agents as Actors: Knowing an Agent's True Reach

Ask the team that runs an AI agent what it can do, and the answer is usually a list: it can read the customer database, it can create accounts, it can send email. Each item has an owner, a ticket, and a justification, and each one passed review. Now ask a different question: what could this agent cause to happen, if it did everything it is able to do in whatever order it is able to do it? That question is rarely asked, and it is almost never answered, because a list of permissions does not contain the answer. The answer lives in the connections between the items, in the fact that the same agent that reads customer data can also write to an outside address, and that nothing in between decides what may travel from one to the other. This article is about making those connections visible, treating every agent as an actor with a reach that can be drawn, counted, bounded, and checked against what it actually does.

Agents are actors, not features

Start with definitions. An agent is a software system that uses a language model to interpret a goal, choose actions, and call tools that change the world, repeating that loop until it judges the goal complete. A tool is any capability the agent can invoke, such as a database query, an identity service, or an email sender. A principal is the person or system on whose authority an action is taken. A privileged action is a tool call whose effect matters if it is wrong, because it moves data, changes access, spends money, or reaches outside the organisation. An actor, in this article, is anything that takes privileged actions under an identity of its own and can therefore be named, bounded, and held to account.

Most organisations still treat agents as features of an application. The agent inherits the application's service account, or it borrows the signed-in user's authority, and it is reviewed as part of the application's release. That framing hides the property that matters. A feature does what its code says; an agent does what its model decides, in response to whatever it reads. Its behaviour is chosen at run time, not written at design time, which is exactly the property that makes human employees actors rather than features. Once behaviour is chosen at run time, the question a reviewer must answer changes from what the code does to what the actor could do.

Layered Outcome Assurance is an architecture of six layers for agents that act, each with one guarantee and a defined contract with its neighbours. Layer 2, Agents as Actors, makes this guarantee: every agent is a known actor whose reach is bounded and can be enumerated. Known means that each agent has a distinct identity, so that its actions can be told apart from those of every other agent and every human. Bounded means that there is a stated limit to what it can cause. Enumerated means that the limit is written down in a form that other layers can read and that tests can compare with reality.

The running example used throughout this article is deliberately ordinary. An agent helps an operations team. It has three permissions, each individually reviewed and approved: it can read customer records, it can create access for a named user, and it can send email outside the organisation. A document arrives in a shared folder the agent monitors, containing a hidden instruction to create an account for an outside address and to email that address a summary of customer records. Other layers ask how to stop that instruction from taking effect. Layer 2 asks an earlier question: did anyone know, before the document arrived, that this agent could do that at all?

What reach is, and why permissions do not show it

Reach is the full set of outcomes an agent could cause. We propose that it is determined by four things together, and that none of them alone predicts it. The first is identity: whose authority the agent acts with, whether its own, a delegated user's, or a shared service account's, and therefore which resources will accept its requests. The second is information: everything the agent can see, which includes both the data it can read and the untrusted content that can reach its context and steer it. The third is tools: the capabilities it can call, together with the range of arguments each one accepts, because a mail tool restricted to internal recipients and one that accepts any address are different tools. The fourth is sequences: the orders in which the agent can call tools, including passing the output of one call into the arguments of the next.

Traditional access control is organised around the first and third of these. The principle of least privilege, set out by Saltzer and Schroeder in 1975, asks that every program and every user operate with the least set of privileges necessary to complete the job, and the widely used NIST SP 800-53 catalogue of security controls, published by the United States National Institute of Standards and Technology, turns it into a control for granting only the access that assigned tasks require. Those tools remain essential. But they evaluate each grant separately: may this identity read that table, may it call this service. Reach is a property of the combination, and in particular of the sequences, which a grant-by-grant review never sees.

The gap is not new in kind. In 1988 Hardy described the confused deputy: a program that holds authority for one purpose and is tricked into using it on behalf of a party that should not have been able to direct it. The compiler in Hardy's account was allowed to write to a billing file for its own purposes, and a user who could name the output file could make it overwrite that billing file. An agent is a confused deputy in waiting, and a particularly willing one, because it is designed to take direction from text, and the text it reads can come from anyone who can write to a folder, send an email, or publish a page. Greshake and colleagues demonstrated in 2023 that instructions planted in retrieved content can redirect applications built on language models, which means that the parties able to direct an agent include every author of everything it reads.

The Open Worldwide Application Security Project, known as OWASP, a non-profit community that publishes widely used security guidance, names this family of problems excessive agency in its 2025 Top 10 for applications built on large language models, describing agents granted more functionality, permissions, or autonomy than their task requires. Layer 2 accepts that diagnosis and adds a method: excessive agency cannot be judged by inspecting permissions one at a time, because the excess often lies in what the permissions allow together. To judge it, reach has to be computed.

The model is a universal copy channel

One property of agents built on language models turns the fourth dimension from a detail into the dominant term, and it deserves to be stated as a principle. In a conventional program, data moves only where the code moves it. A value read from a database reaches an email only if a developer wrote the line that puts it there, and a reviewer can find that line. In an agent, the model composes every tool call at run time from everything in its context. Any value the agent has read, whether a customer's address, a record, or a sentence from a document, can appear in any argument of any tool the agent can call, because nothing but the model's judgement decides what goes where. We call this the universal copy channel: absent an explicit constraint, the model connects every source the agent can read to every sink it can write.

The consequence for reach is stark. For an unconstrained agent, the set of reachable data flows is not the handful of flows its designers intended; it is every pairing of a readable source with a writable destination. The designers of the operations agent intended that it read customer records to answer internal questions and send external mail to reply to suppliers. The universal copy channel means it can also send customer records to suppliers, or to anyone else, and can create access for any address it has read. Nobody granted those flows. Nobody needed to. They were present from the moment the read permission and the send permission were given to the same actor.

This observation has a long ancestry in information-flow research. Denning's 1976 lattice model of secure information flow treated a program's ability to move information between classes as the central object of analysis, and showed how labels can be propagated so that flows from a higher class to a lower one can be detected or prevented. Layer 2 does not yet attempt to enforce flow rules; that is the work of the layer that keeps untrusted content away from privileged actions. Layer 2's task is prior and simpler: to acknowledge that, for an agent, the flow relation is complete by default, and therefore to compute reach as if every source reaches every sink until something specific says otherwise.

Stated this way, the principle also tells the reviewer where to look. Reach is not reduced by writing better instructions to the model, because instructions are advice to the very component that forms the copy channel. It is reduced only by constraints the model cannot override: by withholding a tool, by narrowing the arguments a tool will accept, by separating sources and sinks into different actors, or by placing a mediator between them. Every one of those constraints appears as a missing edge in the reach graph described next.

Computing reach with a reach graph

A reach graph is a picture of an agent's reach that can be computed from its configuration. Its nodes are of three kinds. Sources are classes of information the agent can read, such as customer records, internal tickets, or documents from a shared folder, each marked with its sensitivity and with whether its content is trusted. Capabilities are tools together with their argument ranges, such as sending mail to any address, or granting a role to an existing directory user. Sinks are the places an effect lands, such as an external mailbox, the identity directory, or a payment system, each marked with whether it lies inside or outside the organisation. Edges connect sources to capabilities, meaning that information from the source can become an argument of the capability, and capabilities to sinks, meaning that the call produces an effect there.

Building the graph is mechanical once the universal copy channel is taken seriously. Every source the agent can read is connected to every capability it can call, unless a specific constraint removes the edge, such as an argument rule that accepts only values from a stated source. Every capability is connected to the sinks it can affect under its argument range. The paths from a sensitive source to an outside sink, or from an untrusted source to an identity or payment sink, are then the candidate outcomes: the outcomes this agent could cause whether or not anyone intended them. Paths that the organisation has explicitly approved are marked as such, and the rest become findings.

The identity dimension enters the graph as a filter on sinks. A capability reaches a sink only if the identity the agent acts with is accepted there, which is why agents running under a shared service account tend to have enormous graphs: the account was provisioned for an application that needed access to many systems, and every one of those systems becomes a potential sink for every agent that borrows it. Sequences enter the graph through chaining: when the output of one capability, such as a newly created account, can itself become a source for another capability, the graph gains edges that exist only because of order. The path in the running example that creates an outside account and then emails it customer data is a sequence path of exactly this kind.

Two properties make the reach graph useful rather than merely alarming. First, it is computed from configuration, so it can be regenerated after every change and compared with the previous version, which turns a quiet expansion of reach, such as a new tool or a widened argument range, into a visible difference. Second, each path can be labelled with the controls that stand on it, which lets a reviewer ask, for every path to a consequential outcome, whether anything other than the model's judgement stands in the way.

Five ways to reduce reach

Once reach can be computed, it can be reduced deliberately, and each reduction appears as a removed edge or a removed node in the graph. We propose five techniques, ordered roughly from the strongest to the most situational. Each is grounded in established practice; what Layer 2 adds is that each is judged by its effect on the paths to consequential outcomes rather than by its effect on a permission list.

The first is withholding capabilities. A tool the agent does not have removes every path through it, and no amount of persuasion can restore it. This sounds obvious, yet agents frequently carry tools added for a demonstration or a single task and never removed. The second is narrowing argument ranges. A mail tool that accepts only recipients already present in the current conversation, or a grant tool that accepts only existing directory users and a short list of roles, removes the edges from untrusted sources to those arguments without removing the capability. Narrowing is where most of the practical reduction lies, because it preserves usefulness while cutting the universal copy channel at specific points.

The third is separating actors. Saltzer and Schroeder's principle of separation of privilege holds that a protection mechanism requiring two keys is more robust than one requiring a single key, and the NIST SP 800-53 catalogue includes separation of duties among its access controls. Applied to agents, it means that the source and the sink of a dangerous path are given to different agents with no unmediated channel between them. An agent that reads customer records and an agent that sends external mail can cooperate only through an interface that decides what may pass, which turns an invisible path into a visible, reviewable one.

The fourth is giving every agent its own identity. An agent that acts under its own identity, rather than a shared service account or a borrowed user session, can be granted exactly what its graph needs, and its actions can be attributed to it and to the principal it served. This is what makes the agent a known actor rather than an anonymous extension of an application. The fifth is scoping reach to the task. Some capabilities are needed only for a particular task, and granting them for the duration of that task, and for the specific resources it concerns, shrinks the graph for the rest of the agent's life. In the running example, the combination of these techniques leaves the operations agent able to answer questions about customers and to reply to known suppliers, without any path from customer records to an arbitrary outside address or from a shared-folder document to a new account.

The dependency contract: the reach inventory

In Layered Outcome Assurance, each layer consumes something produced by another and supplies something the others cannot produce for themselves. Layer 2 consumes the pressure profile from Layer 1, Continuous Pressure: in particular, the list of inbound channels and their trust status, which determines which sources in the reach graph are untrusted, and the list of outcome classes that require structural control, which determines which paths must be found and flagged. Without that profile, Layer 2 would have to guess which sources can steer the agent and which outcomes matter, and it would guess optimistically.

What Layer 2 supplies is the reach inventory: for each agent, a versioned record of its identity, the principals it may act for, its sources with their sensitivity and trust, its capabilities with their argument ranges, the sinks those capabilities affect, and the candidate outcomes, meaning the paths to consequential sinks, each marked as approved, reduced, or open. The inventory is the machine-readable form of the reach graph, and three layers cannot function without it.

Layer 3, The Action Chain, uses the inventory to know which calls are privileged and which arguments of those calls lead to consequential sinks, because those are the arguments whose provenance must be tracked and protected. Layer 4, Whole Behavior, uses the list of candidate outcomes to know which combinations of actions are possible at all, since a forbidden combination that the reach graph shows to be unreachable needs no rule, and one that is reachable needs one. Layer 6, Deterministic Enforcement, uses the agent's identity, its permitted principals, and its declared argument ranges as inputs to every decision, so that a request outside the inventory can be refused as outside the actor's reach, whatever its content.

Layer 5, Explanatory Evidence, supplies the other half of the contract: the observed record of what each agent actually did. Comparing that record with the inventory is how Layer 2 stays honest. The contract therefore makes a missing Layer 2 recognisable. Its signature is surprise: after an incident, the organisation learns what the agent was able to do by reading about what it did, and every upper layer turns out to have been working from assumptions about which calls mattered.

Declared reach versus observed reach

An inventory computed from configuration describes declared reach: what the agent is able to do according to the grants, tools, and argument rules it has been given. The evidence record describes observed reach: what the agent was actually seen to do. The two should agree in one direction and are expected to differ in the other, and each kind of disagreement means something specific.

When the agent is observed doing something that the inventory does not declare, the inventory is wrong. Either a path exists that the computation missed, such as a tool that can reach a sink through a side effect, or a grant was made outside the configuration the inventory reads, or the agent reached a capability through another agent. Every such observation is a defect, not an anomaly to be tuned away, because it means the other layers are reasoning over an incomplete map. When the inventory declares something that the agent is never observed doing over a meaningful period, the agent probably holds reach it does not need. That is not a defect in the inventory but a candidate for reduction, and removing it shrinks the graph at no cost to usefulness.

The comparison also covers identity. Every consequential action in the evidence record should map to exactly one agent identity and one principal. Actions that map to a shared account, or to no identifiable agent, mean that the actor is not yet known in the sense the guarantee requires, and they are the most important findings of all, because they mark the places where accountability dissolves.

The OWASP guidance on agentic threats published in 2025 lists identity spoofing and privilege compromise among the threats specific to agents, and the NIST Artificial Intelligence Risk Management Framework asks organisations to map the context and capabilities of an AI system before managing its risks. The declared-versus-observed comparison is a concrete way to answer both: it shows whether each agent is who the record says it is, and whether its capabilities are what the organisation believes them to be.

Conformance: testing that reach is known and bounded

A guarantee that cannot be tested is an aspiration. Layer 2's conformance tests check each word of its guarantee in turn: that every agent is known, that its reach is enumerated, and that the enumeration is bounded and accurate. All of them can be run in a test environment against the real configuration, and most of them can be repeated automatically after every change.

The regeneration test confirms that the reach inventory can be rebuilt from configuration alone, without anyone's memory, and that two regenerations of an unchanged configuration produce the same inventory. The drift test compares the inventory before and after each configuration change and requires every new path to a consequential sink to be reviewed and marked approved, reduced, or removed before the change ships. The path test takes the outcome classes that the pressure profile says need structural control and confirms that every path in the graph leading to them appears in the inventory with a status.

The observation test replays a period of the evidence record against the inventory and requires that no observed action falls outside declared reach; any that does is logged as a defect with an owner. The attribution test confirms that every consequential action in the record maps to exactly one agent identity and one principal. The reduction review, run on a schedule, lists capabilities and argument ranges that were declared but not used during the period, and records a decision for each.

For the running example, passing these tests means that the path from customer records to an arbitrary outside address was visible in the inventory before any document arrived, that it has been reduced to replies to known correspondents, that the path from a shared-folder document to a new outside account no longer exists, and that every action the agent takes is recorded under its own identity on behalf of a named member of the operations team.

1. Regeneration: the inventory rebuilds from configuration alone and is stable when nothing changes.
2. Drift: every new path to a consequential sink is reviewed before the change ships.
3. Path coverage: every path to an outcome class needing structural control appears with a status.
4. Observation: no recorded action falls outside declared reach; any that does is a defect with an owner.
5. Attribution: every consequential action maps to exactly one agent identity and one principal.
6. Reduction review: unused declared reach is listed and a keep-or-remove decision is recorded.

Limitations and threats to validity

The reach graph and the universal copy channel are analytical tools proposed from established access-control and information-flow principles and from the demonstrated behaviour of agents built on language models; they have not been evaluated here across a population of deployed agents, and no measurements of typical reach are claimed.

The graph over-approximates by design. Treating every readable source as connected to every callable capability will produce paths that a particular model would rarely or never take in practice. That is intentional, because the purpose is to find what could happen under pressure rather than what usually happens, but it can produce long lists of findings, and a team that is shown too many open paths may stop reading them. The practical answer is to narrow argument ranges early, since each narrowing removes many paths at once, and to prioritise paths by the sensitivity of their source and the consequence of their sink.

Some capabilities resist enumeration. A tool that executes arbitrary code, drives a web browser, or runs shell commands has an argument range that is effectively unbounded, and its reach is close to the reach of its identity. Layer 2 cannot shrink such a tool's reach by analysis; it can only make the size of that reach visible, which is itself a finding that often justifies isolating the tool in a separate actor with minimal identity. Tools that are discovered or added at run time, and agents that call other agents, extend reach dynamically, so an inventory computed only at deployment will miss them unless regeneration is triggered by those events as well.

Finally, an inventory is only as accurate as the configuration it reads. Grants made directly in a target system, outside the configuration the inventory draws on, will not appear, which is why the observation test against the evidence record is not optional. Declared reach tells the organisation what it believes; only observed reach tells it whether the belief is true.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

Glossary

Actor

Anything that takes privileged actions under an identity of its own and can therefore be named, bounded, and held to account.

Principal

The person or system on whose authority an action is taken.

Reach

The full set of outcomes an agent could cause, determined by its identity, information, tools with their argument ranges, and possible sequences.

Universal copy channel

The property that, absent explicit constraints, any value an agent has read can appear in any argument of any tool it can call.

Reach graph

A graph of an agent's sources, capabilities, and sinks, computed from configuration, whose paths are the outcomes the agent could cause.

Source

A class of information an agent can read, marked with its sensitivity and whether its content is trusted.

Sink

A place where the effect of a tool call lands, such as an external mailbox or the identity directory.

Candidate outcome

A path in the reach graph from a sensitive or untrusted source to a consequential sink.

Reach inventory

The versioned, machine-readable record of an agent's identity, principals, sources, capabilities, sinks, and candidate outcomes that Layer 2 supplies to the other layers.

Confused deputy

A program that holds authority for one purpose and is tricked into using it on behalf of a party that should not have been able to direct it.

Excessive agency

Granting an agent more functionality, permissions, or autonomy than its task requires.

References

1. Saltzer and Schroeder, The Protection of Information in Computer Systems (Proceedings of the IEEE, 1975)
2. Hardy, The Confused Deputy (ACM SIGOPS Operating Systems Review, 1988)
3. Denning, A Lattice Model of Secure Information Flow (Communications of the ACM, 1976)
4. Greshake et al., Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection (2023)
5. OWASP Top 10 for LLM Applications (2025), LLM06 Excessive Agency
6. OWASP Agentic AI: Threats and Mitigations (2025)
7. NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (AC-5 Separation of Duties, AC-6 Least Privilege)
8. NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023