When Does a Tool Become an Agent

This is the threshold question. On one side sits a productivity tool that needs an acceptable-use rule and a line in an inventory. On the other sits a deployment that needs an owner, its own identity, bounded permissions, a stop mechanism and an evidence trail. The question has no product-level answer, because the same product is a chat box for one team and a privileged integration for another.

The threshold in one sentence. A deployment crosses into agent territory when it can change something outside its own conversation, using access that matters, without a human reading that specific action before it takes effect. The rest of this page is how to establish those three facts about software you did not build.

A productivity tool becomes an AI agent, for governance purposes, at the point where it can take an action with effect outside its own conversation, using access to something that matters, without a human reading that specific action first. Those are three separable facts — reach, consequence and mediation — and not one of them is settled by the product name, the marketing category, or the licence tier your organisation bought. The practical consequence is that you classify deployments rather than products. One enterprise licence can produce a dozen deployments across an organisation, sitting at four different risk levels, and the differences between them are things you configured: which connectors are enabled, which identity the deployment runs as, what the tools are permitted to do, and whether a person reads the action before it happens. What follows is a method for establishing that, five tiers with the obligations that attach at each, a decision tree, the evidence an assessor asks for, and a policy trigger that catches the transition without demanding a risk assessment for every prompt.

The properties are not a checklist to be scored four out of four. They multiply rather than add: autonomy over reach over consequence, with persistence as the frequency term that decides how often the product of the other three is exposed. A system with total autonomy and no reach is harmless. A system with enormous reach and a human reading every action is a research assistant. The two together, running unattended, are the thing that needs a named owner.

This is also the structure the security community has converged on. The current OWASP Top 10 for LLM Applications — the 2026 edition, published in August 2026 by the OWASP GenAI Security Project — carries Excessive Agency at LLM03, promoted from sixth place in the previous edition, and names its root causes as excessive functionality, excessive permissions and excessive autonomy. Those map exactly onto the tool surface, the entitlements and the absence of mediation. Item numbers move between editions — the same risk sat at LLM08 in the 2023 list and LLM06 in the 2025 one — so cite it by name and edition rather than by number alone.

Those facts are stated as documented at the time of writing. Product behaviour, menu names and defaults move, but the governance question each one answers does not. Verify the current behaviour in your own tenant rather than in a datasheet, and record the date you checked.

Enterprise chat and workplace assistants — ChatGPT Enterprise, Microsoft 365 Copilot, Gemini for Workspace and their equivalents — are blank chat windows until connectors are enabled. Once grounded in a document estate, the deployment reaches whatever the requesting user is entitled to reach, which converts a latent permissions problem into an immediately exploitable one. The tier boundary is a single switch: whether the grounding connector is enabled at all, and where it is, whether the estate behind it has ever had a permissions review. Both are administrator settings rather than projects, which is why this transition almost never arrives through change control. That is a data-access question long before it is an AI question, and it is covered in permission hygiene and connector inheritance.

Builder surfaces such as Copilot Studio and the agent builders inside major platforms are a category of their own, because approving the platform authorises an unbounded set of future deployments that no one has seen yet. The fact to establish before anything else is whether a published agent authenticates as its maker or as the invoking user. If it runs as its maker, one person’s entitlements are handed to everyone who can invoke it, and a builder in a well-connected administrator’s hands is a privilege-escalation path with a friendly interface. If it runs as the invoker, reach varies per user and the risk moves to whoever is most over-entitled. Either way, capability approval cannot be a one-time gate at purchase. It has to attach to each thing built.

Coding tools — Claude Code, Cursor, GitHub Copilot — span the widest range under one word. An inline completion suggesting the next line and an agent with shell access, repository write permissions and a terminal are both called coding assistants. The first is T0 or T1, and the second is at least T2 and often T3. Three settings decide which you have: whether shell or terminal execution is enabled, whether the agent’s account holds repository write, and whether that account can bypass branch protection or push to a protected branch. The third is the one that defeats the “a human reviews the pull request” argument, and it is a checkbox in repository settings rather than anything to do with AI. Check it before you accept a tier. The distinguishing configuration is specific and checkable, and the detail is in governing coding agents.

MCP servers and tool connectors deserve the sharpest framing: an MCP server is closer to a privileged integration than to a browser extension. The tools it exposes define reach, and the set of tools can change when the server is updated. The fact that matters is whether your client re-reads the server’s declared tool list on every connect — because where it does, the set of tools you approved is not necessarily the set you will run tomorrow, and the change arrives without an install, a ticket or a version number you would notice. That is why tool approval and capability change is a separate discipline from approving the server once.

