What should organisations do when AI agents can change systems or move money?

Why This Matters for Security Teams

When an AI agent can change systems or move money, the risk is not just unauthorized access. The harder problem is that delegated authority can turn into open-ended authority once the agent starts chaining tools, retrying actions, or operating on stale assumptions. Static IAM and broad service roles were designed for predictable workloads, not goal-driven systems that can improvise.

That is why current guidance increasingly points toward runtime policy checks, context-aware approval gates, and short-lived credentials instead of standing privileges. NHI Management Group’s AI Agents: The New Attack Surface report shows how quickly agent behaviour can exceed intended scope, including unauthorized system access and credential exposure. The same pattern appears in agentic security guidance from the OWASP Agentic AI Top 10, which treats tool misuse and over-permissioning as core design flaws rather than edge cases.

For security teams, the practical issue is accountability. A change to production or a transfer of funds must be traceable to a current business context and an explicit owner, not merely to a role that was granted weeks earlier. In practice, many security teams encounter agent overreach only after a system change or payment error has already occurred, rather than through intentional design review.

How It Works in Practice

The safest pattern is to treat each sensitive agent action as a separate authorization event. The agent first proves its workload identity, then requests a narrowly scoped capability for one task, and then receives a decision based on current context. That context can include the target system, data sensitivity, transaction value, time of day, approval status, and whether the request matches the agent’s declared purpose. This is where policy-as-code becomes essential.

In mature environments, the control stack usually includes:

• Workload identity for the agent, rather than a shared human credential.
• Just-in-time, ephemeral credentials with automatic expiration after the task completes.
• Per-action policy evaluation using tools such as OPA or Cedar at request time.
• Break-glass controls for exceptional operations, with explicit logging and post-event review.
• Step-up approval for high-impact actions like financial transfers, privilege changes, or production configuration changes.

This model aligns with the NIST AI Risk Management Framework, which emphasizes governance, measurement, and continuous monitoring, and it is consistent with the CSA MAESTRO agentic AI threat modeling framework, which focuses on tool use, autonomy boundaries, and control points. NHI Management Group’s OWASP NHI Top 10 also reflects the same operational reality: the identity problem is not just who the agent is, but what it is allowed to do right now.

These controls tend to break down in highly distributed environments where agents can call many downstream services through multiple brokers, because the policy decision becomes fragmented across too many trust boundaries.

Common Variations and Edge Cases

Tighter approval gates often increase operational friction, requiring organisations to balance speed against control. That tradeoff is unavoidable for finance, infrastructure, and privileged administration, but the level of friction should match the impact of the action. Best practice is evolving, and there is no universal standard for when an agent should self-execute versus request human approval.

Low-risk actions may be safe under automated policy checks alone, while high-risk actions usually need explicit human confirmation or two-person approval. Some organisations also separate agents by duty: one agent may draft a change request, another may validate it, and a third may execute only after policy and approval both pass. That separation reduces the chance that a single compromised or misaligned agent can complete a full abuse chain.

Two common edge cases deserve special attention. First, money movement often involves external systems with delayed settlement, so a revoked credential does not always undo a completed transaction. Second, system changes may be technically reversible but operationally damaging if they trigger cascading failures, data loss, or downtime. For those cases, controls should not rely on the agent’s stated confidence; they should rely on bounded permissions, transaction limits, and evidence of current authorization. The LLMjacking: How Attackers Hijack AI Using Compromised NHIs research is a useful reminder that exposed credentials and overly broad access can be abused extremely quickly once they are discovered.

Related resources from NHI Mgmt Group

• 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?
• How can organisations prevent AI agents from becoming overprivileged?
• How can organisations govern AI agents that use service accounts and tokens?