From Chat to Agents: How Large Language Models Are Used

"We use AI" can mean almost anything: a case officer pasting a paragraph into a chat window, an office suite drafting replies from a mailbox, a coding agent editing a repository, a claims system calling a model through an API, or an agent settling low-value claims overnight without anyone approving each payment. The model underneath may be the same, yet the architecture, risk, controls, legal position, cost and competence required differ by orders of magnitude. This chapter therefore defines six usage modes of large language models, one in which people meet AI without choosing it and five in which they use it actively, compares them, explains how use cases drift between them, and sets a minimum control baseline for each. The rest of the book uses the modes as a taxonomy and links back here.

Six usage modes of large language models ordered by integration depth and autonomy, from Mode 0 Ambient AI to Mode 5 Autonomous production agents

Figure 2.1: The six usage modes, ordered by integration depth and autonomy. Drift between the modes is described in the text and summarised in the table below.

From To What moves it
Mode 0 Ambient AI Mode 2 A supplier feature is adopted deliberately
Mode 1 Mode 3 A prompt becomes a shared skill
Mode 2 Mode 5 A tenant agent gains triggers
Mode 3 Mode 4 A skill becomes a product
Mode 4 Mode 5 The approval step is removed

Table for Figure 2.1: Drift paths between the usage modes.

Why the way a model is used matters more than the model

The properties that Chapter 1 identified hold in every usage mode. What changes between modes is how far the model's output travels before a human looks at it, what the model can see, and what it can do. A wrong sentence in a chat window costs a minute; the same sentence from an agent with write access to a case-management system can become a decision about a citizen. A policy written for chat is therefore too weak for agents and too heavy for spell-checking.

Amazon Web Services orders generative AI scopes by how much of the stack the organisation owns (115, AWS, n.d.). The usage modes add what ownership does not capture, the depth of integration and the autonomy granted to the model's output: ownership tells you who patches the model, whereas integration and autonomy tell you what happens when it is wrong or manipulated. The modes are defined by architecture, not by product, and products are named only as examples, with capabilities stated as of 1 November 2026. Following Architecture as Code (Chapters 1 and 2), which makes architecture governable by declaring its intent under version control (66, Nordqvist, 2025), the usage mode is part of the declared intent of every AI use case.

Encountering AI and using it

The first distinction is whether anyone chose to use a model at all. Much of the AI staff meet arrives uninvited, and that passive exposure is Mode 0. Modes 1 to 3 are active use in everyday work, and Modes 4 and 5 active use in the organisation's own systems. The governing question shifts accordingly: for Mode 0 it is what people rely on and what suppliers process, for Modes 1 to 3 what people are allowed to do, and for Modes 4 and 5 what the organisation is accountable for.

Mode 0 – Ambient AI

Ambient AI is AI that people meet without having chosen it: generated answers in search engines, automatic summaries in collaboration tools, and AI features that suppliers enable through a product update. The person receives output rather than operating a model, yet still relies on it.

The first risk is to information integrity. Pew Research Center tracked the browsing of 900 adults in the United States in March 2025 and found that 18 per cent of Google searches produced an AI summary; users who saw one clicked a traditional result in 8 per cent of visits, against 15 per cent without, and clicked a link inside the summary in 1 per cent of visits to such pages (182, Chapekis & Lieb, 2025). The second risk is contractual: when a supplier switches on an AI feature, the data processing changes, often to a sub-processor the original assessment never covered.

The controls are verification guidance in the Article 4 literacy programme, so that staff treat summaries as leads rather than sources; supplier change control, requiring notice before AI features are enabled; and an inventory boundary rule for supplier-enabled features that process personal or confidential data. Where generated text ends up in material published to inform the public on matters of public interest, check whether the Article 50(4) disclosure duty for deployers applies (1, European Union, 2024).

Mode 1 – Conversational assistants

