Giving AI Access to Your Business Changes the Security Problem

For the last few years, most security questions about AI have centred on what people paste into a chat window. That concern is real, but it describes AI as an isolated tool: a person gives it some text and decides what to do with the answer. The picture changes when AI becomes part of a business workflow. A system that reads incoming email, looks up customer records, calls other software and prepares communications is far more useful than a model summarising a document, and it has a very different risk surface.

The reason is that usefulness comes from access. The more of the business an AI system can see and influence, the more work it can take on, and the more carefully engineers have to think about what it can see, what it can change and what happens when an input or an output cannot be trusted. In that setting, security belongs in the design of the system from the start rather than being added once the AI works.

From isolated tool to connected system

A model summarising a document that a person has chosen to share has a narrow boundary. It sees one document, produces some text, and a person reads the result. Very little happens automatically, so very little can go wrong without someone noticing.

Connect the same model to a mailbox, a job management system and an accounts platform, and the boundary moves. The system now receives content from people outside the business, holds credentials for other software and may be able to create, change or send things before anyone has looked. That does not make AI unusually dangerous, but it does mean the system needs the same deliberate engineering as any other software that acts on behalf of the business, along with some care that is specific to how AI behaves.

Access should match the job

The most useful principle we apply is bounded capability: give the AI enough access and authority to do the work well, and no more. That sounds obvious, yet it is easy to lose sight of when connecting systems is quick and a broad permission is the simplest way to make a demonstration work.

In practice it means asking, for each connection, what the job actually requires. An assistant that drafts replies to customer email may need to read the inbox and create drafts, but it does not need to send on its own, delete messages or reach the payment system. A workflow that updates job records may need to change a small set of fields, not rewrite whole records or create new customers. Permissions are granted at that level wherever the connected software allows it, and the credentials that carry them are stored as secrets rather than pasted into workflows or tied to an engineer's personal account.

Where the system runs matters as well. Our standard is that a client's automation runs in infrastructure the client owns, with its credentials held there, so access can be reviewed, rotated or withdrawn by the business itself instead of depending on a supplier's account.

Data should move deliberately

Business workflows move information between systems, and every movement is a decision about exposure. It is worth knowing exactly what enters a workflow, which parts of it are passed to an AI model, where the results are stored and which other systems receive them.

Often the AI step does not need everything. A model classifying an enquiry needs the message but not the customer's full history; a model reading an engineer's notes needs the notes, not the billing details. Sending only what a step requires reduces what could be exposed if something goes wrong, and it usually makes the step easier to test and reason about. The same thinking applies to outputs, which should leave the workflow only through the routes it was designed to use.

Not every input can be trusted

Once an AI system reads content from outside the business, some of that content will be wrong, misleading or deliberately crafted. An email can contain instructions aimed at the AI rather than at the person who will eventually read it, asking it to ignore its task, reveal information or take an action. This is usually called prompt injection, and no model can be relied on to resist it every time.

The practical response is architectural. If the AI step that reads untrusted content cannot send email, change records or call sensitive systems by itself, a manipulated instruction has very little to work with. Treating outside content as data to be interpreted rather than as instructions to be followed, and limiting what the interpreting step can initiate, does far more than careful wording in a prompt.

Output has to earn its consequences

The same discipline applies in the other direction. A model's output is a proposal, however fluent it sounds, and before it is allowed to have consequences deterministic software can check it. A job number can be confirmed to exist, a quantity can be checked against the source text, a draft can be screened for a visit or a price nobody has agreed, and a field can be held to the kind of value it is meant to contain. When a check fails, the item goes to a person or to a defined fallback rather than through.

This is where the division of responsibilities behind all of our work becomes a security property as well as a reliability one. AI is used where intelligence is useful, code where certainty is possible and people where judgement matters. Code enforces the rules that can be stated precisely, so the AI never has to be trusted to enforce them itself.

Consequential actions need the right authority

Some actions deserve a person's decision however capable the AI has become: sending a commitment to a customer, approving a payment, changing something that is hard to undo. Human approval at those points is a control rather than a weakness, and it works best when the system has already done the preparation, so that the person is making a decision instead of redoing the work.

Not every workflow needs every control. A low-risk internal summary might need little more than sensible access and a clear record of what happened, while a system that communicates with customers or changes financial records needs validation, approval and careful failure handling. The controls are chosen for the consequences of the process, not applied as a checklist.

Knowing what happened

When something unexpected occurs, it should be possible to understand it afterwards. Where it is useful, that means recording which inputs arrived, what the AI produced, what the deterministic checks decided and what action, if any, followed. Traceability of this kind helps when something needs investigating, and it also builds the confidence that lets a business extend its automation over time, because people can see how the system behaves rather than having to take it on trust.

Failure paths belong in the same design. A model may be unavailable, return something malformed or produce an answer the checks reject, and a well-engineered workflow knows what to do in each case. Whether that means retrying, falling back to a simpler route, passing the item to a person or stopping, it never quietly treats a failure as a success.

Security as part of the architecture

None of this is meant to make AI sound like something to be contained at all costs. Connected AI is valuable precisely because it can work with real business information and real systems, and the businesses that benefit most will be the ones that let it. The engineering task is to make that possible on sensible terms, so that AI gets the access it needs to do the job without gaining unrestricted access to the business.

That is why we treat permissions, credentials, data movement, untrusted inputs, validation, approval and failure handling as part of designing the workflow, alongside the AI capability itself. Designed together, they let a business give AI a meaningful role in its operations while keeping control of the parts that matter.