Two things are structural enough to plan around. Consumer tiers and enterprise tiers generally differ in retention, administrative control and contractual protection, which is why the same brand used on a personal account is a different governance object from the same brand on your tenant. And any product that can acquire new tools or connectors can change its own tier after you approve it. Everything else — whether inputs are used for model training on your plan, what an admin console can genuinely restrict, how long tool-call logs are retained and whether they are exportable — is a question to put to current vendor documentation and to your contract, with the answer dated and re-checked on a stated cadence rather than assumed.

1. Identity. What does it run as? A delegated user token means reach equals that user’s entitlements and every action is attributable to a person who did not perform it. A service principal or app registration means reach equals whatever was consented at registration, which is frequently far wider than the use case and frequently org-wide. A shared privileged account means attribution is gone entirely, and with it your ability to investigate. The artefact is the enterprise application and consent-grant export from your identity provider. Read the scopes, not the display names.

2. Reach, computed and transitive. Reach is the union of the tool surface and the identity’s entitlements — and then you follow the edges. A tool that writes to a repository reaches whatever the pipeline on that repository deploys. A tool that writes to a ticket reaches whatever automation fires on ticket creation, which in many estates includes customer email. Stopping at the first hop is the single most common analytical error, and it is what makes a sandbox feel safer than it is.

3. Verbs, ranked by reversibility. Read and search, then create and modify, then delete, transfer, publish and pay, then configure identity or security. Rank them by how hard the effect is to undo before somebody notices, not by how alarming the word sounds. Creating a draft is a write verb with almost no consequence. Changing a group membership is a configuration verb that quietly rewrites the reach of everything else.

4. Mediation. Does a human read the specific action before it takes effect, and can you evidence that? Approving a workflow once is not mediation. The OWASP guidance is unusually direct on this point: the decision about whether an action is permitted belongs in deterministic authorisation logic, not in the model, and it should be enforced somewhere the model cannot reach — inside the tool, at a policy checkpoint between the tool and the target system, or by the target system itself. A graduated policy then follows naturally, with reversible actions proceeding and irreversible ones routed to a person.

The four inputs are only useful if you know where they live. Console names and menu paths below are as documented at the time of writing — verify against current vendor documentation, because vendors rename menus considerably more often than they change what the setting does.

The reason this method outlives any particular product generation is that all four inputs are facts about your environment. Vendor roadmaps, model versions and feature names change constantly, but the consent grant in your tenant, the tool manifest in your configuration and the approval record in your ticketing system do not change without somebody changing them. Assess what you can observe.

Four tie-breakers settle most of the arguments the tree produces. Among unattended deployments, a deployment takes the tier of the highest-consequence tool it can reach, even if that tool is expected to be used rarely. Mediation can hold a deployment below that tier only where the approval demonstrably covers the consequential verb — per action, evidenced, timely, and with a real record of proposals amended or rejected — which is a high bar and is rarely met at volume. Where it is met, record the mediation evidence alongside the tier, because the tier now depends on a control that can quietly stop working. A deployment that operates a signed-in browser or desktop session has the entitlements of that session, so in the absence of scopes it inherits the whole user. And a deployment whose tier depends on human approval loses that defence entirely if you cannot produce approval records, taking the tier its verbs set rather than dropping by one — the claim and the evidence have to agree.

The re-entry rule is what makes the tree a control rather than a form. Any change to identity, tool surface, scopes or the approval step sends the deployment back to Q1. That rule is the whole subject of the policy trigger section below, and it is the single thing most AI policies are missing.

Nothing in that sequence required a new contract, a new supplier or a new budget line. The deployment moved from T1 to T4 inside a platform that had been correctly approved, and every individual change was made by a competent person for a sensible reason. That is what makes this the ordinary failure rather than an unusual one: there was no moment at which anybody would have described what they were doing as deploying an autonomous agent with payment authority.

This page keeps telling you to record the classification in the AI register, so here is what a register row actually holds — the same deployment, on the day it was approved and on the day it reached T4. Use it as the field schema. The two value columns are only there to make the drift legible. The tier row is derived from the four inputs above it, and the classification-date row is the one that turns a governance failure into something visible on a page.

