In early September 2026, Reuters reported that Germany's digital affairs ministry does not consider halting AI development a viable option for Europe. The same statement contained a sentence boards should read twice: if AI systems could leave their test environment and access other computer systems without human intervention, that would be "an entirely new threat scenario." The ministry called for international coordination, including the United States and China, and said the issue would be raised at G7 level.
It is easy to file this under geopolitics. It is more useful to read it as a change in the unit of risk. For two years, AI governance has focused on the model: is it accurate, biased, explainable, safe to prompt. A government worrying about systems that access other systems is worrying about something else entirely. It is worrying about reach. And reach, inside an enterprise, is a supply-chain problem. The provocative version of the point is this: the risk of an AI agent is not only what it says. It is what you have allowed it to do.
Crest.Digital's Agentic Risk & Continuous Assurance practice maps and controls the full chain behind each AI agent, so its reach is something the audit committee can see and internal audit can test.
Explore Agentic GRCWhat Germany's Statement Signals for Boards
Two messages sit side by side in the German position. The first is that stopping is not an option: enterprises will keep deploying agents because the productivity case is real and competitors are doing the same. The second is that autonomy across system boundaries changes the risk category. Together they describe the position most boards are actually in: committed to deploying, and unsure how far the deployed systems can travel.
This reading is consistent with other recent signals. Microsoft's draft code of conduct, which we examined in our piece on human-in-control AI, requires shutdown and override. Chinese policy discussion, covered in our analysis of ten controls internal audit can test, emphasises discovery, intervention and recovery. Those pieces asked what an auditor should test. This one asks the board-level question underneath: what, precisely, is our exposure, and does it run through parties we do not control?
The Eight-Link Chain: From AI Agent to Evidence
Crest.Digital works with a simple chain to make agent reach concrete. Every agent, however it was built, can be described as a path: AI agent, external tool, API, third party, data, action, control, evidence. A board does not need the technical detail of each link. It needs to know that each one has been identified, owned and tested.
The AI Agent
The agent itself: its identity, owner, purpose, model provider and risk tier. Boards cannot oversee what has not been registered, and agents embedded in SaaS tools or built by business teams are the ones most often missing.
The External Tool
Every tool the agent may call: search, email, code execution, browsers, file stores, workflow engines. Each one extends what the agent can do beyond the model, and each has its own vendor.
The API and Connector
The interfaces and credentials joining the agent to those tools. Tokens are frequently long-lived, shared or inherited from the person who set the agent up, which makes the API layer the quiet centre of the risk.
The Third Party
The vendor behind the tool, and the fourth parties behind that vendor: hosting, model and data subprocessors. This is where AI governance meets third-party risk management, and where concentration builds.
The Data
What the chain can read, copy or send: customer records, contracts, bank details, source code, personal data. Data reach determines the privacy, confidentiality and regulatory consequences of any failure.
The Action
What the chain can change: release a payment, edit a vendor bank account, grant access, send a communication, alter a record. Read, recommend and execute must be separated, and promotion between them treated as an approved change.
The Control
The safeguards that constrain the action: enforced approval thresholds, segregation of duties, least-privilege credentials and a stop mechanism someone has actually exercised. A control described in policy but not enforced in workflow is only a statement of intent.
The Evidence
The tamper-evident record that reconstructs the chain afterwards: inputs, tool calls, approvals, outcomes. If evidence stops at the agent's own log, or the agent can edit it, assurance ends where the risk begins.
The most revealing link is usually the fourth. Most organizations have a mature process for onboarding a human-operated SaaS vendor and almost none for the vendor an agent begins calling on its own initiative. A tool added to an agent's toolkit can create a new third-party relationship in minutes, with no procurement event, no due diligence and no entry in the vendor register. That is how AI risk quietly becomes a fourth-party risk you never contracted for.
Why the Agent's Reach Belongs in the Third-Party Risk Register
If an agent depends on an external model API, a search tool, a document store and a payments interface, then four third parties now sit inside a business process, and the agent's failure modes include theirs. Outages, changes in terms, a compromised connector or a vendor's own subprocessor incident can each propagate straight into the action layer. Concentration compounds it: if several agents in different functions rely on the same model provider or tool platform, one dependency carries far more business risk than any single contract review would suggest.
For that reason we argue that AI agent governance and third-party risk management should share one register rather than two. The agent inventory tells you what is running. The vendor register tells you who is behind it. Joined together, they let a risk leader ask questions that neither can answer alone: which critical processes depend on a single AI vendor, which agents can reach data covered by a regulatory regime, which connectors have no assigned owner, and which tools were added after the last risk assessment.
Crest.Digital's agents watch agent access, connectors and third-party changes continuously, and the Crest TPRM platform supplies live intelligence on the vendors and fourth parties behind each tool, so exceptions reach a named owner with a root-cause hypothesis rather than waiting for the next audit cycle.
Identity is the other place the two disciplines meet. An agent that acts through a shared or inherited service account is, in access-governance terms, a privileged non-human user with no owner. We explored this in our article on AI agent identity and access governance: register each agent, give it its own credential, review its entitlements on the same cycle as privileged humans, and treat any change to its permissions as a controlled event. The agentic AI capabilities on the Crest platform take the same approach to the workflows Crest itself runs, with human-in-the-loop approvals at consequential steps.
Six Questions Boards and Audit Committees Should Ask
Directors do not need to configure an agent. They need to ask questions whose honest answers reveal the maturity of the control environment. The Global Internal Audit Standards place governance and risk management oversight squarely within the assurance mandate, and the COSO internal control framework supplies the vocabulary of control activities and information and communication that these questions draw on.
- What is the complete list of agents we run, and who owns each? Including those inside vendor products and built by business teams.
- What can each reach? Tools, APIs, third parties and data, compared with what the task genuinely needs.
- Which of those third parties have we assessed, and when? Especially any added after go-live.
- What can each agent change, and what requires a human? Payments, vendor bank details, access, records, external communications.
- Has anyone stopped a live agent, or revoked a connection, as a test? An untested stop path is a hope, not a control.
- Could we reconstruct any consequential action from a record the agent cannot edit? Evidence is what turns a claim into assurance.
Executive Takeaways
- Reach is the risk: governments are now focusing on AI systems that access other systems, so boards should govern what an agent can touch, not only what it outputs.
- Every agent is a supply chain: tool, API, third party, data, action, control and evidence each need an owner and a test.
- One register, not two: combine the AI agent inventory with the third-party register to expose concentration and unassessed dependencies.
- Continuous beats periodic: agents change their behaviour and toolkits between reviews, so continuous controls monitoring is the practical assurance model.
A Six-Step Playbook for Governing Agent Reach
Crest.Digital delivers this as a configurable "Risk Automation Pod," not a bespoke build. The reusable stack covers integration connectors, an agent orchestration layer, a workflow and approval engine, a risk-scoring engine, an evidence repository, AI logs with explainability, role-based access and audit trails. What is specific to each client is mostly data mapping, control logic, workflow and dashboards, drawn from the organization's own systems and control language.
The Discover → Design → Connect → Deploy → Validate → Transfer Model
- Discover: Inventory every deployed or planned AI agent and trace each chain from external tool to API to third party to data to action, flagging agents with no owner, boundary or stop path.
- Design: Define the permitted access boundary, approval thresholds, stop authority and evidence for each chain link, mapped to named control owners.
- Connect: Integrate identity, ERP, procurement, TPRM, GRC and orchestration systems so boundaries and approvals are enforced and logged inside the workflow.
- Deploy: Run continuous tests on the highest-risk agents and route every out-of-boundary action or third-party change to a named owner with a root-cause hypothesis.
- Validate: Run parallel scenarios that deliberately attempt out-of-scope calls, revoked connections and emergency stops, and calibrate thresholds before wider rollout.
- Transfer or manage: Hand the tested control set to internal audit, risk or compliance, or continue it as a Crest.Digital managed service as the agent estate grows.
Start with two or three agents that already touch payments, vendor-master data or privileged access, so the validation step produces a visible before-and-after picture. Keep the auditor as decision-maker: agents handle the repetitive mapping, testing, evidence collection and follow-up, while people judge materiality and decide what the committee hears. The connection with audit trails for AI agents is direct, because the evidence link is the one most enterprises find they cannot defend once they try to reconstruct a chain.
The regulatory conversation, in Berlin, Beijing and Redmond, will keep evolving, and no board can predict the exact rules. What it can do now is turn an abstract worry into a register, a set of tested controls and a quarterly pack. Organizations that can show what each agent can reach, who stands behind each tool and how they would step in will be well placed whichever direction policy takes. Those that cannot will be answering the question for the first time under pressure.
Crest Perspective
AI governance programmes that treat AI risk as a technology problem will be underprepared for the regulatory environment taking shape in 2025–26. The EU AI Act, NIST AI RMF, and emerging FCA guidance all frame AI risk as a governance and accountability question first — the technology controls follow from having clear answers to who is responsible, what decisions the AI influences, and what the escalation path is when the system behaves unexpectedly.
Frequently Asked Questions
According to a Reuters report syndicated in early September 2026, a spokesperson for Germany's digital affairs ministry said that halting AI development is not a viable option for Europe, and that the government takes warnings from leading AI developers seriously. The spokesperson also said that AI systems able to leave their testing environment and access other computer systems without human intervention would represent an entirely new threat scenario, and called for international coordination that includes the United States and China, with the issue raised at G7 level. For enterprises the useful signal is the shift in framing: from what a model says to what an autonomous system can reach and do.
It describes everything an AI agent can touch beyond its own code: the external tools it calls, the APIs it connects to, the SaaS and cloud services behind them, the data those services hold and the actions they allow, such as sending a payment, changing a vendor record or granting access. Each link is a dependency on a third party or fourth party that sits outside the organization's direct control. Governing AI agent third-party access means inventorying that chain, limiting it to what the task requires, requiring approval for consequential actions and keeping an evidence trail of every call.
Ownership should be explicit and split by responsibility rather than assigned to AI in general. The CIO or CTO typically owns the agent inventory and technical boundaries, the CISO owns identity, access and stop capability, the CRO or head of third-party risk owns the dependency and concentration view, and internal audit provides independent assurance over all three. The board or audit committee should receive one consolidated view, ideally quarterly, showing agents by risk tier, the third parties each can reach, control test results and open remediation with named owners.
Start by comparing the documented access boundary of each in-scope agent with what its credentials and connectors can actually reach, which usually reveals inherited or over-broad permissions. Then trace a sample of real actions end to end through the chain of tool, API, third party, data and action, checking that each step was authorised, approved where required and logged in a record the agent cannot alter. Because agents choose their own sequence of steps, periodic sampling gives weak assurance, so continuous controls monitoring of agent activity and third-party connections is increasingly the practical model.
Crest.Digital's Agentic Risk & Continuous Assurance practice maps each agent's chain from tool to third party to data to action, then designs and connects the missing controls: registers, approval gates, stop paths, monitoring and tamper-evident evidence. The Crest TPRM platform provides continuous intelligence on the vendors and fourth parties behind those tools. Delivery follows a six-step Discover, Design, Connect, Deploy, Validate and Transfer model as a configurable Risk Automation Pod, with human-in-the-loop governance so that people, not agents, decide what is a finding and what the committee hears.