A conversational assistant is a general-purpose chat interface to a model, such as ChatGPT, Microsoft Copilot Chat, Claude, Gemini or Le Chat. The human brings the context in and takes the output away, so the architectural question is where the pasted data goes and on what terms, and the difference between consumer and enterprise tiers is decisive. OpenAI states that, by default, it does not use inputs and outputs from ChatGPT Business, Enterprise, Edu or its API platform for training, while on the Free, Plus and Pro plans data sharing for training is enabled by default and users can opt out (170, OpenAI, 2026). Anthropic changed its consumer terms in August 2025: users of the Free, Pro and Max plans, including Claude Code used from those accounts, were asked to choose whether their data may be used for training, with retention extended to five years for those who allow it and 30 days for those who do not; the change did not apply to Claude for Work, the API or the cloud platforms (171, Anthropic, 2025).

The same brand is thus offered under consumer terms and under commercial terms with a data processing agreement, and a member of staff who signs in to a consumer tier with a private account has moved organisational data outside every contract the organisation holds. That is shadow AI, an anti-pattern in Chapter 20, and it starts in Mode 1 because the barrier to use is a browser tab. Even under enterprise terms, pasted text may contain personal data whose processing was never assessed. The European Data Protection Supervisor's revised orientations of October 2025 address institutions that use generative AI as well as those that build it (181, EDPS, 2025), and Swedish national guidance states that how generative AI may and should be used must be determined in advance, ultimately by the authority's management (127, Digg & IMY, 2025).

The control artefact is an acceptable-use policy with teeth, stating approved services by tier, permitted data classes and how output must be checked, complemented by organisational accounts through single sign-on and consumer endpoints blocked at the proxy. Cost is per seat, or zero for bundled chat, which is why Mode 1 spreads fastest.

Mode 2 – Embedded workplace assistants

An embedded workplace assistant, such as Microsoft 365 Copilot, Gemini in Google Workspace or Claude inside Office applications, reads and acts on mail, documents, calendars and chats with the user's own permissions; the assistant, not the human, retrieves the context. Microsoft states that Copilot "only surfaces organizational data to which individual users have at least view permissions" (173, Microsoft, 2026), and in September 2025 it introduced Agent Mode, which plans and iterates multi-step changes to workbooks and documents (174, Chauhan, 2025). Two properties make Mode 2 a different architecture from Mode 1.

First, the assistant makes existing permission debt visible: every file once shared with "everyone in the organisation" is now reachable through a natural-language question. The remedy for this oversharing through permission sprawl lies in the tenant: sensitivity labels, access reviews, restricted search scopes and data-loss prevention on outputs.

Second, untrusted content such as an external email enters the model's context without the user choosing it, and can carry instructions the model processes alongside the user's request. Greshake and colleagues named this indirect prompt injection in 2023 (51, Greshake et al., 2023), and OWASP ranks prompt injection first among risks to LLM applications (38, OWASP, 2025). EchoLeak, disclosed in June 2025 and assigned CVE-2025-32711, was a zero-click vulnerability in Microsoft 365 Copilot that enabled data exfiltration through a single crafted email, bypassing the vendor's prompt-injection classifier, link redaction and content security policy; Microsoft fixed it on the service side (176, Reddy & Gujral, 2025). The assistant's access to the user's data became the attacker's access.

Data location also needs checking per feature, not per brand: Microsoft's documentation, read in November 2026, notes that Anthropic models within Microsoft 365 Copilot are excluded from the EU Data Boundary and from in-country processing commitments (172, Microsoft, 2026).

The control artefact is tenant configuration as code: enabled features and models, labels, restricted sites and audit settings, held in version control and checked for drift. Cost is a per-seat add-on; the hidden cost is permission remediation.

Mode 3 – Agentic work tools

An agentic work tool runs a model in a loop with tools on a workstation, in a repository or in a cloud sandbox: it edits files, executes commands, calls connectors and opens pull requests, while a human delegates and reviews. Claude Code, OpenAI Codex, GitHub Copilot's coding agent and Cursor are examples in software development, and Anthropic describes Claude Cowork as taking "real actions on your files and in connected tools" in knowledge work (175, Anthropic, n.d.).

