A common mistake is treating the human user as the only identity that matters. Agentic workflows require separate control over who the user is, what the agent is allowed to do, and which tools or systems the agent may touch. Without that separation, permissions become too broad, visibility drops, and approval decisions lose their security value.
Where teams go wrong with multi-system agents
The first mistake is assuming a single human login can safely stand in for the whole workflow. Once an agent can read one system, decide in another, and write in a third, the security model has changed. The right question is not just who started the task, but what authority the agent carries at each step and how that authority is bounded.
That distinction matters because agentic work often crosses business systems with different trust levels, data sensitivity, and approval rules. If those boundaries are flattened, the agent inherits broad access by default and the organisation loses the ability to make a meaningful decision about each action. The result is not more automation, it is less precise control over delegated activity.
This is why agent identity has to be treated as more than a representation of the user. An agent may act on behalf of a person, but its permissions, token scope, and allowed tools should still be explicit and separable. A useful reference point is the AI Agent Identity Security Buyer's Guide, which helps teams evaluate the control surface before they buy or build.
Why cross-system authority needs a separate control model
In a multi-system workflow, the user, the agent, and the target systems are distinct security subjects. The user expresses intent, the agent executes, and each downstream system enforces its own rules. If teams collapse those layers, they usually end up granting the agent the same access as the human, even when the human would never need that level of standing privilege in every system.
That is where least privilege gets lost. The agent should usually hold task-scoped authority, not open-ended access, and the exact permission model should vary by action rather than by session alone. The moment a workflow can create records, move funds, change tickets, or trigger external actions, the approval model should be tied to the specific operation, not to the fact that the user is already authenticated. AI Agent Authorisation Guide is useful here because it frames per-action decisioning, delegated authority, and just-in-time access as separate design choices.
Good designs also distinguish between tool access and business authority. An agent may need to query a CRM, but not export bulk data; it may need to draft an invoice, but not post it; it may need to open a support case, but not approve one. That separation is what keeps the workflow useful without turning the agent into a universal proxy for the user across every connected system.
What security teams should verify before they trust the workflow
Teams should verify three things before they trust an agent across business systems: the agent’s identity, the scope of each credential or token it uses, and the exact systems or tools each action may reach. If any one of those is vague, the approval chain becomes advisory rather than controlling. The review should focus on whether the agent can be constrained differently for read, write, and invoke actions, and whether those differences are actually enforced.
- Check that the agent has a distinct identity and owner, not just a borrowed user session.
- Confirm that tokens or credentials are scoped to the smallest workable set of systems and operations.
- Require audit trails that show which principal approved the action, which tool executed it, and which target system was touched.
Teams also need to verify that the workflow still behaves safely when it spans more than one trust boundary. A single approval may be adequate for a low-impact lookup, but not for a chain that moves from internal records to customer-facing action to external side effects. That is why multi-hop delegation and containment matter, and why the Multi-Agent and A2A Security Guide is relevant even when the workflow is only “one agent”, because the real issue is delegated action across boundaries.
Risk and Threat Considerations
When agents span several business systems, the main risk is blast radius. A single overbroad credential, confused approval step, or weak tool boundary can turn one compromised workflow into access across records, transactions, and administrative functions. The same pattern also creates trust-abuse opportunities, where a malicious prompt, poisoned instruction, or hijacked action path pushes the agent into doing work the user never intended.
Failure mechanism: The organisation treats the human login as the control point, while the agent keeps broad delegated access and can reuse that authority across systems without a fresh, action-specific decision.
Impact: An attacker or bad workflow can chain access from one system into another, amplify a small compromise into material business damage, and make attribution and rollback much harder.
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 | Agents crossing systems can overstep delegated authority and reuse broad privilege. |
| ASI02 — Tool Misuse | The question centers on agents reaching the wrong tools or systems across a workflow. | |
| ASI09 — Human-Agent Trust Exploitation | Approval decisions can become weak when teams over-trust the human origin of an agent task. | |
| Recommendation — Apply ASI03 to separate user intent from agent authority and scope each action tightly. Apply ASI02 to restrict which tools an agent may invoke for each task step. Apply ASI09 to require action-specific checks before trusted workflows can proceed. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Multi-system agents need bounded access rather than user-wide broad permissions. |
| IA-5 — Authenticator Management | The answer depends on scoping and managing the credentials or tokens the agent uses. | |
| AU-2 — Event Logging | Agent actions across business systems need traceability to preserve accountability. | |
| Recommendation — Enforce AC-6 so each agent action gets the minimum privileges it needs. Manage agent credentials so scope, rotation, and revocation limit cross-system exposure. Log agent actions with enough detail to attribute each step across systems. | ||
Practitioner Guidance
What to prioritise: Start by mapping the actions that can create external effect, modify records, or cross trust boundaries. Those are the points where per-action authorisation and tighter scope matter most; read-only enrichment steps are usually lower risk than write or approval steps.
What to verify: Require evidence that the agent cannot reuse one approval to do unrelated work in another system. If the workflow depends on the user being “trusted enough” once at login, the control is probably too weak for production use.
Common mistake: Teams often secure the agent’s interface and ignore the downstream systems it can reach. The safer pattern is to treat the agent as a distinct actor with bounded authority, observable actions, and explicit retirement when the task is done.
Practitioner takeaway: The goal is not to remove automation, it is to make sure each delegated action has its own scope, visibility, and stopping point before the agent can move across business systems.
Related resources from NHI Mgmt Group
- What do teams get wrong when they let agents act across business apps without a shared identity boundary?
- What do teams get wrong when they try to search across multiple security tables in one investigation?
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams govern AI agents that can access enterprise systems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
