Use separate identities for the main agent, support agents, and any tooling that touches execution environments. Give each component only the permissions needed for its stage, then review their logs independently. Modular design reduces context overload, but it only improves security if the identity model is modular too.
Why This Matters for Security Teams
Modular agent architectures can improve resilience and maintainability, but they also expand the number of identities, tool paths, and decision points that need governance. The main risk is not just a compromised model response, but an authorised component doing the wrong thing with valid permissions. That is why agent design must be treated as an identity and control problem, not only a software architecture choice. Guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward explicit governance, traceability, and misuse resistance.
The practical challenge is that modularity often creates a false sense of safety. Teams may isolate prompts or split workflows, yet still reuse the same service principal, token scope, or execution channel across components. That collapses the trust boundary and makes lateral movement easier once one piece is abused. In practice, many security teams encounter agent risk only after an execution permission, shared secret, or delegated tool has already been exercised outside the intended stage.
How It Works in Practice
Risk reduction starts by assigning a distinct identity to each agent role and each sensitive tool boundary. The orchestrator, specialist agents, and environment-facing utilities should not share credentials unless there is a tightly justified control reason. Separate identities make it possible to enforce least privilege, rotate credentials independently, and trace actions back to a specific component. This is especially important when an agent can call external tools, retrieve data, or trigger code execution.
A workable control pattern usually includes:
- Unique service identities for orchestration, retrieval, execution, and reporting.
- Scoped permissions that align to one stage of the workflow, not the full agent chain.
- Short-lived credentials or tokens where possible, with explicit session boundaries.
- Independent logging and alerting for each agent identity and each tool invocation.
- Output validation before one agent’s result becomes another agent’s instruction.
Security teams should also classify the most dangerous transitions, such as model-to-tool, tool-to-cloud, and agent-to-agent handoffs. Those are the points where prompt injection, poisoned context, or malformed instructions can turn into real action. The MITRE ATLAS adversarial AI threat matrix is useful here because it helps teams think in terms of attack pathways rather than only control lists. For more operational threat modeling, the CSA MAESTRO agentic AI threat modeling framework is also relevant.
Teams should review whether each agent actually needs to execute actions, or whether some components can be reduced to read-only analysis or suggestion generation. The more an agent can alter state, the more its identity must be monitored like any other privileged workload. These controls tend to break down in highly dynamic environments where agents are created and retired automatically because identity lifecycle and logging drift faster than governance can keep up.
Common Variations and Edge Cases
Tighter segmentation often increases operational overhead, requiring organisations to balance containment against orchestration complexity. There is no universal standard for how many identities a modular agent stack should use, but current guidance suggests that each materially different trust boundary deserves its own control plane treatment. That usually means separate authentication, separate authorisation, and separate audit trails.
Some teams try to simplify by giving the orchestrator broad access and assuming downstream agents are “internal.” That approach can work in low-risk demos, but it is fragile in production because a compromised planning agent can inherit too much authority. The same issue appears when agents share a common secret vault path or when logs are merged so aggressively that incident responders cannot tell which component issued which action. The NIST Cybersecurity Framework 2.0 remains useful for mapping these issues to govern, protect, detect, and respond activities.
Where regulatory scrutiny is high, teams may also need to document model governance, change control, and human override points more formally. The current consensus is stronger on separation of duties than on a single ideal architecture, so the safest implementation is the one that preserves attribution and limits blast radius. In practice, modular agent systems fail most often when one “temporary” shared credential becomes the default way every component reaches production systems.
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, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI risk governance is central to modular agent identity and tool controls. | |
| OWASP Agentic AI Top 10 | Agentic AI risks include prompt injection, misuse, and unsafe tool execution. | |
| MITRE ATLAS | ATLAS maps adversarial AI attack paths across model, prompt, and tooling layers. | |
| CSA MAESTRO | MAESTRO focuses on threat modeling and trust boundaries for agentic systems. | |
| NIST CSF 2.0 | PR.AC | Least privilege and identity governance underpin modular agent containment. |
Apply AI RMF to assign owners, assess harms, and govern agent-to-tool trust boundaries.