Because the human becomes a supervisor, the controls are the agent's permission configuration and execution environment. Claude Code's documentation evaluates deny rules before allow rules, gives managed settings precedence over user and project settings, reserves its bypass mode for "isolated environments like containers or VMs", and offers a shell sandbox that is off by default and, unless configured otherwise, runs commands unsandboxed if it cannot start (178, Anthropic, n.d.). GitHub states that its Copilot cloud agent can push only to a single branch, cannot approve or merge its pull requests, and does not trigger workflows until a person approves them (179, GitHub, n.d.). A user under deadline pressure can relax every one of these defaults. The core risk of Mode 3 is therefore excessive agency, OWASP's term for an agent that holds more functionality, permission or autonomy than its task needs (38, OWASP, 2025), combined with untrusted input. A prompt injection in a public issue led an agent using the GitHub MCP server to leak private repositories (110, Milanta & Beurer-Kellner, 2025), a triage workflow that gave a coding agent shell access on issues anyone could open was used to compromise the Cline project's releases (109, Khan, 2026), and an agent reportedly deleted a production database during a code freeze (83, Nolan, 2025).

Mode 3 also introduces a supply chain of instructions, because skills, rules files, MCP servers and plugins are shared code that shapes what the agent does, and Snyk found at least one security flaw in 36.8 per cent of the 3,984 agent skills it scanned, and a critical-level issue in 13.4 per cent (107, Beurer-Kellner et al., 2026). Secrets are the other exposure: GitGuardian found commits co-authored with one coding agent leaking secrets at about twice the baseline rate (108, GitGuardian, 2026). Some tools are not tied to one provider. OpenCode, an open-source coding agent, states that it has built-in support for many LLM providers, including local runtimes such as Ollama, and lets each agent be configured with its own model (183, OpenCode, 2026), which allows a self-hosted model to handle sensitive material and a cloud model the rest. The routing rule, by which the data class of the task decides which model may see it, must then be recorded and enforced rather than left to the user.

The control artefacts are an agent permission configuration distributed as managed policy, a containment environment, and a curated catalogue of skills and connectors. Cost moves towards consumption, because agents run long loops.

Mode 4 – Built AI applications

In Mode 4 the organisation integrates a model into its own system through an API, a managed platform or self-hosted weights: a retrieval-augmented assistant, a correspondence classifier, decision support or a citizen-facing chatbot. It owns the full lifecycle, and most of the governance in this book, from Chapter 8 to Chapter 11, is designed for this mode. Identity is split between the application's service identity towards the model and the end user's identity towards the application, a gap where many access-control errors live.

Legally, Mode 4 is where the organisation's role can change. Under Article 3 of the AI Act, Regulation (EU) 2024/1689, an organisation that develops an AI system and puts it into service under its own name is its provider (1, European Union, 2024), so an insurer that builds a claims assistant on another company's general-purpose model is the provider of that system. If the use case falls under Annex III, the full provider obligations of Chapter III apply; otherwise the provider may still carry the Article 50 transparency duties, applicable since 2 August 2026, and the Article 4 literacy duty. Article 25 adds that a deployer becomes the provider of a high-risk system if it puts its name on it, substantially modifies it, or changes its intended purpose so that it becomes high-risk. Fine-tuning rarely makes the organisation a provider of the model itself: the Commission's guidelines of July 2025 set an indicative threshold of modification compute above one third of the original training compute (117, European Commission, 2025). The AI Decision Record for every Mode 4 system must therefore state the organisation's role and why.

The threats are the full set, from data poisoning to drift and evaluation gaps, and the controls are a lifecycle in which security, evaluation and policy checks gate every release, which this book calls the DevSecMLOps loop. Cost is consumption plus the team that a lifecycle requires.

Mode 5 – Autonomous production agents

