How Many External Systems Should One AI Be Allowed to Control?

After AI Enters the Workflow · Season Three: “When AI Starts Acting for the Organisation” · Article Seven

At first, a company’s AI can read email and draft replies. For efficiency, it later gains calendar access to arrange meetings. It connects to the customer system to update contacts, the document repository to share material, the procurement platform to create orders and finally a payment service to issue low-value refunds.

Each permission appears small and has a reasonable business purpose. Concentrated in one agent, however, the result is not five independent conveniences but a complete action chain. The system can read a request from outside, locate customer information, create a document, communicate under the company’s identity, alter a transaction and cause money to move.

At that point, asking how many systems the AI connects to is still insufficient. Risk depends on what the combination permits it to complete and how many formerly separate boundaries one error can cross.

Permissions multiply rather than merely add

An AI that reads email may disclose information but cannot alter a customer account. An automation that writes to a customer system may corrupt a field but cannot decide what to write. Connected together, malicious content in an external email can influence a model and be carried into the formal internal record. Add a sending tool and the false record can be communicated as fact. Add payment and error becomes financial action.

The chain can be written as:

Read untrusted input
× access internal knowledge
× modify authoritative records
× send under institutional identity
× invoke irreversible tools
= compound agency risk

The multiplication sign matters. Reviewing each connection as “not very risky” misses the combination. Excessive agency appears when one system can independently complete a loop from observation and judgement through execution and concealment.

Count the worst achievable action, not the number of integrations

Two connections may be more dangerous than ten. Reading and signing contracts can be more consequential than reading ten public databases. For every tool, the organisation should record four attributes:

The next step is to evaluate combinations. “Read every customer plus mass email” can create a large communication failure. “Read invoices plus create payment” can enable fraud. “Read internal policy plus publish externally” can convert a draft into institutional position.

The useful limit is not “five tools maximum”. It is that no single agent should complete a category of consequential loop without an independent approval or control.

Give AI a permission budget

A permission budget is not one score. It is a set of resources that cannot all be overspent.

The data budget limits visibility. For one customer request, expose only that customer and necessary task data rather than the database.

The action budget limits calls, value, recipients and modified objects. Low-value refunds can have a daily aggregate cap. Sending can begin with one recipient. A bulk update requires new approval.

The time budget makes permission expire. Tokens and temporary access should end when the task finishes, the session closes or an anomaly occurs.

The irreversibility budget restricts actions difficult to undo. Public publication, deletion, signature, payment and permission grant should not share the confirmation level of a query.

The trust budget limits the distance that external input can travel into internal action. Text from an email, webpage, attachment or third-party service should not become a high-privilege call directly.

Budgets allocate ability to a use case rather than copying the complete account of a powerful employee into AI.

Re-authorise at each tool call

Many agent systems receive a broad token at the beginning of a task and then invoke tools repeatedly. This is convenient, but expands an initially vague consent into actions no one could fully anticipate.

A safer architecture separates model proposal, policy enforcement and tool execution. The policy layer should ask more than whether this AI may use a refund tool. It checks customer, value, reason, aggregate limit, completeness and whether a person must approve.

The OWASP Top 10 for Large Language Model Applications includes excessive agency, prompt injection, sensitive information disclosure and insecure output handling. OWASP, “Top 10 for Large Language Model Applications” Together they show why natural-language suggestions cannot be treated as direct tool parameters and external content cannot expand system permission.

The UK National Cyber Security Centre’s secure AI development guidance recommends tracking, authenticating and version-controlling AI assets, using secure defaults and considering least privilege. NCSC, “Secure development” For agents, least privilege needs to operate at each action, not remain a principle written during procurement.

Break consequential chains apart

Traditional internal control uses separation of duties. The person who creates a supplier does not alone approve payment; the person proposing a refund does not also alter the audit record. AI should not recombine those functions merely because it can work across systems.

Separation can occur in three ways:

1. Proposal and execution: AI prepares an action, while an independent service validates and executes it.
2. Role separation: one agent reads and analyses; a more limited component executes without sharing all context.
3. Human approval: a person independent of generation confirms the consequential act.

Adding more agents is not automatically separation. If they share credentials, memory and policy vulnerabilities, they are interfaces to one privileged system. Real separation requires distinct permissions, logs and a control point able to reject upstream requests.

Bulk action needs a higher threshold

AI can copy one reasonable action into a large incident. One email, update or refund is not proportionate to the same action across ten thousand customers.

Controls should rise with scale: preview a sample, run a small batch, observe anomalies and then expand. Any transition from individual to list, internal to public or reversible to irreversible should require new authority.

Technical rate limits are insufficient. Calls per minute do not replace daily total value, unique customers, failure rate and unusual destination. An agent can remain within a technical rate and produce major loss steadily over several hours.

Logs must show how permission was used

“AI called the CRM” is not enough. A useful record includes task source, acting identity, tool and action, object scope, material parameters, policy check, approval, result and later reversal.

The record should connect the natural-language request to the actual API action, but it does not need purported model chain-of-thought. The auditable sequence is observable input, proposed action, authority rule, executed action and consequence.

The NIST AI Risk Management Framework puts governance, assigned roles, monitoring and incident response across the AI lifecycle. NIST AI Resource Center, “AI RMF Core” For multi-tool agents, monitoring should detect combinations: a bulk export followed by mass email at night, a bank-detail change followed by payment, or deletion of logs after privilege escalation.

The stop control must be more independent than the agent

An emergency stop is unreliable if the agent being stopped must execute it. The organisation needs a separate control plane that can revoke tokens, block tools, pause outward communication and terminate a task without destroying evidence.

Stopping should also be granular. Cut payment and public publication while retaining read-only diagnosis. Pause one customer or workflow without disabling the service. When a supplier model behaves unexpectedly, move to people or a known safe version.

The NCSC secure operation and maintenance guidance emphasises behavioural monitoring, update management, logging and incident planning. NCSC, “Secure operation and maintenance” The more an agent can act across systems, the more stopping, recovery and investigation need to be designed before release.

New permission is a new deployment decision

Teams can add integrations casually: “It already writes email, so let it arrange the meeting too.” Each tool changes the security boundary, privacy scope and outward consequence.

New permission should trigger risk analysis, testing, responsibility confirmation and rollback planning. Old tests may no longer be adequate. A wrong suggestion tolerable in an internal draft becomes unacceptable after automatic execution. Prompt injection confined to writing can become a data incident after customer-system access.

Permissions should also be removed. When a pilot ends, a process changes or a supplier is replaced, unused integrations and tokens should be withdrawn. Agency grows out of control when permission only accumulates.

Conclusion: one AI may connect to many systems, but should not complete every critical step alone

There is no universally safe number of integrations. The question is whether their combination forms a high-consequence loop without independent control.

The final principle is:

AI may use multiple tools necessary for a task, but every permission should be limited by data scope, action, reversibility and blast radius. Reading untrusted input, modifying authoritative records and performing irreversible action should not be concentrated in one agent without independent policy enforcement or human approval.

A good agent is not the one holding the most keys. It can complete a defined task, request another key at a boundary and return its access when work ends. Organisations need an action architecture that does not reunify every internal control in the name of efficiency—not an omnipotent digital employee.

Primary sources and further reading

• OWASP: Top 10 for Large Language Model Applications
• UK National Cyber Security Centre: Secure development
• NIST AI Resource Center: AI RMF Core
• UK National Cyber Security Centre: Secure operation and maintenance

Continue reading: Explore the After AI Enters the Workflow series.