Who your agent logs in as

Last week I wrote two thousand words arguing that AI-native is a metering decision. The idea was that a pricing page is harder to fake than a keynote, so whatever a company charges for tells you what it actually thinks the unit of work is. I had a lovely worked example in Paper and Figma, two design tools that spent the year arguing about whether a canvas needs to be legible to a model. I was quite pleased with the opening, too: an independent Braintrust eval in July found that the tool built out of HTML, specifically so models could read it, produced more generic markup than the one drawing its canvas on a GPU. Paper's output was 46% <div>s to Figma's 35%.

Then I read 39 priced AI products from 19 vendors, and the whole thing fell over in about two hours.

Two things did it. GitHub's cloud coding agent runs on its own, unsupervised, for minutes at a stretch, and every one of those sessions bills out of a named human's seat allowance. So by my own test, the most widely deployed autonomous agent in the world came out as a copilot. Then there was Atlassian, which ships a full per-credit meter for Rovo, down to "10 credits per request to Rovo Agents," and also says in its own documentation that "Atlassian is not currently billing for extra usage above your Rovo credit allowance."

A meter nobody gets invoiced on is telemetry with a price drawn on it.

So that essay is dead. This one is narrower, better sourced, and a lot more useful if you work in a German company.

Of the 39 products I catalogued, 14 charge a seat plus a credit, 10 are pure consumption, 9 are seat-only, 5 charge per outcome, and one I could not classify from public pages at all. Looks like a spectrum. It stops looking like one as soon as you read how the credits are actually handed out.

Reading 39 pricing pages back to back is not something I would recommend doing in one sitting, incidentally. A few of them bury the number you want in a footnote under a comparison table, and two I could only get out of a PDF rate card. This is apparently fine with everyone.

Atlassian's Rovo allowances "are pooled at the organization level, so allowances scale with your seat count and editions." Figma's AI credits are "assigned to an individual user," reset monthly, and "can't be shared or transferred to other users." Zendesk's AI agents hold no seat at all, and yet the resolution allowance they draw from is sized by how many human agents you license.

This is not consumption pricing competing with seat pricing. It is consumption denominated in seats. The meter counts machine work and then bills it against a headcount, which means the number deciding how much agent capacity you get is still the number of people you employ.

So sorting vendors by pricing model tells you almost nothing. One question does sort them.

Across the 39 products: 18 let an agent consume the meter with no named human seat attached to the transaction, 11 do not, 9 are partial, and one I could not pin down. The vendors are not converging on an answer. They have picked opposite ones and written them into their own documentation.

Microsoft's answer is that the agent acts as a person. For employee-facing Copilot Studio scenarios, agent usage sits inside the Microsoft 365 Copilot licence when the user is licensed "and the agent operates using the authenticated Microsoft 365 Copilot USL user's identity." Agent 365, the governance layer above it, is "licensed per user." The FAQ says flatly that "Agents do not require their own licenses." And there is no unlicensed path around it: delegate your access to an on-behalf-of agent and you need a licence, while an autonomous agent with its own access pulls one from "the owner, sponsor or the manager" instead.

The obvious workaround is narrower than it looks, though not as narrow as the first sentence you find suggests. Running an agent under one shared technical account can be multiplexing, which the Power Automate licensing FAQ scopes to "Power Apps, Power Automate, and Microsoft Copilot Studio" and defines as pooling connections or reducing "the number of users that directly access or use" those products. The language is blunt: "Using multiplexing as a mechanism to reduce the number of licenses to purchase is a license violation."

The very next question on that page softens it a lot. Microsoft explains how to run a flow under a service account compliantly, including putting a process licence on the flow, and notes along the way that "this is guidance only and not hard enforcement." The doctrine is aimed at humans hiding behind a technical account rather than at machines: a flow escapes it where "the users consume the data, rather than trigger the flow." Microsoft's multiplexing brief also says the construct "only applies to access-based licensing," which it frames as a benefit that metered and other non-user-aligned models offer.