An autonomous production agent acts on business systems without a human approving each step: it receives an event, calls tools that change records, send messages or initiate transactions, and reports afterwards, for example when resolving service tickets or remediating infrastructure alerts. The human sets the mandate, bounds and stop conditions and monitors outcomes rather than actions.

The defining property is identity, because what the agent acts as determines the blast radius. Microsoft's Copilot Studio documentation states that event triggers can only use the agent maker's credentials, and warns that users of a published agent may be able to "access information or prompt the agent to perform actions by using the author's credentials" (180, Microsoft, 2026). An agent that runs as a named employee inherits that employee's permissions and leaves an audit trail that names the wrong actor, so each agent needs a dedicated least-privilege workload identity. Emerging control planes reflect this: Microsoft's Agent 365 centres on an agent registry and lets administrators quarantine unsanctioned agents (106, Lamanna, 2025).

The threats are those of Modes 2 to 4 multiplied by speed and scale. ForcedLeak, disclosed in September 2025, is an example: instructions hidden in a web-form field were processed by a CRM agent, which sent CRM data to an expired domain that the platform's content security policy still trusted; the vendor responded by enforcing trusted URLs for agent output (177, Levi, 2025). OWASP's Top 10 for Agentic Applications catalogues goal hijacking, tool misuse, identity and privilege abuse, and cascading failures (84, OWASP, 2025).

The control artefacts are agent definitions in version control, each with its mandate, tool allow-list, identity, rate and value limits, approval policy and a tested stop path, which Chapter 9 checks before release. The AI Act does not regulate autonomy as such, but autonomy amplifies every obligation the use case triggers, and Article 14 oversight is hard to evidence when no human sees individual actions. Cost scales with event volume, so budget limits are a safety control too.

The usage modes compared

Table 2.1 compares the modes along the dimensions later chapters use.

Dimension Mode 0 – Ambient AI Mode 1 – Conversational assistants Mode 2 – Embedded workplace assistants Mode 3 – Agentic work tools Mode 4 – Built AI applications Mode 5 – Autonomous production agents
Whether the use is chosen No By an individual By the user, within tenant settings By a team or individual By the organisation By the organisation
Who builds and operates Supplier Vendor; organisation configures accounts Vendor; organisation configures the tenant Vendor tool; organisation configures policy Organisation Organisation, often on a vendor agent platform
Where the model runs Supplier's cloud Vendor cloud, consumer or commercial terms Vendor cloud, per feature Vendor cloud; tools local or sandboxed Chosen region, platform or self-hosted As Mode 4
What the model sees Nothing chosen by the user What the user pastes or uploads The user's mail, documents, chats and meetings A repository, file system, terminal and connectors A curated corpus and structured inputs Live business systems and inbound events
What it can do Present output to a reader Produce text Draft and change documents and messages Edit files, execute commands, open pull requests What the application permits Act on records, messages and transactions
Identity and permissions Supplier's service, or the user's account The user's account The user's own permissions, delegated The user's credentials or a sandbox token Application service identity plus end-user identity A dedicated agent identity, ideally
Human role Recipient who relies on the output Performs every action Reviews and sends Delegates, approves plans, reviews output Uses output inside a designed workflow Sets bounds, monitors, can stop
AI Act position Usually none as provider; deployer where used under its authority; Article 4 Deployer; Article 4 Deployer; Article 4 Deployer; Article 4 Often provider; Articles 4 and 50; high-risk via use case Provider or deployer; high-risk via use case
Typical failure and threat Unverified reliance Data leakage, shadow AI Oversharing, indirect prompt injection Excessive agency, secrets, supply chain Poisoning, drift, evaluation gaps Loss of control at scale, identity abuse
Control artefact Verification guidance, supplier change control Acceptable-use policy and approved-service list Tenant configuration, sensitivity labels Managed permission policy, sandbox, catalogue AI Decision Record and the DevSecMLOps loop Agent definition, approval policy, stop path
Cost model None visible; bundled into other licences Per seat or bundled Per seat add-on Seat plus consumption Consumption plus team Consumption scaling with events
Competence Verification habits Literacy for all staff Literacy plus tenant administrators Engineers who configure and review agents AI engineering and evaluation As Mode 4, plus agent safety

