AI agents in the enterprise: how to limit their blast radius before it is too late

AI agents no longer just answer questions. They can read documentation, work with the CRM, change code, run processes, prepare invoices or act on corporate systems.

That capability brings speed, but it also introduces a new risk: what happens if an agent follows a malicious instruction, misuses a tool or operates with more permissions than it needs?

Research published over the past months has focused on threats such as indirect prompt injection, tool abuse, excessive permissions, memory poisoning and lateral movement between agents.

Many of the best-known cases are still lab demonstrations or responsibly disclosed vulnerabilities, not confirmed attacks against named companies. But they all point to the same conclusion:

The risk is not only that someone manipulates an agent's instructions. The real risk depends on what that agent can do next.

An AI agent is a new identity inside the company

An agent may have:

its own credentials;
access to corporate applications;
database connections;
tools that can execute actions;
persistent memory;
internet access;
the ability to talk to other agents.

From a security point of view, it should therefore be treated as a non-human identity.

It should not get general network access just because it is part of an internal process. Nor should it share credentials with people, servers or other agents.

The principle should be the same as in a Zero Trust architecture: do not trust by default and authorise only what it needs to do its job.

The problem does not end with prompt injection

A prompt injection can arrive hidden inside an email, a web page, a document, a support ticket or any other source the agent processes.

If the agent can only read one specific folder, the potential impact is limited. But if it can also read confidential information, change systems, run code and send data to any destination, the same manipulation can have far more serious consequences.

Protection cannot depend solely on detecting malicious instructions. You have to assume that at some point the agent will make a mistake or be manipulated, and prepare the environment so that the error stays contained.

Five controls before putting an agent into production

1. A dedicated identity for each agent

Every agent should have its own identity, with revocable credentials and a specific purpose.

That makes it possible to know which agent made each connection, revoke its access without affecting other services, and avoid shared credentials that cannot be audited.

When an agent is retired, its identity and permissions should be retired too.

2. Least privilege as the starting configuration

A support agent does not need access to the finance system. A development agent should not read HR data. A reporting agent does not need to modify the source database.

Permissions should follow the agent's real function, not everything it could conceivably do.

The safest model is to start with access denied and then explicitly authorise each required resource.

3. Segmentation and access only to the required resources

Connecting an agent to the whole corporate network needlessly widens its blast radius.

Microsegmentation keeps it limited to one application, one server or one environment. If the agent is manipulated or its credentials are compromised, that separation makes it harder for the incident to spread.

The agent should be able to reach the resource it needs, not "enter" the whole network.

4. Control over connections and destinations

You also need to define where the agent can communicate.

A process that only needs to call a corporate API should not be able to send information to any domain on the internet. Outbound connections, authorised destinations and exit points are part of the security model.

This matters especially when the agent handles personal data, commercial information or internal documentation.

5. Logging and the ability to contain

When an action is automated, traceability is essential.

The company should be able to answer questions such as:

Which agent started the connection?
When did it happen?
From which device or environment?
Which resource did it reach?
Which exit point did it use?
Can it be blocked or isolated quickly?

Logs do not prevent every incident, but they make it possible to investigate, scope and respond faster.

Where ConnectaSec fits

ConnectaSec can help limit the blast radius of agents at the network and access layer, applying the same Zero Trust principles used to protect people, devices and workloads.

That includes:

access denied by default;
per-resource access policies;
microsegmentation;
outbound connections without exposing ports to the internet;
a dedicated gateway per customer;
the ability to choose the traffic exit point;
connection logging and traceability;
the ability to contain access without opening the whole network.

ConnectaSec does not inspect prompts and does not replace the agent's internal security. It also does not replace secret management, application permissions, human approvals or the AI model's own controls.

Its role is complementary: reducing how far an agent can reach if it makes a mistake, receives a malicious instruction or has its identity compromised.

Five use cases

Support agent connected to the CRM

Needs: to read customer records and create or update tickets.

Should not be able to: reach billing, HR, infrastructure or backups.

Allowed destinations: CRM, support platform and strictly necessary services.

Audit: bulk queries, exports, data changes and connections outside normal hours.

Development agent

Needs: to read repositories, open issues and run controlled integration processes.

Should not be able to: reach production directly, download general secrets or change infrastructure outside its project.

Allowed destinations: repositories, development tooling and approved services.

Audit: code changes, executions, permission changes and attempts to reach other environments.

Finance agent

Needs: to read invoices, prepare reconciliations or generate reports.

Should not be able to: authorise payments, change bank accounts or export entire databases without approval.

Allowed destinations: ERP, document repository and authorised financial services.

Audit: access to sensitive data, exports, payee changes and actions that require human validation.

Operations or SRE agent

Needs: to read telemetry, review alerts and propose corrective actions.

Should not be able to: run destructive commands or deploy critical changes without explicit approval.

Allowed destinations: monitoring, operational repositories and scoped environments.

Audit: commands executed, privilege escalation, configuration changes and communication with external systems.

MSP running agents for several customers

Needs: to operate repetitive processes for each organisation.

Should not be able to: reuse one identity across customers or move data between environments.

Allowed destinations: the resources and gateways belonging to each customer.

Audit: separation between customers, identity used, policy changes and administrative actions.

Checklist before enabling an AI agent

Before going to production, check:

Does it have its own identity?
Can its credentials be revoked?
Does it only hold the permissions it needs?
Can it reach only the required resources?
Is it separated from the rest of the network?
Are its outbound connections controlled?
Do sensitive actions require human approval?
Is it logged who accessed what, and when?
Is there a procedure to block or contain it?
Are its memory and sources reviewed?
Have error and manipulation scenarios been tested?
Is someone accountable for its lifecycle?

The right question

The question is no longer only whether a company will use AI agents.

The question is:

When an agent makes a mistake or is manipulated, how far will it get?

A Zero Trust architecture does not remove every risk associated with AI. But it can turn broad, hard-to-control access into a set of limited, segmented and auditable connections.

If your company is deploying AI agents, ConnectaSec can help you review their segmentation, access and connections before they go to production.

Pricing starts at €5 per user per month, with up to 5 devices included, plus a dedicated gateway from €40 per month.