Four lessons fall out of it. The identity swap on 30 June was the largest single change and the least discussed, because it was framed as a reliability fix rather than a permissions decision. The log retention that made the incident uninvestigable was set long before anyone thought of those logs as evidence, which is why retention belongs in the T3 obligations rather than in an incident review. The reconciliation control that eventually caught it worked, but at a four-day latency — the last posting on 14 August, detection on 18 August — that was fine for a human process and far too slow for a system running at 07:00 every weekday. Four days of latency against seven days of retention is what turned a recoverable error into an uninvestigable one. And the control that would have prevented the whole sequence is not a better initial assessment — the March classification was correct — but a trigger that fires when capability changes.

For what the resulting incident record has to capture, and how to decide whether this is reportable at all, see what counts as an AI incident and monitoring agents that work unattended.

The separation is not bureaucracy for its own sake. It is what lets you say yes quickly to the platform while keeping the right to ask questions about the fifth thing built on it, and it is the difference between a register of contracts and a register of risk objects. The vendor and use-case halves are treated at length in vendor approval is not use-case approval and AI supplier due diligence.

Two points about how this behaves in a SOC 2 examination specifically. There is no trust services criterion about AI, and none is needed — an AI deployment lands under criteria you already claim. Classification and the risk analysis behind it sit with the risk identification and analysis criterion at CC3.2. Identity, scopes and least privilege sit at CC6.1, CC6.2 and CC6.3, which asks that access be authorised, modified or removed based on roles and responsibilities, giving consideration to least privilege and segregation of duties. Adding a tool or widening a scope is a change under CC8.1. Monitoring for anomalous activity is CC7.2. The supplier half is CC9.2. And if a deployment sits inside the system boundary, the description prepared by management under the SOC 2 description criteria in DC section 200 has to describe it — an agent acting on in-scope systems that appears nowhere in Section 3 is a completeness problem in the description, not merely an omission.

Sample-size behaviour is worth anticipating. The population of registered deployments is usually large enough to sample, and the T3 and T4 subset is usually small enough that a tester examines all of it — which is the same small-population arithmetic that governs any low-frequency control: with a population of three, one undated classification is a deviation in a third of the population, not a rounding error. Expect the tester to ask for the exports, filters and record counts behind your registry rather than the registry alone, on the same completeness-and-accuracy reasoning applied to any information produced by the entity. The general evidence mechanics are set out in what auditors actually accept.

On the ISO side the emphasis differs. ISO/IEC 42001:2023 is a management system standard for AI, certifiable by an accredited certification body, and its reference controls in Annex A include objectives covering the AI system life cycle, data for AI systems, information for interested parties, the use of AI systems and third-party relationships. What an auditor tests there is that your scope statement, your classification scheme and your Statement of Applicability agree with each other and with what the register actually contains. Where an impact assessment is called for, ISO/IEC 42005:2025 gives published guidance on how to structure and document one, and NIST’s AI Risk Management Framework 1.0 supplies a widely recognised vocabulary — govern, map, measure, manage — with its Generative AI Profile applying those functions to generative systems. TCSA advises, implements and coordinates against all of these, but certificates are issued by accredited certification bodies and SOC reports by licensed CPA firms, never by us.

Two of these have their own treatments: human-in-the-loop that actually means something and shadow AI on personal accounts. Where an agent has been given its own identity, the delegation questions that follow are in agent identity and delegated authority.

The cost then concentrates exactly where you would want it to. Each T3 deployment needs its own identity, a scope review, ceilings, a tested stop mechanism and log retention long enough to investigate — a few days of engineering each, not weeks. Each T4 deployment adds an impact assessment and independent review. If your T3 and T4 population is large enough that this sounds unaffordable, that is a finding about the estate rather than about the method.

Two sequencing notes from readiness work. Classify before you write the policy, because a policy written against an imagined estate always mis-sizes the tiers. And put the trigger in before you finish classifying, so the classification you are doing does not go stale while you do it.

On engagement shape: Tranquility Cybersecurity advises on the scheme, builds the register, runs the classification with your teams and coordinates the examination or certification audit that follows. ISO/IEC 42001 certificates come from accredited certification bodies and SOC reports from licensed CPA firms. ISO 42001 pricing is all-inclusive and indicative: from $4,000 (₹3–3.5 Lakh) for small organisations, $5,000–6,000 (₹4.5–5 Lakh) for growing companies and $8,000 (₹7–10 Lakh) for large enterprises. It includes the accredited certification body’s audit fee. The certificate is issued by that certification body, not by Tranquility Cybersecurity, and the final figure depends on the certification body you choose.

Related reading: the ten questions that govern any AI agent, building the register, vendor versus use-case approval, kill switches and circuit breakers, prompt injection once tools are connected, and the ISO 42001 hub.