Table 2.1: The six usage modes compared.

Two cautions apply to the AI Act row. The high-risk classification follows the use case under Article 6 and Annex III, not the mode, so a Mode 1 assistant used to rank job applicants is part of a high-risk use. And Article 26 deployer obligations attach only to high-risk systems, while Article 4 applies to every AI system. Article 4, as amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744, requires providers and deployers to take measures to support the AI literacy of their staff, without guaranteeing a specific level for each individual (27, European Union, 2026). Literacy measures should therefore be differentiated by mode, because a Mode 1 user and a Mode 5 agent owner need to understand very different things.

Mode drift: when a use case moves

Use cases rarely stay in their first mode. A case officer's good prompt for summarising consultation responses (Mode 1) becomes a shared skill in the team's agentic tool (Mode 3), is built into the case-management system with a corpus and evaluation (Mode 4), and a year later is proposed to run on every consultation and file its themes automatically (Mode 5). Drift is often how good use cases mature; the failure is that the controls stay where the use case started. A prompt carries no evaluation set, a shared skill no owner, and an automation inherits the permissions of whoever first ran it. Drift also runs sideways, as when an embedded assistant's agent gains an event trigger. Governance therefore attaches to the use case, not to the tool, and treats every change of mode as a change event that requires review.

One vendor, several modes

Brand names cut across the modes, which makes them poor units of governance: Microsoft's Copilot name covers all of Modes 1 to 5, and Anthropic, OpenAI and Google each span at least three. Even within one brand the data terms differ by feature, as the Anthropic-models exclusion from Microsoft's EU Data Boundary shows (172, Microsoft, 2026). Organise the inventory by use case and mode, and write approvals in the form "service X, tier Y, mode Z, for data classes up to C".

Minimum control baseline per mode

Every mode needs some controls, and the higher modes inherit those of the lower ones. Table 2.2 is a floor, not a target: the risk class set through the classification of Chapter 8 adds controls on top, and an organisation with a low risk appetite will raise the floor.

Mode Minimum baseline, in addition to the modes above it
Mode 0 – Ambient AI Verification guidance; supplier notice clauses before AI features are enabled; data protection assessment revisited; supplier-enabled features with personal or confidential data in the inventory
Mode 1 – Conversational assistants Approved-service list by tier; organisational accounts through single sign-on; consumer endpoints blocked at the proxy; data-class rules; Article 4 literacy module
Mode 2 – Embedded workplace assistants Access review before licences are assigned; sensitivity labels enforced on output; restricted grounding scopes; prompt and response audit; tenant settings in version control
Mode 3 – Agentic work tools Managed permission policy users cannot override; fail-closed sandbox; egress allow-list; no production credentials; catalogue-only skills and connectors; generated changes pass the same gates as human changes
Mode 4 – Built AI applications AI Decision Record stating the AI Act role; inventory entry; evaluation suite and release gate; AI gateway with logging; Article 50 disclosure where people interact with the system
Mode 5 – Autonomous production agents Dedicated least-privilege identity; versioned agent definition with mandate, tool allow-list and limits; approval policy above thresholds; tested stop path with a named owner; behavioural monitoring

Table 2.2: Minimum control baseline by usage mode.

Practical guide: classify your AI estate by mode and assign a minimum control baseline

Purpose. Establish, within one quarter, a register of every use of large language models, classified by usage mode, with the baseline of Table 2.2 assigned and its gaps visible.

Roles. The AI architect owns the register; the security team supplies telemetry, tenant administrators configuration exports, business owners confirmation of each use case, and the data protection officer review of entries with personal data. In a DORA-regulated entity, include the ICT risk function.