Priced and narrow, then, rather than closed. Worth checking yourself before someone who read the first sentence and stopped tells you otherwise.

Atlassian went the other way. "A service account is an account that is not associated with a person," and "when you grant a service account access to Jira or Confluence, they do not count towards your user limit. This means we don't charge your Jira or Confluence subscription plan for service accounts." Cursor is blunter: service accounts "do not consume a seat license." Linear needs one line for it — "Agents are not counted as billable seats in Linear." Databricks puts a price on the distinction in its Genie cost docs: "The free usage applies to identified users, not Databricks service principals."

Same architecture, opposite invoice, depending on whose logo is on the tab.

The more useful pattern is that the big vendors ship both answers at once. Microsoft is a no on the Copilot seat and a no on Agent 365, and a yes on Copilot Studio, where an event-triggered agent draws from a tenant-wide credit pool. Google is a no on Workspace, where Gemini is folded into the per-user price with no meter exposed at all, and a yes on its Agent Platform, which bills vCPU-hours to a Cloud billing account with no seat anywhere in sight.

Then look at where each answer lives. Not one flagship application in my census is priced as pure consumption. The seat-free meter exists, and it sits in the builder platform, one layer underneath the product the business actually bought. Whether your agent needs a human licence comes down to which of those two layers your team happened to build on, which is not a decision anyone remembers making.

What convinced me the split is structural rather than commercial is that the identity layer forces it.

Microsoft's on-behalf-of flow, the mechanism by which software acts for a signed-in user, "only works for user principals." An agent running at three in the morning with nobody signed in cannot use it. It falls back to client credentials and authenticates as itself. The moment an agent runs with nobody attending it, it loses the ability to borrow a human identity, whatever the licence says.

That same fork sets what your audit trail is worth. Google's IAM guidance states the failure plainly: when a service account authenticates with a service account key, "there is no reliable way to tell who used the key." Impersonate the same account with user credentials instead and it logs the principal who did it. Microsoft's Entra Agent ID records agent activity "under the base identity type from where the activity originates," so finding it means filtering on an agentType property across three separate fields. One thing worth knowing before you promise anyone a clean report: those logs currently come out of Graph only on the /beta endpoint, which carries no compatibility guarantee, while the product itself is GA.

Microsoft documents both halves of this on a single page, and the gap between them is the whole essay.

On billing, an event trigger is machine work and gets charged as such: "a recurrence trigger set to activate every 10 minutes sends a trigger payload as a message to an agent every 10 minutes," and every one of those payloads is billable. On authentication, further down the same page: "Currently, event triggers can use only the agent author's credentials for authentication. As well, in order for the agent to run autonomously, all triggers and actions that require authentication must use the maker's credentials."

I read that page twice, because on a first pass it looks like an editing mistake. It is not. The invoice says a machine did it. The audit log says it was the person who built the thing, who was asleep at the time. Microsoft is straight about the consequence, warning that publishing such an agent "might allow users of an agent to use the agent to access data and systems using that same authorization," and it puts that warning in front of makers before they publish.

I have sat through a lot of agent demos. They have a rhythm: someone types a request in plain language, the thing goes away for a moment, it comes back with the work done, and the room makes an approving noise. I have never heard anyone ask whose credentials it just used, and for a long stretch I was not asking it either.

So the thing you get billed for and the thing that authenticates have come apart, and the audit trail follows the identity rather than the invoice. That gap is where this starts costing you.

Here is the part I did not see coming, and the reason the first essay went in the bin.

If you have ever taken an IT system to a Betriebsrat, you know how the meeting goes. They ask what it does. Then they ask what it records about whom. The second question is the one that decides your timeline, and agent platforms answer it badly.

German co-determination under § 87 Abs. 1 Nr. 6 BetrVG covers technical systems suited to monitoring employee behaviour or performance. Two features of the case law matter here.

