Your AI agent has keys. Can it read, write, delete, send or spend?

Once an AI agent can use company credentials, the production question is no longer only whether it gives a plausible answer. It is which personal data it can read, which records it can write or delete, which messages it can send, and whether it can spend without a human stopping it.

By Reynier Rivero·Software engineer·13 September 2026

At 08:42 on a Tuesday, the operations manager at a Leeds-based commercial maintenance firm typed one sentence:

“Clear the overdue follow-ups, find the next engineer slot and let each customer know.”

The agent was connected to the shared inbox, job-management system, calendar and payment provider. It could read customer records, write notes, delete duplicate tickets, send emails and create refunds within a configured limit.

In the demo, each permission had looked small.

Composite hypothetical scenario: This is a constructed UK business example, not a reported incident.

At 08:49, the first job was updated. The agent found the right appointment, copied a phone number into the CRM and drafted a message. It also opened a PDF from an older email thread, selected the wrong customer record and sent an attachment externally.

The message went out. The refund did not, because the payment provider requested another approval.

The team had tested whether the agent answered accurately. They had not tested what it was authorised to do when accuracy failed.

The first question is not which model

On 8 January 2026, the ICO published its Tech Futures report on agentic AI. It describes systems that combine generative AI with tools and new ways of interacting with the world, including research, coding, planning and transactions. It also makes the responsibility clear: organisations remain responsible for the data protection compliance of agentic AI they develop, deploy or integrate. (ICO report)

That changes the design conversation.

An agent is not just a model producing text. It is a model operating through identities, tools and systems. The useful question is not simply whether it can reason; it is what its credentials allow it to do.

If your agent touches a CRM, inbox or support desk, the integration boundary deserves the same attention as the model. The practical difference is explained in our guide to connecting AI to your CRM, WhatsApp and the rest of your business.

Map the five actions before granting the key

“Finance access” is not a useful production permission. Reading an invoice, changing an invoice, deleting a record, sending a message and releasing money have different consequences.

A workable map looks like this:

This is not a universal configuration. A low-risk internal assistant may need more autonomy than a customer-facing agent handling financial information.

The point is to make each permission deliberate.

Production risk is more than a wrong answer

Purpose sets the data boundary

The ICO identifies broad purposes and unnecessary access as specific risks in agentic AI. Its guidance says organisations should not give an agent access to information merely because it might be useful later; access should have a justifiable reason connected to the purpose. (ICO on purpose limitation and data minimisation)

For a UK business, that means defining the task before choosing the data path:

• Which customer or tenant does the agent need?
• Which fields are necessary?
• Which information can be masked or redacted?
• Which systems are completely unrelated?
• How long does the access need to last?

The same map should identify who acts as controller or processor for each processing operation, including the suppliers in the agentic AI chain. The ICO lists those responsibilities as a specific agentic-AI risk.

Autonomy sets the approval boundary

In its interim advice published on 20 August 2026, the NCSC recommends proportionate controls based on the agent’s autonomy and the consequences of failure. It distinguishes human-in-the-loop approval, human-on-the-loop monitoring and fully autonomous operation. (NCSC guidance)

For most businesses, the five-action map gives a useful starting point:

• Read can often be automated when the data scope is narrow.
• Write should be limited to specific fields and reversible changes.
• Delete should usually be proposed, not executed.
• Send should require approval when it is external, sensitive or high-volume.
• Spend should use a separate approval path, amount limit or both.

An approval request should show the exact action, recipient, record and amount. “The AI wants to continue” is not an approval control.

Credentials set the blast radius

The NCSC recommends giving agents their own identity, limiting credentials to the permissions needed for the task and using credentials with the shortest possible lifetime. It also describes proxies that inject credentials into approved requests without exposing the credentials directly to the agent.

That matters because an agent should not be able to discover a secret and decide where else to use it.

A system prompt can explain the rules. It cannot replace a tool layer that enforces them.

The strongest design usually separates the model from the credentials. The model requests create_refund; a controlled service checks the customer, amount, approval and account before using a short-lived credential.

Monitoring sets the detection boundary

The NCSC says agent activity should be observable in near real time and afterwards, with telemetry from both the agent and its wider sandbox. Logs should be protected from modification or deletion and, where possible, made immutable.

A transcript alone is not enough.

You need to know which identity accessed which record, which tool was called, what approval existed, what the external system returned and whether the intended final state was actually reached.

That is the difference between “the agent said it succeeded” and “the refund was confirmed by the payment system”.

Stopping sets the recovery boundary

The NCSC also recommends an emergency shutdown capability. Stopping the agent’s process may not be sufficient; the wider controls should be able to restrict network access and interrupt communication with model infrastructure when necessary.

For agents with meaningful external actions, having an owner, an alert path and a tested stop mechanism is a sensible recommendation.

If nobody knows who can revoke the credential at 18:30 on a Friday, the stop button is theoretical.

DPIA is a risk assessment, not a universal launch approval

The ICO’s AI guidance says not every use of AI involves processing likely to result in high risk. Whether a DPIA is required must be assessed case by case, and an organisation should document how it reached that conclusion where it assesses that the processing is not high risk. (ICO accountability and DPIA guidance)

The guidance supports a proportionate, risk-based approach. It also describes a DPIA as a way to understand the nature, scope, context and purposes of processing, and to record the safeguards chosen.

So the right question is not “Do all AI agents need the same approval?”

It is:

“What risks does this particular agent create for people, what data and actions create those risks, and how will we reduce and monitor them?”

The ICO’s AI guidance is guidance rather than a statutory code, and it distinguishes legal requirements from good-practice recommendations. (ICO guidance status and approach)

What to check before adding another integration

Run the map

Before production, write down every tool the agent can call and assign it one of five verbs:

• read;
• write;
• delete;
• send;
• spend.

For each verb, record the data required, the credential used, the approval rule, the owner, the expiry time and the recovery action.

If those answers are spread across five consoles, the architecture is already telling you something.

Test the failure path

Do not test only successful prompts. Test:

• the wrong customer with the right surname;
• an attachment containing hostile instructions;
• a missing approval;
• a duplicate request;
• a payment above the limit;
• a revoked credential;
• a service outage;
• a request to delete information that must be retained.

The goal is not to prove that the agent never fails. It is to prove that a failure cannot quietly become an unauthorised action.

Build the control layer around the workflow

Some businesses need a tightly scoped AI agent and chatbot implementation. Others need an automation and integration layer that separates data access from action execution.

The implementation choice depends on the workflow, systems and risk tolerance. It should not be decided by which model produced the most impressive demo.

Your agent has keys now.

The important question is whether each key opens one necessary door—or the whole building.

If you cannot explain exactly what the agent can read, write, delete, send or spend, and where a human must intervene, the next integration should probably wait. Prontavel helps teams design and build that control layer around real business systems.

The service this article is about: AI agents and chatbots that actually know your organisation