Steps.

  1. Collect evidence before asking for declarations: 90 days of proxy and DNS logs for AI service domains, AI add-ins and agents enabled in the tenant, agent tools on developer workstations, and API keys issued for model providers.
  2. Ask the owners of the main SaaS contracts which AI features their suppliers have enabled; these Mode 0 entries rarely show in telemetry.
  3. Group the evidence into use cases, not tools; a different data class makes a different use case.
  4. Classify each use case with these questions, in order. Did anyone choose to use the feature? If not, Mode 0. Does the model act on business systems without a human approving each action? If so, Mode 5. Did the organisation build or integrate the system? If so, Mode 4. Does it execute tools, edit files or run commands? If so, Mode 3. Does it retrieve organisational content on its own? If so, Mode 2; if not, Mode 1. When in doubt, choose the higher mode.
  5. Record vendor, product, tier, data classes, identity, owner and AI Act role in a version-controlled register, as in the worked example below.
  6. Assign the baseline for the mode and mark each control as met, partly met or missing, with evidence links.
  7. Act on the gaps in order of exposure: consumer-tier use with personal data first, Mode 3 and Mode 5 entries without managed policy or dedicated identity second, Mode 2 rollouts without an access review third.
  8. Add a pipeline check that fails when an entry's mode changes without a linked review, and reconcile against telemetry every quarter.

Definition of done. Every use in the telemetry maps to a register entry with a mode, an owner and a baseline status, and no consumer-tier use with personal or confidential data remains unaddressed. The 90-day window and quarterly cycle are defaults that fast-moving organisations should shorten.

Worked example: a usage-mode register

Illustrative example. Nordvik Region, one of the two example organisations, keeps its usage-mode register as YAML in the same repository as its AI inventory. As its register policy states, it runs no autonomous production agents and limits agentic work tools to its platform team.

# usage-modes/nordvik-region.yaml - illustrative example
organisation: Nordvik Region
register_version: 2026.11.1
review_cycle_days: 90
policy: {modes_not_permitted: [5], mode_3_permitted_for: [platform-team]}
use_cases:
  - id: NR-UC-001
    name: Meeting recaps switched on by the collaboration-suite supplier
    mode: 0
    data_classes: [internal, personal]
    baseline: {supplier_notice_clause: partly-met, dpia_revisited: met, inventory_entry: met}
    owner: chief-digital-officer
  - id: NR-UC-004
    name: Drafting and rephrasing in the approved enterprise chat tool
    mode: 1
    product: {vendor: VendorB, service: chat assistant, tier: enterprise}
    identity: user-sso
    baseline: {approved_service: met, sso_only: met, consumer_block: partly-met}
    owner: chief-digital-officer
  - id: NR-UC-017
    name: Coding agent for the platform team's infrastructure code
    mode: 3
    identity: sandbox-token
    baseline: {managed_policy: met, sandbox_fail_closed: missing, catalogue_only: met}
    owner: head-of-platform
  - id: NR-UC-020
    name: Internal staff assistant for drafting and guidance search
    mode: 4
    ai_act_role: provider
    aidr: AIDR-0211
    owner: chief-digital-officer
  - id: NR-UC-021
    name: Benefits-triage system, procured
    mode: 4
    risk_class: high-risk-annex-iii-5a
    ai_act_role: deployer
    aidr: [AIDR-0007, AIDR-0011]
    fria: FRIA-2026-002
    owner: head-of-financial-assistance

Hansa Mutual's register adds two DORA fields for its EU entities, the ICT third-party register reference and whether the use case supports a critical or important function, and it records mode drift properly. Its claims-triage agent entry names its previous mode (4), links the approving change review CR-2026-118, and states limits that a pipeline can check against the runtime configuration: it may not approve payments, is capped at 400 actions per hour, and needs human approval for reserve changes. Neither register names a person; roles are resolved through the roles file described in Chapter 9.

Worked example: which mode for this task

Illustrative example. The decision table encodes the least autonomy that works: choose the lowest mode that can do the task, because every step up adds permissions, identities and oversight duties. Nordvik Region issues it without the Mode 5 row; Hansa Mutual issues it in full.

