Neither regulator asked whether the model was any good, and that is the detail most coverage missed.
The UK's data protection regulator went first. On 8 October the ICO opened a six-week call for evidence on agentic AI, a 37-page document that sets out how it reads existing law for software that plans, uses tools and acts with little human oversight. Eleven days later the FCA published examples of good and poor AI practice for financial firms, with a long section on governance and accountability. The two documents come from different regulators with different remits, and both circle the same question. Which agent acted, who owned it, what authority did it hold, and what data did it touch?
Neither document creates a new law. The ICO is collecting evidence that will shape guidance and a statutory code, and the FCA says its examples are illustrative and create no new requirements. That does not make them harmless. Regulators publish their examples before they publish their findings, and organizations that read the examples as trivia tend to meet them again as findings.
At Bonfy we read both documents line by line, and the pattern is hard to miss. Every expectation about security, transparency, accountability and oversight comes back to one capability, the ability to reconstruct an agent action after it happened. This post walks through what each regulator asked for, where ordinary logging falls short, and what to do before the ICO's window closes on 20 November.
The ICO's call for evidence is organized around six themes, and each follows the same pattern. The regulator describes the challenge, sets out what it currently expects, and asks for evidence on how organizations cope. The themes are data security, transparency, accountability, automated decision-making, fairness and purpose limitation, and lawful processing. Responses close at the end of 20 November 2026, and the ICO has said it may not consider anything that arrives later.
Status matters here, and the ICO is plain about it. The document binds nobody. What it does is show the positions the regulator is likely to carry into its guidance and into a forthcoming statutory code of practice on AI and automated decision-making. A statutory code is something a regulator weighs when it enforces. So the call for evidence is better read as a preview of the questions an investigator will ask than as a consultation exercise.
The tone was set by the ICO's Director of Technology Regulation, who said that "the fact AI agents act with autonomy is not an excuse for poor compliance." That sentence does most of the work. Autonomy is a design choice, and the organization that made the choice owns the consequences.
The same day, the ICO confirmed it had made enquiries with OpenAI, Anthropic, Meta and the UK AI Security Institute about recent testing and deployment of agents. The enquiries followed reports that some agents had bypassed protections, used unauthorized communication channels and reached external systems. Scrutiny of agents is no longer confined to how models are trained. It now covers what a running agent did with data it could reach.
Read the six themes in order and they look like a standard data protection checklist. Read them again, watching for repeated nouns, and a different structure shows up. The Freshfields analysis puts it well. Across all six themes the ICO keeps returning to an organization's ability to identify the actions of a particular agent, the authority it operated under, and the data it used.
Add a fourth item from the automated decision-making theme and the list is complete. The ICO wants organizations to be able to say whether any human involvement in a decision was meaningful. Together those four facts are the spine of the document. Which agent. Under what authority. On what data. With what human involvement.
Start with identity. The ICO says organizations need a clear way to identify when an agent is operating, because without it they cannot decide which guardrails apply. It suggests deployers may need to register each agent to an owner, with a defined purpose and a defined set of permissions. According to PPC Land's breakdown, the document also floats the idea that an agent identity should carry more than a traditional software identity, including the tools the agent can use, its approval thresholds, its deployment context and the delegated authority it holds for the current task.
Authority comes next. The ICO expects the level of autonomy given to an agent to be a deliberate design decision, supported by guardrails, permissions and approval thresholds that match the risk of what the agent can do with personal data. Least privilege, limits on tool use and human approval for high-risk actions are the controls it names. None of those controls is exotic. The harder part is proving which settings applied to a specific agent on a specific day, and the ICO signals interest in exactly that by asking whether guardrails and permissions change dynamically.
Then there is the record itself. Among the evidence the ICO asks for is structured logging that captures agent identity alongside actions such as retrieving data or modifying a database, with outcome tracking and tamper-evident records. It also asks about session isolation, meaning controls that keep data from one session away from other users, agents or sessions. A log that shows a service account made an API call does not meet that description.
The ICO is not working alone. In March the CMA, FCA, ICO and Ofcom published a joint foresight paper on agentic AI, and four UK regulators agreed that existing rules on transparency, fairness and consumer protection already apply. The October documents are what that agreement looks like when each regulator applies it to its own territory.
The accountability theme contains the passage that should worry platform teams most. The ICO has heard from some agentic AI developers that they are controllers only for initial development, maintenance and security, and that organizations further along the chain are controllers for everything downstream. The regulator does not accept that as a default. It asks organizations to interpret the concept of a controller broadly, and it says they should not rely only on how they describe themselves.
Then it makes a technical observation. In generative AI, the types and sources of training data shaped a deployment. In agentic AI, the ICO says decisions about protocols, permissions and access controls may more heavily influence the means of processing. A reasonable reading is that the team approving which tools and MCP servers an agent can reach is making a decision that may carry controller responsibility.
Picture how that decision gets made. An engineer connects an agent to a document store so it can draft customer replies. The connector inherits whatever the engineer's service account can read. Nobody wrote a purpose statement, nobody was named as owner, and nobody believed they were making a regulatory decision. Yet the permission set, and not any policy document, now defines what the agent can process. This is why naming an AI owner on an org chart does not create control. The owner must be able to see and change what the agent can actually reach.
Purpose limitation sharpens the problem. The ICO states that an agent's ability to spot a new use for personal information does not make that use compatible with the original purpose. Agents that carry memory from one task to the next can cross that line without anyone deciding to. A permission says the agent may read a record. It says nothing about whether this task is a use the record was collected for, which is why permissions and AI use must be governed as separate questions.
UK GDPR security duties continue to apply to agents in full. Teams that already worked through GDPR Article 32 for agents will recognize the themes of scoped credentials and agent identity in the ICO's language, and the overlap is a useful head start.
The FCA's good and poor practice publication reaches the same destination from a different direction. It applies to regulated firms that develop, deploy, procure or use AI, and it leans on existing rules, including the Senior Managers and Certification Regime. The FCA is explicit that the examples are illustrative, non-exhaustive and create no new requirements.
Its governance chapter reads like an audit checklist. Good practice includes informed, documented and auditable oversight by senior managers, with records of decisions that show the rationale, the challenge and the escalation. The matching area for improvement is blunt. Some firms kept poor documentation of AI decisions, with limited audit trails, which meant senior managers could not show the steps they had taken to assess and mitigate risk.
That last clause deserves a second look. The failure the FCA describes is not a failed control. It is a control nobody can prove existed. A senior manager who took reasonable steps but cannot show them is in a weak position the day a regulator asks.
For agents specifically, the FCA describes firms that registered their agents in a central inventory, so they could see which agents were live, who owned them, what systems and data they could access, and what controls applied. It also describes firms that designed governance layers, with escalation routes and compliance controls, before deploying more autonomous systems. The poor-practice mirror image is retrospective governance, where a firm deploys first and then tries to fit the use case into an existing framework. One case study describes several teams each assuming that oversight sat somewhere else when risks emerged.
In a 19 October Rusu speech, the FCA's chief data, information and intelligence officer said the regulator will work with industry, other regulators and frontier labs on a trusted framework for agentic finance, covering agent identity, delegated authority, accountability and execution. She said agentic systems require continuous, conditional assurance, because a system that is safe at deployment may behave differently at scale or as the models beneath it change. She also said firms need senior managers personally accountable for AI systems, and that the regulators' joint survey with the Bank of England shows 86 percent of firms now use AI. These are not edge cases.
The publication also flags overreliance on untested vendor assurances. Firms remain accountable for outsourced AI services, and a supplier's statement that its agent is safe is not evidence. Teams doing third-party risk management for AI suppliers should treat the supplier's logs and their own logs as two separate sources of evidence.
Many organizations answer agent risk with a human in the loop and consider the question closed. Both regulators are skeptical, and for the same reason. The FCA lists excessive reliance on human-in-the-loop controls as an area for improvement, noting that review can mask weaknesses in a model while leaving gaps in accountability and escalation. It also warns that review can become a box-ticking exercise.
One case study makes the failure concrete. A firm created a human reviewer role, but the role was unclear and became a tick-box exercise over time. Reviewers increasingly accepted AI recommendations without scrutiny, even where there were signs of error, and unclear escalation criteria meant some low-confidence outputs went ahead anyway. On paper the control existed. In practice it was a signature.
The ICO draws the same line from the data protection side. Its automated decision-making theme says human involvement at one point in a chain of machine decisions does not necessarily make the whole workflow meaningfully human. Reviewers need to look at the decision where it has real impact, be able to influence it, have the authority to change the outcome, understand the system's logic and limits, and weigh the factors the system used. Organizations must assess this across the complete workflow, not one agent or decision point at a time.
Call it the assumed control problem. Organizations assume the human check works because a human exists. Regulators now want proof that it ran. One small firm described in the FCA publication recorded whether staff needed to review an output, whether the review happened, and whether the reviewer approved, overrode or escalated. That created an audit trail showing how oversight operated in practice instead of relying on an assumption.
This is where human oversight compliance stops being a staffing question and becomes a records question. A reviewer's decision is evidence only if the system captured what the reviewer saw, what the agent proposed and what happened next.
Most organizations will reach for their existing logs when a regulator asks for reconstruction. Those logs were built for a different actor. An application log shows that a service account called an API. An identity log shows a token was issued. A data store log shows a file was read. None of them says which agent was running, what task it was performing, whose delegated authority it held, or why it asked for that file.
The identity problem is often worse than missing detail. When agents borrow a human's credentials or share a static service account, the record points to a person or a generic account and never to the agent. The Kiteworks analysis of shared human logins covers how that pattern hides agent activity, and it is why the ICO's request for agent identity alongside every logged action is harder than it sounds.
Prompt-level controls do not rescue the situation. A system prompt that tells an agent not to share salary data is an instruction, and the agent may or may not follow it. It also writes no record when it works or when it fails. Access decisions that matter belong at the point of data layer access control, where a decision can be enforced and logged regardless of what the model decides to do.
There is a deeper gap. Identity tells you who is acting. Data classification tells you what is being touched. Neither tells you why, and purpose is the thing the ICO's purpose limitation and lawful basis themes turn on. Bonfy has written about this gap between identity and intent, and the regulator documents now make it a compliance issue instead of a design preference.
The ICO's reference to tamper-evident records is easy to skim past. A record that an agent or its operator could edit after the fact is not evidence of anything. Logs must be written by something outside the agent's control, at the moment of action, in a form that can be shown to an outsider.
If the four facts are the spine of what regulators want, the design question is where those facts get captured. Reconstructing them afterward, from application logs, identity logs and chat transcripts, is slow and incomplete. Capturing them at the moment the agent acts is cheaper, and it produces a record that was never reconstructed in the first place.
That is the idea behind Contextual Data Enforcement. Instead of trusting that permissions are enough, the enforcement point sits between the agent and enterprise data and evaluates what the agent is about to retrieve or send against the entities, relationships and context involved. A customer record requested for a support reply and the same record requested for a marketing experiment are different events, even when one permission covers both.
Entity awareness matters because most agent harm is about relationships, not file types. Whether a document may be used in a given task often depends on who the customer is, which regulation attaches to that customer, and what the agent was asked to do. That is the argument behind relationship-aware governance, and it is also the context a regulator will ask about when it asks for purpose.
Each enforcement decision then becomes a record in its own right. It states which agent acted, what it asked for, which entities were involved, what policy applied and what the outcome was. Multiply that across every retrieval and every output and you have what the ICO and FCA are asking for, a trace that links agent, authority, data and decision. Continuous control is the right phrase for it, because the evidence accrues as a by-product of enforcement instead of arriving as a quarterly exercise.
Agents reach enterprise data through MCP servers and similar connectors, which is where the ICO says protocols and permissions can shape the means of processing. Placing enforcement at agentic data security chokepoints gives teams one place to apply policy and one place to read the record, rather than one per connector.
Every new connector also moves the edge of what the organization must account for. That is the trust boundary problem in plain terms, and drawing the boundary on paper starts with mapping every data source, tool and recipient in each agentic workflow.
Five actions will put most organizations in a defensible position, and none of them requires waiting for final guidance.
Build the inventory. List every agent in production and every pilot, with a named owner, a stated purpose and the permissions it holds. The FCA describes this as central registration. If the list takes more than a week to assemble, you have learned something important about your visibility.
Run a reconstruction drill. Pick one agent action from last week and try to answer the four questions. Which agent, under what authority, on what data, with what human involvement. Time how long it takes and note where the trail went cold. The cold spots are your roadmap, and they are the same ones an investigator would find.
Revisit the controller analysis. Whoever approves tools, protocols and access permissions for an agent is shaping the means of processing. Write down who that is for each agent, whether the approval was deliberate, and whether your controller and processor assumptions survive the ICO's broad reading. A data protection impact assessment is a natural place to record the answer.
Test human oversight for substance. For every agent with a human check, record whether the reviewer has the authority to change the outcome, the information to judge it and a path to escalate. Then check whether the system records what the reviewer actually did. If it does not, you have an assumed control.
Decide whether to respond. The ICO is asking developers, deployers and other experts what works and what is hard. Organizations that have already built agent registers, scoped permissions or logging at the data layer hold exactly the evidence it is asking for. The window closes at the end of 20 November, and late submissions may be ignored.
For financial firms, add one more step. Map each material agent to a named senior manager with documented risk appetite, thresholds and escalation routes before it goes live, which the FCA cites as good practice.
Start with the drill. It costs an afternoon and tells you more than any policy review.
No. The call for evidence is a consultation exercise, and the ICO frames its expectations as its current reading of existing data protection law. It will inform future guidance and a statutory code of practice on AI and automated decision-making, and a statutory code is something a regulator takes into account when it enforces. Organizations should treat the document as an early view of how compliance will be tested. Waiting for the final code to start building records means building them under time pressure.
The ICO call for evidence concerns the processing of personal data by agentic systems under UK data protection law, so it matters to any organization whose agents handle UK personal data. The FCA publication applies to regulated firms that develop, deploy, procure or use AI in connection with regulated activities, consumer-facing use, operations or governance. Many financial firms fall under both. Organizations outside the UK with UK customers or employees should check whether their agents touch UK personal data, and Legal and the data protection officer should confirm how each document applies before anyone assumes it does not.
The ICO, drawing on its draft guidance on automated decision-making and profiling, lists five conditions. The person shaping the decision should review it at a point where it has real impact, be able to influence the outcome, hold the discretion and authority to change it, have the training to understand the system's logic, outputs, limits and risks, and take into account the data and factors the system used. Organizations must assess the complete workflow rather than each agent or decision point alone. An appeal route after a solely automated decision does not turn that decision into a human one.
Neither regulator publishes a template, so this is a reasonable synthesis rather than a requirement. At minimum the record should identify the agent and its owner, the purpose and delegated authority for the task, the permissions and approval thresholds in force, the data retrieved or changed, any human intervention and its outcome, and the result. The ICO asks about tamper-evident records and session isolation, so the record should be written outside the agent's control. Capturing it at execution time is more dependable than reconstructing it later from several systems.
The ICO invites developers, deployers and other experts to respond through its Citizen Space portal until the end of 20 November 2026. Responding is an invitation, not an obligation. Organizations that run agents on UK personal data, or that have worked out practical controls for agent identity, permissions or logging, are well placed to contribute. Legal and privacy teams should make the call together, because a response informs the regulator's thinking on guidance and the statutory code.
To learn more about contextual data enforcement, schedule a custom demo.