First, intent is irrelevant. The Bundesarbeitsgericht put it this way in 1 ABR 7/15: systems are "bestimmt" for monitoring "wenn sie objektiv geeignet sind, Verhaltens- oder Leistungsinformationen über den Arbeitnehmer zu erheben und aufzuzeichnen; auf die subjektive Überwachungsabsicht des Arbeitgebers kommt es nicht an." Objective suitability settles it. Your assurance that nobody would dream of using agent logs in a performance review is not a defence, and the roadmap slide proposing a per-developer agent productivity dashboard is evidence for the other side.

Second, and this is the crux, the trigger is whether the data can be tied to individual employees. In that same decision the court found no co-determination on one limb precisely because a generic administrator account made it impossible to identify which employee had acted, even "unter Zuhilfenahme weiterer Erkenntnisquellen." Worth knowing that this was the lower court's binding finding of fact rather than a standard the BAG itself set, which limits how hard you can lean on it.

Now put that next to the licensing census.

A platform that logs every agent action against a named employee's identity is objectively suited to collecting behaviour and performance information about that person, which on this case law makes it co-determined in all but contrived cases. That is a duty to negotiate, not a prohibition, and it may belong to the Gesamtbetriebsrat or already sit inside a framework agreement on IT systems, which is where most of these conversations end up anyway. Microsoft's licence model pushes you straight there, and prices the shared-account alternative rather than forbidding it. Atlassian, Cursor and Linear push you the other way for free.

The maker-credentials case is worse. There, the person whose name ends up on months of overnight machine activity did not do the work, did not ask for it, and did not watch it happen. They built the agent once, some time back in March. If you set out to design a system that generates individually attributable performance data about an employee who is not performing, you would land on roughly this.

No court has ruled on that shape yet, and I think that is the whole point. Whether machine activity logged under a human credential counts as behaviour or performance information about that person is genuinely open. It will get settled on a fact pattern that nobody chose on purpose, assembled out of whichever vendor won whichever bake-off.

I want to be careful about the escape hatch in both directions, because it gets oversold both ways. Putting agents on service identities narrows the question without closing it: in a real stack your SIEM, your ticket queue and your approval UI will usually hand you a route back to whoever triggered the run. The 2024 headset case is instructive here, and not in the direction it usually gets quoted. The BAG did say that the bare theoretical chance a supervisor might work out who used which device does not suffice, so the bar is not metaphysical impossibility. But it still held the system co-determined, because the monitoring pressure existed even without the headsets being attributable to individual employees. Pooling the identity did not remove the right. It also found co-determination even though nothing was recorded or stored, so short retention will not save you either. The works council lost anyway, on competence: the rollout was company-wide, so the Gesamtbetriebsrat was the right body. Worth knowing before you negotiate with the wrong one.

Two dates for the plan. § 90 Abs. 1 Nr. 3 BetrVG has named artificial intelligence in the statutory text since 2021, and it bites at planning time, which means your agent architecture document is already the trigger. It carries information and consultation duties rather than an injunction, which is exactly why everyone skips it. And under § 80 Abs. 3 BetrVG, where the works council has to assess the introduction or use of AI, an expert counts as necessary — so the argument you used to win, about whether one is warranted at all, is gone. What is left is agreeing the person, the scope and the cost. Budget for that and negotiate the mandate early instead of treating it as an escalation.

I have to be exact here, because this is where the LinkedIn version of this argument goes wrong.

You cannot currently argue that agent mis-attribution breaches a deployer's obligations under the AI Act, because those obligations are not in force. The Digital Omnibus on AI, Regulation (EU) 2026/1744 of 8 July 2026, in force since 27 July, deferred Chapter III Sections 1 to 3, which is where Articles 12, 14, 19 and 26 all live, to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I. Article 26 binds nobody today.

It would not help you much when it does. Article 26(6) asks deployers to keep logs for at least six months "to the extent such logs are under their control," and says nothing about whether those logs name the right actor. The only place the Act requires logs to identify the natural persons involved is Article 12(3)(d), confined to remote biometric identification. Outside biometrics, the AI Act never tells you to record who did it.