Task Recommended mode Why not a lower mode Why not a higher mode
Check a regulatory threshold seen in a search summary No mode: verify in the primary source Mode 0 output is a lead, not a source —
Summarise a long internal mail thread before a meeting Mode 2 Pasting the thread into chat copies personal data needlessly No action on systems is needed
Refactor a module and update its tests Mode 3, in a sandbox The task needs file edits and command execution Every change still passes review
Answer residents' questions about services on the website Mode 4 A chat tool cannot carry the corpus, evaluation, disclosure and logging Answers inform; they do not decide
Route incoming claims correspondence around the clock Mode 5, with limits and a stop path Volume makes per-item approval impractical —
Decide eligibility for a social benefit Mode 4 decision support, with a human deciding — An autonomous benefit decision is a high-risk use whose oversight duties per-action autonomy cannot meet

Table 2.3: Which mode for this task (illustrative).

How the rest of the book uses the modes

From here on, the modes are a shared vocabulary. Chapter 3 sets out the AI Act roles that Table 2.1 summarises, Chapter 9 turns this chapter's register into a governed inventory with policy gates, Chapter 10 designs oversight where no human sees individual actions, and Chapter 14 differentiates competence by mode. Where a chapter's answer differs by mode, it includes an "Across the usage modes" subsection that links back here. The engineering artefacts on which the higher modes depend are outside this book's scope; it asks who approves them, against which policy, and with what evidence.

Nordvik Region and Hansa Mutual

Nordvik Region's exposure sits at the two ends of its scale: Mode 0 and Mode 2 risks it did not design, where its leverage is the supplier contract and tenant hygiene, and a Mode 4 benefits-triage system that makes it a deployer of a high-risk system. Hansa Mutual, by contrast, uses every mode and builds most of what it runs, so its risk concentrates in Modes 3 and 5. Its group footprint also means a tool rolled out group-wide falls under the AI Act and DORA in its EU entities, reaches Norway only through the EEA Agreement, meets other regimes in the UK and Switzerland, and requires works-council consultation in Germany, the Netherlands and Sweden before tools that can monitor employees go live.

Summary

Using a large language model is not one activity but at least six, and the differences are architectural. In Mode 0 the controls are verification habits, supplier change control and an inventory boundary; in Mode 1 the decisive question is the tier and its data terms; in Mode 2 the assistant exposes permission debt and lets untrusted content reach the model; in Mode 3 the controls are permission policy, containment and a catalogue; in Mode 4 the organisation is often the provider under the AI Act; and in Mode 5 identity, limits and a tested stop path become the primary controls.

Because use cases drift between modes, governance attaches to the use case and treats every change of mode as a change event, and because brands span several modes, approvals name the mode rather than the vendor. The baseline, practical guide and registers let an organisation classify its estate in a quarter. Chapter 3 now turns to the AI Act and the European legislation around it.

