Why do AI agents and automation tools break down in complex organisations?

Why This Matters for Security Teams

ai agents and automation tools fail in complex organisations because they are asked to act on behalf of a business that is constantly changing, but they are usually given static permissions, static assumptions, and static workflows. That mismatch is exactly what makes them brittle. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both points toward runtime risk, not just design-time policy, because the agent’s next move cannot be assumed from its last one.

In practice, this breaks down at the seams between teams, systems, and approvals. One tool may see an “authorized” task while another sees a policy violation, a stale ownership record, or a credential that should no longer be valid. NHIMG research on OWASP NHI Top 10 shows that agentic risk is not just about prompt attacks, but about the identities and secrets that let agents keep operating after context has shifted. In complex organisations, that mismatch becomes an operational failure before it becomes a security incident.

In practice, many security teams encounter agent failures only after a workflow has already crossed a trust boundary, rather than through intentional testing of changing ownership, privilege, and downstream impact.

How It Works in Practice

The core problem is that autonomous tools do not behave like stable human roles. They chain actions, call APIs, retry failed steps, and adapt to partial results. A role-based access model assumes the caller’s intent and access pattern are known in advance, but agents are goal-driven. They may need to read one system, transform data in another, and trigger a third, all within one task. That is why static IAM and long-lived credentials fail to describe what the agent is actually doing.

More resilient patterns are emerging. Best practice is evolving toward workload identity, JIT issuance, and context-aware authorisation. The identity primitive should be the workload itself, not a reusable human credential. In implementation terms, that often means cryptographic workload identity such as SPIFFE/SPIRE or short-lived OIDC tokens, combined with policy-as-code evaluated at request time. NIST’s AI governance guidance and CSA’s CSA MAESTRO agentic AI threat modeling framework both reinforce the need to bind authorisation to the current task, not the assumed persona.

• Issue secrets per task, not per environment, and revoke them automatically when the task ends.
• Prefer short TTLs and narrowly scoped tokens over reusable API keys and shared service accounts.
• Evaluate policy at runtime using the current action, data sensitivity, and downstream effect.
• Log the agent’s intent, tool chain, and decision path so operators can reconstruct why access was granted.

NHIMG’s coverage of the Analysis of Claude Code Security and the Replit AI Tool Database Deletion illustrates the same pattern: once an agent has execution authority, small reasoning errors can become cross-system side effects very quickly. These controls tend to break down when the organisation still treats the agent like a fixed application rather than a dynamic actor with changing context and tool paths.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance speed against observability and revocation discipline. That tradeoff is especially visible in multi-agent pipelines, where one agent hands off to another and each step may need separate trust decisions. There is no universal standard for this yet, but current guidance suggests designing for containment first, convenience second.

One common edge case is delegated access across business units. An agent may need temporary access to customer data, finance systems, and internal knowledge stores in a single workflow, but each system may have different ownership and approval logic. Another is tool sprawl: once agents can call external SaaS, browser tools, and internal APIs, static allowlists age quickly. NHIMG reporting on the Moltbook AI agent keys breach and CoPhish OAuth Token Theft via Copilot Studio shows why token lifetime, consent scope, and revocation speed matter more than broad “trusted agent” labels.

Finally, some environments still rely on human approval gates for high-risk steps. That can help, but it is not a full answer if the agent can continue chaining low-risk actions until the dangerous outcome is assembled. The best available practice is to combine runtime policy, ephemeral credentials, and explicit blast-radius limits, while recognising that highly distributed, fast-changing enterprises remain the hardest place to keep agents predictable.

Related resources from NHI Mgmt Group

• Why do user IAM and PAM break down for AI agents and service workloads?
• How should organisations disclose the use of AI tools and agents?
• How should organisations attribute AI spend when usage is spread across tools and agents?
• Why do scoped tokens break down for enterprise AI agents?