What is in force is Article 50, since 2 August 2026, carrying a ceiling of €15 million or, if the offender is an undertaking, 3% of worldwide turnover, whichever is higher. For SMEs and start-ups that reverses to whichever is lower. The Commission's Article 50 guidelines, adopted 20 July 2026, go further than the Act on exactly this point. AI agents fall under Article 50(1) where they interact with people while carrying out tasks, and must be designed so that both their artificial nature and the person on whose behalf they act are disclosed, reasoning explicitly from "delegation of authority and accountability for the consequences of their actions." Article 50(1) binds providers, which you inherit the moment you put an agent into service under your own name. The guidelines also point, in a footnote and by way of example, at eIDAS electronic attestations and the EU Digital Identity Wallets, plus the still-proposed European Business Wallets, as one way of identifying an agent.

Those same guidelines state at paragraph 5 that they are non-binding, and that only the CJEU can interpret the Act authoritatively. Treat them as the enforcement posture of the AI Office, never as law. But read as a direction of travel, the Commission has described a target architecture in which an agent carries its own attested identity. Microsoft's current default is the opposite of that, and it is the default most German enterprises are standardising on.

This is just attended versus unattended, rediscovered. Largely, yes. UiPath was documenting attended licences per named user and unattended licences allocated to machines back in 2019, and RPA teams have priced unattended machine work for a decade. The distinction is old and I will concede it. What changed is who makes it. It used to be an explicit call by an automation team that knew it was choosing. Now it is a default buried in the licensing terms of general-purpose software your whole company already runs, and nobody gets asked.

The meter is a lagging indicator, so stop reading tea leaves in pricing pages. The history is against me and I should say so plainly. Adobe changed its meter early and deliberately, by its own account withholding new functionality from perpetual licences, then spent two fiscal years below its old revenue peak: $4.40bn in FY2012 down to $4.06bn in FY2013, not exceeded again until FY2015. Microsoft shipped its cloud seat meter more than four years after Google, still sells a perpetual Office LTSC in 2024, and is the largest cloud software company in the world. Twilio, Snowflake and Datadog never switched meters at all; they were born with them. And in the third quarter of its 2026 fiscal year Salesforce renamed the service offerings behind $39.4bn of annual subscription and support revenue to "Agentforce," while telling the SEC there were "no changes in the allocation of revenue between these service offerings as a result of this change." That is a rename, cleared by legal, shipped inside a quarter, and whatever runs underneath it did not move an inch.

Attaching an accountable human is a feature. For high-risk systems it becomes a legal requirement in December 2027: Article 26(2) requires deployers to assign human oversight to natural persons with the necessary competence, training, authority and support. So "the agent runs under a person's identity" is sometimes exactly what you want. None of this tells you which answer to pick. It tells you to go and find out which one you already bought.

Ask your vendors one question in the first call, before the demo starts: can an agent do work here without a named human licence attached to the transaction, and if it can, what does the audit log record as the actor? Every vendor in my census answers this somewhere in their public documentation. Almost none of them raise it unprompted.

Then ask it about your own platform. If everything runs under employee identities, you have a co-determination surface nobody has scoped and a licence bill that grows with headcount instead of automation. If it runs on service identities, you owe your works council a demonstration that no realistic join path back to a person survives anywhere in your estate, and that demonstration is an engineering commitment rather than a paragraph in an agreement.

Neither answer is wrong. Choosing by accident is.

Here is my falsifier, so you can hold me to it. If in two years the major platforms have shipped per-agent identities with their own attested authorisations and their own meters, and works councils wave agent logs through because the actor was never a person, then this was a transitional problem and I made too much of it. I do not think that is what happens, because Microsoft has a licensing doctrine to defend and it is the one that gets paid per head.

The operating side of running agents in a regulated environment, instrumenting the calls and governing what gets promoted from suggesting to doing, is in The AI-native Platform Playbook. The identity question comes before all of it, and unlike most of that, it costs you an afternoon.

Census compiled 24 August 2026 from vendor pricing pages, licensing guides and product documentation. Pricing moves monthly; re-check before quoting.