The interaction layer governs what the agent can request, send or trigger through tools and external services. The infrastructure layer governs what workloads, applications and data paths the agent can reach once it is inside the environment. Both matter, because failure in one layer can undermine the other.
Why the Agent Interaction Layer and Infrastructure Layer Are Different Security Problems
The interaction layer is the policy boundary for what an agent may ask for, invoke, or transmit through tools, prompts, APIs, and external services. The infrastructure layer is the environment boundary for what that agent can actually reach after it has been granted execution context. Treating them as the same control plane creates false confidence, because a well-bounded request path can still land on an overexposed runtime.
The distinction matters because each layer fails in a different way. Interaction-layer weakness usually shows up as unsafe requests, tool abuse, or excessive delegated authority; infrastructure-layer weakness usually shows up as broad network reach, overprivileged compute, and weak segmentation. Good agent security needs both, because agent authorisation does not compensate for an open backend, and a hardened backend does not compensate for a permissive tool policy.
A practical way to think about it is that the interaction layer governs intent translation, while the infrastructure layer governs blast radius. If the agent can ask for too much, the interaction layer is failing. If the agent can do too much once a request is accepted, the infrastructure layer is failing.
What Changes at the Interaction Layer
The interaction layer should answer questions like: can the agent call this tool, with what arguments, for which user or task, and under what approval rule? This is where request filtering, per-action authorisation, scoped tokens, and human approval gates belong. It is also where you decide whether an agent may chain actions automatically or must pause before a sensitive step.
That layer is about constraining agency before work is delegated. If the policy is too broad, an agent can misuse a legitimate tool without ever needing deeper system access. That is why MCP security and related tool access patterns matter: the risk is not only the transport protocol, but the authority implied by each tool invocation.
Interaction-layer controls are usually evaluated by the quality of the decision at request time. The questions are whether the agent is authorised for the specific action, whether the call is attributable, and whether a human or policy engine can intervene before a dangerous request is executed.
What Changes at the Infrastructure Layer
The infrastructure layer starts after the request is accepted. It governs runtime containment, network reachability, storage access, secrets exposure, service connectivity, and the agent’s ability to move from one foothold to another. Even a properly authorised action can become damaging if the underlying environment has flat network access or shared credentials.
This layer is where segmentation, runtime isolation, workload permissions, and data-path restriction matter most. If the agent runs in a broadly trusted environment, a single compromised workflow can become an environment-wide incident. The strongest interaction policy in the world will not help if the agent inherits standing privilege and unconstrained reach inside the network.
Infrastructure controls are judged by containment, not just approval. The key question is whether a compromised agent instance can reach systems, data, or secrets beyond the minimum runtime scope needed for the task.
How the Layers Fail Together
The two layers are coupled, but they fail differently. A weak interaction layer lets an agent make unsafe or excessive requests. A weak infrastructure layer lets a valid request have broader consequences than intended. In practice, attackers look for the path of least resistance, so they will often exploit whichever layer is easier to subvert and then use it to undermine the other.
That is why agent threat models usually need both policy and containment. A tool call may be authorised correctly and still become dangerous if the environment exposes reusable secrets, permissive network routes, or shared sessions. Likewise, a hardened runtime can still be abused if the agent is allowed to trigger high-impact actions without sufficient request-time checks. Layered agent security is most effective when request authority and execution scope are designed together.
Risk and Threat Considerations
The main risk is false separation: teams may tighten one layer and assume the other is covered, leaving a gap that attackers can exploit. An agent with overbroad request rights can misuse approved tools, while an agent with narrow request rights but broad runtime reach can cause disproportionate damage after one allowed action.
Failure mechanism: Excessive delegation, weak tool gating, flat network access, reusable secrets, or poor runtime isolation lets a single agent action expand into broader access or lateral movement.
Impact: The result can be data exposure, unauthorised system changes, secret theft, or a wider compromise than the original request seemed to permit.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent request authority and execution scope are central to this layer split. |
| ASI02 — Tool Misuse | The interaction layer governs which tools the agent may invoke and how. | |
| Recommendation — Enforce per-action authorization and limit delegated agent privilege. Constrain tool invocation to approved actions and arguments. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Both layers depend on limiting what the agent can request and reach. |
| IA-9 — Identification and Authentication (Service and Other Non-Organizational Users) | Agent-to-service and workload interactions depend on authenticating non-human actors. | |
| SC-7 — Boundary Protection | The infrastructure layer is defined by what the agent can reach after admission. | |
| Recommendation — Restrict agent permissions to the minimum access needed for the task. Authenticate non-human actors before allowing service-to-service access. Segment runtime paths so agent access stops at approved boundaries. | ||
Practitioner Guidance
What to prioritise: Define the interaction policy and the runtime containment model separately, then verify that each one still holds if the other fails. That usually means asking two different questions: “Was this action allowed?” and “How far could the agent have gone if it was allowed?”
What good looks like: The agent can only request narrowly scoped actions, and the environment only exposes the minimum network, secret, and workload reach needed for that request. If you cannot describe both boundaries in one sentence, the control design is probably incomplete.
Practitioner takeaway: Secure the request path to limit what the agent may do, and secure the runtime path to limit what the agent may reach; either control alone leaves a usable attack path.
Related resources from NHI Mgmt Group
- What is the difference between privilege reduction and secret rotation?
- What is the difference between a rules-based secret scanner and a hybrid scanner?
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between zero trust for users and zero trust for NHIs?