The story in brief
Controls now govern what agents do, but one agent at a time; nobody limits what the fleet does in total
Every control in this analysis is a small protocol: a rule about what an agent may do, written down by someone and checked at some point in the agent’s work. In two years the protocols moved from words to deeds. A firm can now decide which tools an agent may pick up, whose identity it acts under, how much it may spend and when it must ask a person.
What it mostly cannot decide is how much all of its agents may do together. Most checks look at one action, one agent or one user; the few that look across the firm mostly keep records or meter the vendor’s bill. That works for ten agents. With ten thousand, every agent can stay inside its own limits while the firm’s total exposure grows without anyone watching it: many small refunds that add up to a large one, many agents leaning on the same system, one shared weakness that every agent has at once. And the fleet a firm can count is only the part on its own systems: an agent an employee runs on a personal account, on a personal device, sits, on this analysis’s reading, outside nearly every control we found.
Why per-agent? Not mainly because of how vendors bill, a test in this analysis found. Products priced per seat do put more of their rules on each person or team (21% against 8%), but free, open-source tools and open protocols, which bill nothing, check one request at a time even more often than paid products (87% against 68% of their checks). The likelier reason, an interpretation, is where checks are easiest to build: where each request passes. Agent controls are being built the way API and cloud controls were, as features a firm may switch on, not the way water and industrial safety controls were, as duties the law sets first. The law has not yet required any. Automated trading, the nearest comparison, shows the other path: there the law requires controls over the whole system, a kill switch and firm-wide limits among them, because each algorithm within its limits can still add up to ruin.
Below are our ten main findings: the fleet result first, then the rest, most certain first. The small labels say how sure we are and open the evidence.
A control is one documented setting, policy or feature that constrains, changes, approves or records what an AI model or agent may do. One vocabulary marks how sure we are: High, the evidence shows; Medium, it points to; Low, an early sign.
- 134 of the 1,061 documented controls that check, count or show something take a whole firm’s agents or users into account: 70 keep records, 30 meter the vendor’s service, 21 switch a feature off for everyone, 6 detect risky behaviour, 1 limits what agents do in total. Two coders from different model families coded 240 controls blind (kappa 0.72 on where a rule is set, 0.78 on what it counts); a third model settled the 71 disagreements and re-read all 148 controls first coded as firm-wide, moving 17 out. Documentation shows what is on offer, not what firms switch on.
Few controls look across the fleet. About one in eight takes all of a firm’s agents into account, and those mostly keep records, meter the vendor’s bill or switch a feature off for everyone. Just one limits what agents do in total.
- 2,046 controls from 46 products and 31 vendors, in 14 categories and 7 mechanisms. Two coders from different model families agreed at kappa 0.86 to 0.87 on 144 controls not used to build the map; both found at least 96% of planted codes.
The controls vendors document sort cleanly into a short list of things an agent touches, from its tools and identity to its data, spend and records, and a few ways of acting on them: allow, block, cap, ask a person, steer, detect, record.
- Counted from the coded inventory: each of identity, logs, tools and usage limits is documented by at least 32 of 46 products and 25 of 31 vendors.
The basics are everywhere. Most products, and nearly all vendors, control who the agent is, which tools it may use, how much it may use and what record it leaves.
- From 289 dated availability events: the share coded as scoped to an agent’s tools, actions, session or identity rose from 5% in 2024 to 54% in 2025. The result holds when archive and press dates are dropped.
Controls moved from words to actions in a single year: new controls stopped being mostly text filters and started being written for agents’ tools, sessions and identity.
- Quoted from the vendors’ own documentation and checked against the stored pages: Anthropic on Claude Code managed settings; Google on Gemini Code Assist.
Even rules a firm sets centrally can be edited where they run: one major vendor documents its managed settings as “a client-side control, not a security boundary”. Another says there is no undo for changes its agent makes outside the editor.
- A text search of 2,111 rows finds no value cap outside the payment protocols AP2 and ACP. A control a vendor offers but does not document would be missed.
A cap on how much money an agent may move exists only in the new agent payment protocols, not on refunds, orders or other actions.
- From dated release events: AWS AgentCore Policy, generally available March 2026. Microsoft’s Agent 365 control plane may also be generally available; its page was updated after launch.
A central rulebook that checks every agent action is brand new: the first generally available one shipped in March 2026, and only a handful of vendors have one. In our coding, even these check each action against the rules; they do not add actions up.
- Rests on what 46 products document. Closest: ServiceNow’s gateway pause, Entra’s agent disable, MCP and A2A task cancel; resetting single sign-on ends every session in one product, and Intercom Fin’s outcome limit stops live conversations.
Off switches block sign-ins, pause gateways or cancel one task. Only two controls stop work already running across a product, and neither is built as an emergency stop for all of a firm’s agents.
- Eight cross-vendor controls, in identity, security-posture and governance tools: Entra Agent ID, Okta, Purview, Credo AI, Check Point and ServiceNow AI Control Tower. From the unit-of-control coding.
Across vendors, a few tools can list and flag a firm’s agents, and one can block unapproved AI apps. None limits what agents from different vendors do together.
- Trading is the only comparison domain where we collected binding law. The EU AI Act’s stop button applies to high-risk systems from 2 December 2027.
What trading law requires, a kill switch, firm-wide limits, caps on each order and throttles, is optional or absent for agents, and no law requires any of it before December 2027.
SourcesPublic documentation of 46 agent products and protocols, read in October 2026, set beside trading, payments, cloud, email, IT change, industrial safety and ordinary business software.How we know
Local rules, fleet risk
The three ways risk adds up are this analysis’s reasoning, from how the documented controls work and from why trading law requires firm-wide controls. They are not a measured finding. The measured part is the chart below the illustration.Every agent can pass every rule while the firm as a whole runs over
Picture a firm of ten thousand people, each with an agent that can issue customer refunds. An administrator sets a sensible rule: no refund over $100 without a person’s approval. The rule is checked on every call, and it works. Every agent obeys it. Nothing in the rule asks how many refunds all the agents issued today, or whether they all started doing it at once.
That is the shape of a typical firm-wide rule: set once for the whole firm, then, in nearly two cases of three, checked one action, one agent or one user at a time. Risk that only exists in the total slips between the checks, in three ways.
Totals nobody limits
Each agent stays under its own cap for spend, refunds, emails or records touched. Nobody caps the sum. Trading firms must hold firm-wide limits for exactly this reason.
Many agents, one system
Hundreds of agents, each well-behaved, can lean on the same supplier, customer or internal system at once. Each check sees one request; none sees the crowd.
One weakness, everywhere at once
Agents share models, default settings and tool servers. A prompt attack or a bad default that works on one works on all of them, at the same moment. A per-agent check cannot tell a pattern from an accident.
Illustration, not data
Measured · The unit of control
Two coders from different model families coded 240 controls blind, plus 30 planted ones: kappa 0.72 on where the rule is set and 0.78 on what it counts; both found every planted fleet code. A third model settled the 71 disagreements and re-read all 148 controls first coded as firm-wide or cross-vendor, moving 17 out. Other shares rest on one coder. Documentation shows what is on offer, not what firms switch on; a firm can still add up exported logs itself.Agent controls look at one action, one agent or one user at a time; almost none limit what a firm’s agents do together
Where the rule is set
- Whole firm, in one product 35%
- Across vendors <1%
- One person, project or team 17%
- One agent, app or tool 33%
- Not stated 15%
What the check counts when it fires (1,061 controls that check, count or show something)
- Whole firm (total) 10%
- Whole firm (all at once) 2%
- Across vendors <1%
- One agent or user 8%
- One action 79%
What the 134 firm-wide controls do
- Limit what agents do in total <1%
- Detect risky behaviour 4%
- Switch a feature off for everyone 16%
- Meter the vendor’s bill 22%
- Keep records and dashboards 52%
- Other 4%
Of the 1,061 documented controls that check, count or show something, 134 look across the whole firm. Most of those keep records (70), meter the vendor’s bill (30) or switch a feature off for everyone (21). One limits what agents do in total. Two can stop work already running, each inside one product.
Where control ends · Personal AI
From vendor documentation of device, browser, sign-in, network and gateway controls, security-agency guidance and vendor surveys, checked quote by quote. Every “no” for a personal device is our inference: no stored page states it. No source we found measures personal accounts on personal devices.Every control stops where the firm stops owning things, so personal AI accounts and personal agents sit outside nearly all of them
A control is a protocol, and a firm can only enforce a protocol on infrastructure it runs: the laptop it issued, the browser it manages, the network its traffic crosses, the sign-in on its email domain, and its own business apps. On this analysis’s reading, the controls in this analysis work through one of those. Staff who use AI on their own phone, under their own subscription, step off nearly all of them at once. The firm can still write a rule, but almost nothing technical checks it.
Personal agents widen the gap. Run on a personal device, an agent an employee sets up on a personal subscription passes, on this analysis’s reading of the evidence, none of the firm’s device settings, managed browser, web gateway or AI gateway. The firm’s remaining grip, on this analysis’s reading, is the company apps and data the agent must reach to do company work, and only when it uses credentials the company issued. Work pasted by hand into a personal chat never touches a company app at all.
| Layer of control | Company device | Personal device, work sign-in | Personal device, personal account |
|---|---|---|---|
| Devicemanaged settings, endpoint data-loss rules | reaches: Yes, once the machine is enrolled | does not reach, inferred: No | does not reach, inferred: No |
| Browsermanaged profile or extension | reaches: Yes | partly reaches: Only if the browser is managed | does not reach, inferred: No |
| Sign-insingle sign-on, tenant rules, claiming accounts | reaches: Yes | partly reaches: Partly: claiming reaches any account on the company email domain | does not reach, inferred: No |
| Networkweb gateway, inline app controls | reaches: Yes, on the company network or with its client | does not reach, inferred: No | does not reach, inferred: No |
| Company appsAPI links, tool portals, conditional access | reaches: Yes | reaches: Yes | partly reaches, inferred: Only if the agent uses company credentials |
| Policy, training, lawrules of use, AI literacy | reaches: Yes | reaches: Yes | partly reaches: Yes, but nothing technical enforces it |
- reaches
- reaches only in part, or only on a condition
- does not reach
- inferred: no stored page states it
- Netskope cloud-security telemetry, October 2024 to October 2025, reported by Cybersecurity Dive in January 2026 (vendor data, via news): personal-account use fell from 78% to 47% of generative AI users, approved accounts rose from 25% to 62%. It counts only traffic that crosses a company control, so it says nothing about personal devices. Earlier vendor surveys (Microsoft and LinkedIn, 2024; Salesforce, 2023) predate agents.
Using a personal AI account for work is common, but in the traffic companies can see, its share is falling as firms hand out approved accounts. Use the company cannot see is not measured at all.
- Gartner survey via CXOToday, July 2025, sample size not given: 16% of organisations block public generative AI by default. Samsung’s 2023 ban covered “company-owned devices as well as internal networks” (Fox Business, relaying another outlet’s report of a Samsung representative; third-hand, 2023).
Few firms block outright, and the bans on record stopped at company devices and networks, the same edge every control has.
- Anthropic’s Claude Enterprise domain capture: “no non-Enterprise accounts can exist on your verified domain”. On Team plans admins can block new personal accounts but cannot claim existing ones. An account on a private email address is out of reach (our inference). ChatGPT and Gemini pages were not retrieved.
Reach over accounts follows the company email domain and the plan the firm buys. An account opened with a private email address is outside it.
- Anthropic documents that two Claude Code commands “enforce only forceLoginMethod, so they can mint a token in a different organization”, and that server-managed settings cannot redirect a developer’s first login.
Even on a managed machine, pinning a tool to the company account has documented holes.
- UK NCSC blog, 7 September 2026: shadow AI “is unlikely to disappear completely”, so “the goal should be to reduce risk”. Gartner’s analyst advice adds enterprise licences and internal chatbots. EU AI Act Article 4 (AI literacy) has applied since 2 February 2025; after the July 2026 amendment “no specific – or ‘sufficient’ - level is mandated”.
The UK’s cyber-security agency advises firms to reduce the risk rather than hope to ban it. Gartner adds offering a good approved tool, and data regulators add clear rules and training. The law adds a training duty, not new technical reach.
- From our corpus of job postings: about 19 of 31 duty statements that name a control for unapproved AI (discover, monitor, block, approve) sit in security roles. Before review corrections it was 22 of 34, from 14 employers, three of which supplied 10. Our search terms were security vocabulary, which builds in part of the result. Elsewhere the typical duty is simply to use approved tools.
Where firms hire for this, the job lands mostly with security teams; for everyone else it is a line in the job ad: use approved tools.
What this means for the fleet. The analysis’s interpretation, joining this section to the unit-of-control result above; not a separate measurement. A firm-wide total or an off switch can only count and stop the agents a firm can see. Personal agents are the uncounted part of the fleet. So the controls that matter most at fleet scale belong where most company work still has to pass: the company’s own apps, data and credentials. Work pasted by hand into a personal chat escapes even these.
Explore · What can you control?
High on what the documentation says. On 120 held-out controls and 24 planted ones, two coders from different model families agreed at kappa 0.86 (object), 0.87 (mechanism) and 0.87 (enforcement point). A spot check of 40 rows found all three codes right on 35. Documentation shows what products offer, not what firms switch on.Firms can control who an agent is, what it may use, what it spends and what it leaves on record; far fewer products control where it connects or whether it is right
Think of an agent as a new kind of worker that acts through software. The controls vendors offer answer familiar questions about any worker: who is this, what may it see, which tools may it pick up, how much may it spend, what record does it leave, and when must it ask someone. The basic answers are on offer in most products. Two questions are answered by far fewer vendors: which networks an agent may reach, and whether its answers are correct.
What to notice: the big circles sit in the tools, identity, usage and logs rows; the network and accuracy rows are thin.
Each row is what a control acts on; each column is where in the agent’s work it acts. A bigger circle means more products offer a control there. Select a cell to read real examples, or filter by how the control worksCircle size is the number of the 46 products (from 31 vendors) that document at least one control in the cell. Counted by vendor, network rules are the narrowest object (10 of 31) and answer accuracy next (12). Two AI coders from different model families sorted 662 controls into categories without seeing each other’s work. A third model merged the two sorts into 14 objects and 7 mechanisms; the enforcement points were fixed in advance. A separate clustering of all controls by meaning checked the result. Then two coders coded 144 controls not used to build the map, including 24 planted ones: agreement was kappa 0.86 to 0.87, and both found 96–100% of the planted codes. The other controls were coded once..
Scroll sideways for all eleven points.
Every documented control, placed so that similar ones sit together
What to notice: similar controls from different vendors land together, so each cluster is one kind of rule offered many times over. Each dot is one control. Controls with similar wording sit close together; colour shows the family of what they act on. Rings mark documented limits, where a vendor states what a control does not cover. The cell you select above lights up hereEach control’s name and codes were turned into a sentence embedding (all-mpnet-base-v2, run locally) and projected to two dimensions (UMAP). The labels name clusters found by HDBSCAN; the short names are ours. Position shows similarity of wording, not importance; the axes have no meaning..
Explainer · How agent controls differ
The codes are judgements from documentation, made by two coders and settled by a third. The two sides use different units: 83 control types in five kinds of enterprise software, and 14 categories of agent control.Ordinary software rules give the same answer every time; many agent rules sit around a system nobody wrote line by line, and some use a model’s judgement
A permission in an accounting system is arithmetic: the same request always gets the same answer, and you can test it. Agent controls are different in kind. They sit around a model whose behaviour was learned, not written, and some are models themselves, such as a filter that guesses whether a prompt is an attack and is sometimes wrong. That changes what a rule can promise. It also changes how rules are written: some are now plain sentences the agent is asked to follow.
What to notice: most small squares, ordinary software, are fixed rules; most large squares, agents, sit at the edge of the model rather than inside written code.
We put the same three questions to the controls firms already use on apps, ERP duties, software robots, APIs and feature releases, and to agent controls83 conventional control types from five kinds of enterprise software, and the 14 agent categories, each coded on where the control sits, how it decides and how far it reaches.. One small square is one ordinary control type; the larger squares are the agent categories.
| What differs | Conventional software controls | Controls on AI agents |
|---|---|---|
| Where the control sits Coded from documentation: 44 of 83 conventional control types sit inside written logic; 11 of 14 agent categories sit at the boundary. | Mostly inside written, testable logic: feature flags, ERP role checks, most robot controls. API gateways and firewalls are the exception. | Mostly at the boundary, around a model whose behaviour is not specified in code. Only logs, stored data and inventory sit inside. |
| How it decides 72 of 83 conventional types are coded deterministic. Agent detectors document their own error modes, such as fail-open behaviour. | Fixed rules: the same request always gets the same answer. The probabilistic ones, bot scores and content safety, are those AI protection borrowed. | Half the categories decide partly by classifier, with an error rate. Prompt-attack detection is probabilistic throughout. |
| How rules are written Plain-language rules appear across business agent platforms; we did not count them separately. | As structured policy: roles, conditions, schemas. | Also in plain language the model must follow. One business platform describes topic instructions phrased as “Always…”, “Never…”, “If x, then y…”; another’s example tells an agent to escalate refunds “over $100”Salesforce Agentforce; UiPath Agents.. |
| How far it reaches 79 of 83 conventional types reach company systems only. Agent reach is coded per category from documentation. | What the company owns or federates. Software robots are the exception: a robot’s credential carries it into systems the control plane does not govern. | Tool controls reach any system the agent’s identity can touch. Four categories reach into tools on staff machines, where managed settings are “a client-side control, not a security boundary”. |
| How it fails Each failure is stated in the vendor’s own documentation. | Vendors state the leaks: a web firewall inspects only the first 8 to 64 KB of a request body; distributed rate limits are not exact. | Detectors that fail open when unreachable; PII filters blind to tool-call arguments; cache hits that skip data-loss checks; allow rules void in bypass mode. |
| What one run is From how agent platforms describe runs and from the loop and iteration caps in the inventory. | Long-lived processes and accounts. A software robot is governed as an account. | A lasting design plus many short runs. Most loop and iteration caps end one run and reset; a few counters, such as spend caps and repeated-block limits, carry over. |
See how each agent category was coded, with its documented failures
Explore · Compared with other control systems
Each cell is a judgement: two coders agreed on 124 of 154 cells (kappa 0.69) and a third settled the rest. Comparison controls come from primary legal texts and official documentation, quoted and checked by script. Four cells rest on an Atlassian explainer or a third-party mirror of a NIST text.Agents borrowed the per-item controls of older systems, not the controls that watch the whole system
Every system that lets software or machines act for a firm has had to answer the same question: how do you stop it doing too much? Trading desks, payment networks, cloud accounts, email, IT change and industrial plants each have answers. Agents reuse many of them, especially on which tools may be used and who may access what. The answers they have not taken up are the ones that look across the whole system at once: the trading desk’s firm-wide limit, the payment network’s total exposure, the plant’s emergency stop for every line.
What to notice: the tools row finds a match in every domain; the stored-data and accuracy rows are mostly empty.
For each agent category and each domain, we looked for the closest control in that domain. A full circle means the same mechanism on an equivalent object; a half circle, a partial match; a small dot, nothing comparable. Select a cell to see the analogue.
Scroll sideways for all eleven domains.
Tools and actions have a counterpart in every domain. Stored data and answer accuracy mostly have noneTools and actions: an analogue in all 11 domains, 8 of them direct. Stored data: none in 9 of 11. Answer accuracy: none in 8.. Software robots and API gateways are closest to agent controls; industrial safety and IT change are furthest.
The other direction: controls other systems rely on that agents have no direct equivalent for
Most are product features elsewhere. The ones the law requires are all trading controls, because trading is the only comparison domain where we collected binding law61 controls in all have no direct agent equivalent; 13 of them are required by law. For the other domains we collected guidance, standards and product documentation.. One of them, a firm-wide risk limit, has no agent equivalent at all. Filter by what requires the control in its home domain.
Explore · How controls evolved, 2021–2026
Dates are first availability, from release notes, changelogs and dated documentation at 26 vendors. Archive captures give upper bounds, so the series can only move earlier. Before 2023 the record is thin, and the 2021 start is a Credo AI marketing page in the Internet Archive. The timeline has no events for ServiceNow, Workday, IBM or Gemini Enterprise. Announcements are not counted as availability, and availability is not adoption.In five years agent controls went from a lone content filter to a crowded menu, and the menu moved from words to actions
The first controls on AI models were filters on text: block this topic, catch that attack. As models became agents that use tools, the controls followed them into action: which tools, which identity, which approvals. New kinds of control kept arriving through 2025, then slowed in 2026.
What to notice: the curve steepens through 2023–2025 and flattens in 2026; switch to “Agent-scoped share” to see controls on actions pass half of new releases in 2025.
Each step up the curve is a vendor adding a new kind of controlA control type is one vendor offering controls on one thing at one level of sophistication, counted when it first became available. From 1 type in 2021 to 146 by the third quarter of 2026, across 26 vendors. Types grew 4.2 times in 2023, 2.9 times in 2024 and 1.8 times in 2025.. Switch between measures; hover or tap the chart to read a quarter.
See the quarterly numbers
Agent controls are following the path of APIs and cloud, where vendors lead, not that of water and industrial safety, where the law leads
Older control regimes show two paths. In APIs, cloud and networks, vendors shipped controls first and the law came later, if at all. In water and industrial safety, the law came first and set duties that products then met. Agents are on the first path and moving along it fast, likely in part because they reuse the identity, gateway and policy machinery the others built.
What to notice: the agent lane climbs steeply and has no law in force; water and industrial safety start with a law.
Each lane is one kind of control regime, drawn from its first sourced control. The line climbs through five stages: a fixed rule, a classifier, a rule that reads the context, a rule that knows who is acting, and a central rulebook checked on every action. Triangles mark laws. Counting shipped products, agents reached the top stage fastestAbout three years, against 6.6 for cloud and 18.8 for APIs. Counting standards too, APIs reached stage 5 in 3.7 years, with the XACML policy language in 2003, and several baselines are censored.. The reuse is visible: one cloud vendor’s agent policy engine runs on a policy language first built for APIsAWS AgentCore Policy uses Cedar..
See the timing table
| Regime | From | Stage 3 | Stage 4 | Stage 5 | First binding law |
|---|---|---|---|---|---|
| APIs | 1999 | +3.7 | +3.7 | +3.7 standard (XACML); +18.8 product (OPA) | +16.5, PSD2, sector-specific |
| Cloud | 2010, censored | +0.0 | +0.2 | +6.6 (service control policies) | +12.4, DORA, sector-specific |
| Network | 1989 | +14.0 | +14.0 | +31.4 standard (zero trust); no product row | +14.0, HIPAA, sector-specific |
| Industrial safety | 1989, censored | +2.7 | none | none | +0.0 |
| Water | 1974, censored | +24.6 | +24.6 | none | +0.0 |
| AI agents | 2022 | +0.3 | +1.8 | +3.2 preview; +3.6 generally available | None in force. General AI-literacy duty +2.5; Colorado reviewer duty +4.4; EU AI Act stop button for high-risk systems scheduled +5.3 |
Agents counted from the first primary-source control of any stage. Counted from the first stage-1 control instead, agents reach stage 3 before their baseline, because earlier static controls such as the 2020 OpenAI API limits are not in the record.
Blind spots
Absence rests on 2,046 documented controls, text searches of the inventory and 303 dated events. A control a vendor offers but does not document would be missed. “Announced work” means a dated event or documented control, not stated intent.The missing controls are fleet controls: stop every agent at once, cap what they do together, see them all in one place
Most agent controls govern one agent at a time. That is how a firm governs an employee, not how it governs a trading desk. When many agents act for a firm at once, the risks that matter add up across them. Trading answers this with controls over the whole system, set by law. Those are the controls agent products mostly lack, so we list them first. The item-level gaps follow: controls on single actions that other systems have and agents do not yet.
Within each group, gaps are ranked first by whether the control is required in its home domain, then by what goes wrong without it. Because trading is the only domain where we collected binding law, trading controls rank high by construction.
Fleet controls missing
One stop for every agent, including work already under way
Trading firms must be able to cancel “any or all of its unexecuted orders” at once. Agent off switches exist, but they stop new sign-ins, pause a gateway or cancel one task at a time. None documents cancelling actions already queued or running across all of a firm’s agents. The EU AI Act will require a “stop” button for high-risk systems from 2 December 2027.
Closest: Entra agent disable EG-173, EG-186; ServiceNow MCP pause EG-237, AH-066 (community page); MCP and A2A task cancel AH-427
A limit on what all of a firm’s agents can do in total
Spend caps meter what the vendor charges, not the value agents move. Payment-protocol budgets cover one person’s mandate. Many agents, each within its limits, can add up to an unbounded exposure. The one exception we found caps the number of conversations a support agent resolves, and doubles as a billing cap. Nothing caps the business value agents move together.
Closest: AH-405 (Intercom Fin outcome limit); CD-852, AH-524 (AP2)
One view of every agent, across vendors
Each vendor’s console sees that vendor’s agents. Eight documented controls reach across vendors, all in identity, security or governance tools: seven find, register or flag agents, and one blocks unapproved AI apps. None limits what agents from different vendors do together, and the agents staff bring themselves stay largely outside.
EG-190, EG-212, EG-215, EG-236, EG-274, EG-281, EG-060; block: EG-202. From the unit-of-control coding above
Seeing one weakness everywhere at once
Agents in one firm often share a model, default settings and tool servers. A prompt attack or a bad default that works on one will work on all of them at once. A check that judges each action alone cannot tell a firm-wide pattern from a single mistake. Six documented controls do watch behaviour across a firm’s agents, in identity-risk, security-monitoring and governance tools; none is documented as linking one failure that shows up across many agents. Trading’s equivalent is the repeated-error disable below, applied to the whole system.
Fleet-wide detection: EG-169, AH-156, EG-212, AH-062, EG-277, AH-172. The linking of failures across agents is this analysis’s reasoning, not a measured gap
Item-level gaps
A value cap on any action that moves money, outside payments
The new agent payment protocols cap one payment. No stored page documents a cap on a refund, order or transfer made through an ordinary tool call. Central policy engines could express one, but none documents it (our inference).
Closest: AH-523, AH-532 (AP2, ACP), BF-027; policy engines at AWS and Databricks
Two-person approval is rare, and some approvers are now models
Most approvals are a single click, often by the person who started the run145 controls in 26 products require a human.. A few business platforms offer multistage approvals, some mixing human and AI reviewers. Some coding and workflow products let a reviewer agent, an AI model or a stored past human decision approve instead of a person.
Multistage: Copilot Studio AH-136, ServiceNow EG-232, Entra EG-181. Model reviewers: Codex CD-731, ServiceNow EG-250, UiPath AH-285. Rests on an inventory search, not on the adjudicated mapping.
Guardrails independent of the agent, and settings only the firm can change
One major vendor documents its managed settings as “a client-side control, not a security boundary”, editable by a local administrator. 2026 brought checks that run on the vendor’s servers instead. None documents that the check shares no model, host or runtime with the agent it checks.
Closest: Anthropic CD-411, CD-682; BF-129, EG-021. Server-side events P-110, P-115 (Anthropic), P-085 (AWS), G-108 (Databricks)
A way to check and reverse what an agent did
Controls that spot a risky agent and stop it exist across identity, security and coding products. What is missing is a check on the business effects of completed actions, and a way back: one vendor says there is no undo for changes outside the editor, and rollback controls roll back agent versions, not what the agents did.
Detect and stop: Entra EG-169, EG-171; Agent 365 AH-171; Codex CD-719; ServiceNow EG-239. No reversal: Gemini Code Assist CD-1042; version rollback AH-235, BF-142
Segregation of duties across an agent’s tools
One security product detects one fixed risky combination: an agent that can read confidential data, take in untrusted content and communicate externally. No vendor offers a rule like “no agent may hold both create-vendor and approve-payment”.
Closest: Lakera EG-062
Limits on delegation across separate agents
Inside one product, subagents are controlled: which may run, how many, and what a delegated task may do. Across separate agents, the open protocols only authenticate each hop. Nothing limits how deep a chain goes, narrows scope as a task passes along, or ties a downstream action to the original person across more than one hop.
Subagents: Claude Code CD-302, CD-447; ServiceNow EG-255; Cursor CD-835. Across agents: A2A and MCP AH-485, AH-188, AH-190; Workday forbids proxy delegation AH-192
A repeated-error disable that only a person can lift
Trading systems must be “automatically disabled until re-enabled by a designated staff member” after repeated executions. Some agent counters persist, until the next billing period or the next month. None disables an agent after repeated errors until a named person turns it back on.
Persisting counters: Intercom AH-405; Claude Code CD-445, CD-027, CD-212. Per-run caps: AH-279, AH-435, BF-197
Accuracy, data-reach and stored-data controls spread slowly
Answer accuracy is documented by the fewest products. It and stored data had no new release event in 2026, and data reach never had more than three vendors in the timeline. Part of this is how we collected: the timeline misses several business platforms, and its collectors read security changelogs.
14 of 46 products document accuracy controls. Timeline has no events for ServiceNow, Workday, IBM or Gemini Enterprise. Most recent: P-066, AWS Automated Reasoning checks, August 2025
What the analysis suggests asking vendors
The analysis suggests that before scaling to thousands of agents, firms ask for controls over the fleet, not only over each agent
If vendors write the rules, buyers shape them by what they ask for. The analysis starts from trading’s list, because it was written for the same problem: software acting for a firm, fast and at scale. The first five questions are about the fleet, the next two about agents run outside the firm’s systems; the rest close gaps on single actions.
Ask for documentation, not a roadmap: an announcement is not a feature, and a feature in the documentation is not a feature switched on.
0 of 12 done
Your ticks stay in this browser only.
How we know
We read what vendors publish, as any buyer could; that shows what is on offer, not what firms switch on
We read the public documentation of agent products and listed every control it describes. That tells you what is on offer, not what firms actually use or how well it works. The numbers behind each finding are below.
We read public documentation only, with no sign-ins, and stored every page. Each control is one row with a verbatim quote of 40 words or fewer, checked by script against the stored page. The research plan, with its tests and limits, was written before any source was collected.
What these findings rest on
- Documentation shows what products offer, not what firms switch on or how well a control works.
- The snapshot is dated October 2026, and vendor documentation changes quickly. Some pages are gated or rendered by script; controls on pages we could not retrieve are missing.
- 63% of control rows (1,329 of 2,111) were coded by one coder. A spot check of 40 rows found all three codes right on 35; enforcement point is the weakest of the three.
- Several close agent analogues come from pages that are not product documentation: Credo AI marketing pages, ServiceNow community articles and Salesforce Trailhead modules. None of the ten largest gaps rests only on them.
- The timeline covers 26 vendors chosen in advance. Dense changelogs add more events, so we count control types, not events. 153 events state no release stage, so counts of general availability are a floor.
- Mappings to other domains and stage codes are judgements, reported with agreement statistics. Milestone sets in the older regimes are small and were picked by one collector.
- 95 of 370 product-by-object cells rest on one row, and 28 on a single row coded once.
- Three products rest wholly on pages that are not reference documentation: Salesforce Agentforce on Trailhead training modules (37 rows), ServiceNow AI Agents on community and store pages (35) and Credo AI on product pages (18). The explorers flag them.
- The timeline has no events for ServiceNow, Workday, IBM or Gemini Enterprise, so slow growth in autonomy, accuracy and data reach is partly how we collected.
- Trading is the only comparison domain where we collected binding law, so the law-required gaps are all trading controls by construction.
Where we departed from the plan
- The map was built on a balanced sample of 662 controls.
- 1,329 rows (63%) were coded by one coder, and the 120 held-out rows carry that coder’s code. Clear errors in a spot check: 4 of 24 single-coder rows.
- Determinism, position and reach were coded for the agent categories and the five enterprise-software domains, not for trading, payments, cloud, email, IT change or industrial safety. The planned determinism-by-reach map of all regimes was not drawn.
- Timeline events carry object and level codes but no mechanism or enforcement point.
- No agreement statistic is reported for the reverse list (32 of 83 candidate rows were on both coders’ lists). Two-person approval was never mapped; it rests on an inventory search.
- In the lineage, the first coder was the collector, not blind.
- Sample changes: Gemini Code Assist added; Lakera and the archived LLM Guard chosen for the security group; AWS split into three products.
- Level 4 is defined as “agent-aware” in the timeline and as “identity- or actor-aware” in the lineage.
- There is no fetch date per row; the snapshot is October 2026.
- Comparison sources are thin in places: no Visa or Mastercard documentation; industrial safety rests on one HSE bulletin; the NIST change-control text comes from a mirror; IT change from an Atlassian explainer.
- Three pairs of Internet Archive requests were sent less than five seconds apart, against the pacing rule.
Checks
- Two independent card sorts (agreement on objects: adjusted Rand index 0.59), merged by a third model; the merged objects match a data-driven clustering at least as well as either sort (NMI 0.60).
- Coder agreement on 120 held-out controls plus 24 planted ones: kappa 0.86 for objects, 0.87 for mechanisms, 0.87 for enforcement points; planted-code accuracy 96–100%.
- Spot check of 40 rows against the stored pages: all 40 quotes verbatim.
- Comparison mapping: 124 of 154 cells agreed (kappa 0.69), the rest settled by a fresh reviewer. Timeline coding: objects kappa 0.83, sophistication 0.66, availability 0.89. Lineage stages: kappa 0.88.
- A sensitivity series without archive and press dates moves no turning point by more than a quarter.
Sources quoted on this page
- Commission Delegated Regulation (EU) 2017/589 (RTS 6), kill functionality and repeated-execution throttle. SEC Rule 15c3-5. HSE safety bulletin CEMHD02-2023, quoting BS EN 61511.
- Claude Code, server-managed settings. Salesforce Trailhead, Agentforce guardrails and trust patterns. Microsoft Entra Agent ID best practices. Lakera agent risk assessment. Gemini Code Assist agent mode. NeMo Guardrails jailbreak protection.
- Every quote in the explorers comes from vendor documentation stored in the corpus; each row’s URL is in
inventory-all.csv.
The first report
Who owns the rules when agents join the business? Who edits, decides and oversees agent rules, from job postings, filings, practitioners and law.
The data
Fork it on GitHub: the plan, the control inventory, codes, mappings, timeline and scripts, under results/rerun-2026-10-10/controls-atlas/.
Talk to us about agent controls in your firm
Protocol Vision Advisory helps firms decide which agent controls to require and who owns them.