When agent delegation becomes unauthorized access

Agents routinely delegate work and call tools on each other's behalf. Those ordinary handoffs can give a restricted agent access to capabilities it was never meant to use.

A support agent cannot export customer records. A reporting agent can, after approval. Through delegation, the support agent can ask the reporting agent to export those records.

The tool is legitimate. The reporting agent has access. If the control checks only that final agent, the unauthorized request can pass. Sensitive records leave through an approved operation.

Ordinary delegation can become unauthorized access.

Routine handoffs can create dangerous paths

Hidden instructions in a customer ticket can push the support agent to request an export. This is prompt injection, LLM01 in the OWASP Top 10 for LLM applications, and the agent delegates to the reporting agent through the same route it uses for legitimate work. The attacker is using a connection the application already provides.

Inspect the agents separately and this exposure is easy to miss. The restricted agent reaches a legitimate tool through another agent. The dangerous capability comes from their connection, not from either agent on its own.

As applications connect more agents and tools, these routes multiply. Teams can believe their permissions are sound while a forbidden route remains open.

Delegation should pass the task. It should never pass the permission.

Complete visibility means understanding the agents, their capabilities and their connections as one application. Kodem reconstructs those relationships from runtime memory, including reachable paths that have never been used. This is the practical shape of agentic AI security: the unit of risk is the connection, not the component.

Memory exposes what traffic alone cannot

Several agents can share one process, one service account and one network connection. At that level, they look like one application. Inside it, each agent has its own tools, models, guardrails and delegation relationships. Workload-level permissions cannot express all those differences.

Kodem reads runtime memory, the working state of the application while it runs. It reconstructs the loaded agents and the capabilities attached to them, without requiring an application SDK, code changes or repository access for runtime discovery. The same runtime intelligence that tells you which packages and functions actually execute also tells you which agents exist and what they can reach.

That depth exposes blind spots with real consequences:

• A dormant agent can hold a powerful tool, ready to act when invoked.
• A guardrail declared in a console can be absent from the running application.
• A local model can operate outside the traffic routed through an AI gateway.
• A delegation path can connect a restricted agent to sensitive data.

These capabilities create exposure before they produce an event. Memory analysis helps teams address a dangerous path before its first use. It is worth being precise about what this evidence is: these are reachable paths, derived from how the agents are wired, not a recording of data that moved.

You cannot control a dangerous path you cannot see.

Stop the forbidden action and keep the application running

The same export tool can serve an approved reporting task or a forbidden support request. The difference is the agent behind the request and the path that brought it there.

Kodem combines agent and delegation context with supported gateway and host enforcement. It can restrict a tool call, deny a network interaction, or stop an agent's communication with a targeted kill switch. The scope follows the customer's policy and the capabilities of the integration.

For the support example, the rule is clear: the support agent cannot request customer-data exports, including through the reporting agent. With the corresponding origin-aware control configured, enforcement denies that request while allowing the reporting agent to continue serving approved work.

The policy follows the request across the handoff.

Controls are scoped, reversible and under customer approval. The response can target the offending capability while preserving the rest of the service. None of this is a guarantee that an attack cannot happen, and it should not be sold as one. It is a precise restriction placed where the evidence says it belongs.

Verify the protection in the running application

Blocking a dangerous action contains the immediate attempt. Removing an unsafe tool connection or delegation path addresses the underlying exposure.

Kodem re-inspects runtime state to check whether the change reached the application. Testing the configured control confirms whether it rejects the forbidden action under the tested conditions. Teams can verify both the changed exposure and the restriction, rather than waiting for the event to recur as the only proof that something worked.

Routine connections between agents can create a direct route to sensitive data, and checking each agent separately can miss it entirely. An allowed tool becomes an unauthorized capability through delegation.

This is why runtime AI security and runtime application protection are converging rather than splitting into two disciplines. Agents run inside applications, in the same processes and the same memory, and the evidence that governs them is the evidence that already governs everything else running there. For the wider map, our researcher's guide to AI application security covers the full stack.

Find the hidden path. Stop the dangerous action. Keep legitimate work running.

Frequently Asked Questions

What is agent delegation, and why is it a security concern?

Delegation is one agent asking another to carry out a task on its behalf, which is normal and necessary in multi-agent applications. It becomes a security concern when the receiving agent holds capabilities the requesting agent does not, because the task crosses the boundary and the permission can effectively cross with it. The handoff itself is legitimate; the combination is what creates exposure.

How can a restricted agent reach data it is not allowed to access?

By asking an agent that is allowed to. If a support agent cannot export customer records but a reporting agent can, the support agent can request the export through the reporting agent. The tool is legitimate and the final caller is authorized, so a control that inspects only the agent making the final call can let the request through.

Why isn't checking each agent's permissions enough?

Because the dangerous capability does not live in any single agent. Each one can look correctly scoped in isolation while the route between them is open. Reviewing agents separately is exactly the method that misses this class of exposure, which is why the connections have to be reconstructed and assessed as one application.

Can an AI gateway or network monitoring detect this?

Only partially. Several agents commonly share one process, one service account and one network connection, so delegation between them does not necessarily cross the network at all. A gateway sees calls that leave the workload, not in-memory handoffs, the tool registry behind each agent, or a model served locally.

What does origin-aware enforcement mean?

It means a control decides based on which agent originated a request and the delegation chain behind it, not just the identity of the workload or the agent making the final call. That is what allows a policy to deny a customer-data export requested by a support agent, including through a reporting agent, while the reporting agent continues serving approved work. Controls are scoped, reversible and under customer approval, and they are not a guarantee that an attack cannot occur.

How do you verify that a control actually stopped the action?

By re-inspecting runtime state to confirm the change reached the running application, and by testing the configured control to see whether it rejects the forbidden action under the tested conditions. Both halves matter: that the underlying exposure changed, and that the restriction behaves as intended. The alternative is waiting for the event to recur, which is not verification.