Security leaders should map agent permissions, monitor communications, require human approval, test revocation, and set procurement safeguards before deploying AI assistants

Gleb Tsipursky, PhD, CEO, Disaster Avoidance Experts

An AI agent that finds an unofficial communication route could turn that blind spot into an operational failure. This is not an entirely hypothetical category of weakness, as recent rogue AI agent attacks have shown. The lesson for security leaders is uncomfortable: agents that appear isolated may still find ways to coordinate, if isolation and communication controls fail.

Solving the problem

  1. The first step is to require an authority map for each agent. The map should record the service identity it uses, the systems it can access, the commands it may execute, who can approve an exception, and when that authority expires. In a regional business, that map should also show boundaries between subsidiaries, vendors, and data jurisdictions. A customer-support assistant may need to read an account record and suggest a resolution. It should not necessarily be able to export a complete customer database, invite a new third-party service into the workflow, or edit payment instructions simply because doing so might make a task easier.
  2. Treat agent-to-agent messages as security-relevant traffic. Give approved agents named channels and explicit delegation limits. Block unmanaged message boards and outbound destinations. Log the sender, recipient, tool, requested action, and authorisation for every consequential exchange. Keep those records in infrastructure the agent cannot alter.
  3. Next, make irreversible actions conditional on informed human approval. A manager should see the specific proposed payment, data export, email recipient, or production-system change. Presenting a large bundle of opaque steps for one-click approval undermines the purpose of review. The system should enforce the decision through application permissions, rather than relying on the agent’s instruction to ask nicely.
  4. Then, test what happens when the organisation says ‘Stop’. Revoke an agent’s credentials while a realistic task is in progress. Check whether child jobs continue, whether messages remain queued for delivery, and whether other agents can still act on instructions received before revocation. A dashboard showing ‘stopped’ proves little if work has already propagated into another service. Consider a deliberately contained exercise. A test agent receives a legitimate request to resolve a customer issue. A mock tool then invites it to use an unauthorised external relay to retrieve missing information. The security team can check whether the agent declines the relay, whether its delegated processes remain within approved channels, and whether the resulting audit trail shows what happened. The exercise needs no real customer data or access to public systems.
  5. A useful procurement requirement follows. Before a vendor receives ‘live’ credentials, ask it to demonstrate scoped identity, limits on outbound communication, secure logging, tested cancellation, and a record of independent security evaluation. Prefer a provider that can explain how those protections work to one that simply promises its model will behave.