Sources

  1. Amazon Web Services. Generative AI Security Scoping Matrix. aws.amazon.com, undated. (115, AWS, n.d.)
  2. Nordqvist, G. (2025). Architecture as Code. Companion volume to this book, published at aac.geon.se. (66, Nordqvist, 2025)
  3. Chapekis, A. & Lieb, A. (2025). Google users are less likely to click on links when an AI summary appears in the results. Pew Research Center, 22 July 2025. (182, Chapekis & Lieb, 2025)
  4. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
  5. OpenAI (2026). What is the ChatGPT Enterprise and Business data policy? OpenAI Help Center, living page read 1 November 2026. (170, OpenAI, 2026)
  6. Anthropic (2025). Updates to Consumer Terms and Privacy Policy. Anthropic, 28 August 2025. (171, Anthropic, 2025)
  7. Microsoft (2026). Enterprise data protection in Microsoft Copilot and Microsoft Copilot Chat. Microsoft Learn, updated 31 October 2026. (172, Microsoft, 2026)
  8. European Data Protection Supervisor (2025). Generative AI and the EUDPR. Orientations for ensuring data protection compliance when using generative AI systems, version 2. EDPS, 28 October 2025. (181, EDPS, 2025)
  9. Agency for Digital Government and Swedish Authority for Privacy Protection (2025). Inför en AI-policy (Introducing an AI policy), part of the national guidelines for the use of generative AI in public administration. Digg, published January 2025, updated 3 June 2026. (127, Digg & IMY, 2025)
  10. Microsoft (2026). Data, Privacy, and Security for Microsoft Copilot. Microsoft Learn, updated 31 October 2026. (173, Microsoft, 2026)
  11. Chauhan, S. (2025). Vibe working: Introducing Agent Mode and Office Agent in Microsoft 365 Copilot. Microsoft 365 Blog, 29 September 2025. (174, Chauhan, 2025)
  12. Greshake, K., Abdelnabi, S., Mishra, S., Endres, C., Holz, T. & Fritz, M. (2023). Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security (AISec '23). (51, Greshake et al., 2023)
  13. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. OWASP GenAI Security Project. (38, OWASP, 2025)
  14. Reddy, P. & Gujral, A. S. (2025). EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System. arXiv:2509.10540, AAAI Fall Symposium Series 2025. (176, Reddy & Gujral, 2025)
  15. Anthropic. Claude Cowork. Claude product page, living document. (175, Anthropic, n.d.)
  16. Anthropic. Configure permissions and Configure the sandboxed Bash tool. Claude Code documentation, living page. (178, Anthropic, n.d.)
  17. GitHub. Risks and mitigations for GitHub Copilot cloud agent. GitHub Docs, living page. (179, GitHub, n.d.)
  18. OpenCode (2026). OpenCode documentation: Intro, with the linked Providers and Agents pages. Last updated 1 November 2026; repository licensed under MIT. (183, OpenCode, 2026)
  19. Milanta, M. & Beurer-Kellner, L. (2025). GitHub MCP Exploited: Accessing private repositories via MCP. Invariant Labs, 26 May 2025. (110, Milanta & Beurer-Kellner, 2025)
  20. Khan, A. (2026). Clinejection — Compromising Cline's Production Releases just by Prompting an Issue Triager. 9 February 2026, updated 18 February 2026. (109, Khan, 2026)
  21. Nolan, B. (2025). An AI-powered coding tool wiped out a software company's database, then apologized for a 'catastrophic failure on my part'. Fortune, 23 July 2025. (83, Nolan, 2025)
  22. Beurer-Kellner, L., Kudrinskii, A., Milanta, M., Bonde Nielsen, K., Sarkar, H. & Tal, L. (2026). Snyk Finds Prompt Injection in 36%, 1467 Malicious Payloads in a ToxicSkills Study of Agent Skills Supply Chain Compromise. Snyk blog, 5 February 2026. (107, Beurer-Kellner et al., 2026)
  23. GitGuardian (2026). The State of Secrets Sprawl 2026. GitGuardian, March 2026. (108, GitGuardian, 2026)
  24. European Commission (2025). Guidelines on the scope of the obligations for general-purpose AI models established by Regulation (EU) 2024/1689 (AI Act). Annex to C(2025) 5045 final, 18 July 2025. (117, European Commission, 2025)
  25. Microsoft (2026). Event triggers overview – Microsoft Copilot Studio. Microsoft Learn, updated 10 September 2026. (180, Microsoft, 2026)
  26. Lamanna, C. (2025). Microsoft Agent 365: The control plane for AI agents. Microsoft 365 Blog, 18 November 2025. (106, Lamanna, 2025)
  27. Levi, S. (2025). ForcedLeak: AI agent risks exposed in Salesforce Agentforce. Noma Security blog, 25 September 2025. (177, Levi, 2025)
  28. OWASP Foundation (2025). OWASP Top 10 for Agentic Applications for 2026. OWASP GenAI Security Project, 9 December 2025. (84, OWASP, 2025)
  29. European Parliament and Council of the European Union. Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). Official Journal of the European Union, 24 July 2026. (27, European Union, 2026)