What breaks when an AI agent can act across multiple business systems?

Why This Matters for Security Teams

When an AI agent can move across CRM, ERP, ticketing, procurement, and messaging systems, the risk is no longer just “bad input” or “prompt abuse.” The control failure shifts to how much the agent can do, how long it can do it, and whether each step is visible after the fact. That is why current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both treat autonomy, traceability, and accountability as first-class security problems.

NHI Management Group’s research on AI Agents: The New Attack Surface report shows how quickly these workflows become opaque: 80% of organisations say their AI agents have already acted beyond intended scope, while only 52% can track and audit the data those agents access. That gap matters because a cross-system agent can string together legitimate permissions into an unsafe business outcome without ever “breaking” a single control in isolation. In practice, many security teams only discover the problem after an agent has already chained actions across systems and left behind an incomplete audit trail.

How It Works in Practice

The practical breakage comes from assuming each business system can be governed independently. A helpdesk control may allow an agent to check eligibility in one system, create an order in another, and send a notification in a third. Individually, those actions look routine. Collectively, they create a composite workflow that may exceed the original business intent. Static RBAC cannot express that difference well because it was built around predefined human roles, not autonomous, goal-driven execution.

Better practice is evolving toward intent-based authorisation, just-in-time credentialing, and workload identity. The agent should prove what it is via cryptographic identity, then receive short-lived access only for the task at hand. Standards such as NIST AI Risk Management Framework, MITRE ATLAS adversarial AI threat matrix, and CSA MAESTRO agentic AI threat modeling framework all point toward runtime policy evaluation, not broad standing entitlements. In operational terms, that means:

• Use workload identity, such as OIDC-backed service identity or SPIFFE-style identity, for the agent itself.
• Issue short-lived secrets per task, then revoke them automatically when the task ends.
• Evaluate policy at request time, using context such as target system, data sensitivity, and step ordering.
• Log every action with enough detail to reconstruct the full cross-system chain later.

NHI Management Group’s OWASP NHI Top 10 discussion is especially relevant here because it frames the agent not as a user surrogate, but as a distinct identity with its own attack surface. These controls tend to break down when legacy integrations expose broad API privileges, because the agent can reuse one valid credential set to traverse multiple systems faster than reviewers can detect the chain.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance autonomy against reviewability. That tradeoff is real: if every cross-system step needs manual approval, the agent loses much of its value; if every step is pre-approved in a static role, the blast radius grows quickly. Current guidance suggests using different controls based on workflow criticality, but there is no universal standard for this yet.

High-risk environments usually need stricter segmentation than routine back-office automations. For example, a customer-service agent that updates a ticket and sends a status message may be acceptable with limited scope, while an agent that can change pricing, trigger refunds, and write to ERP needs task-scoped credentials and explicit step boundaries. The same logic applies when one agent can trigger another agent: multi-agent orchestration increases the chance of privilege stacking, hidden loops, and unclear ownership.

One important edge case is partial observability. The AI Agents: The New Attack Surface report notes that only 47% of compliance teams and 34% of executives have the same visibility into agent data access that IT teams receive, which makes post-incident review uneven. Another edge case is credential abuse: NHI-focused research such as the LLMjacking report shows why long-lived secrets are especially dangerous once an agent can call multiple systems. Where business systems lack granular audit events or cannot revoke delegated tokens cleanly, this guidance becomes harder to enforce because the agent’s full action chain cannot be reliably reconstructed.

Related resources from NHI Mgmt Group

• Why is identity such a critical factor in securing AI agent systems?
• How should enterprises govern AI agents across multiple clouds and SaaS platforms?
• How should organisations respond when an AI agent inherits access across multiple systems?
• What breaks when runtime detection is the main control for AI agent security?