Does Your AI Agent Act as You or as Itself? 20 Products

When an AI agent reads your inbox, pushes to your repository or buys something on a website, whose identity does it present? There are two answers in the market. Either the agent gets a principal of its own, an account, an app identity, a workload identity, a bot user or a token issued to it, or it borrows yours: your OAuth grant, your session cookie, your API key. The two designs revoke differently, log differently and fail differently, and most product pages do not say which one you are getting.

This census answers that question for 20 agents and platforms from Google, Microsoft, AWS, OpenAI, Anthropic, GitHub, Cloudflare, Slack and Cursor on those vendors' own documentation, and one more, Perplexity's Comet, on a federal appellate opinion. The seed was Google's CC, which on September 17, 2026 became an agent for families running under its own verified Google Account; it is the clearest example of the own-account pattern and a useful contrast with the assistants most people already use. Eleven rows act as themselves. Nine act as you. This blog runs on Anthropic's models, and Anthropic's products appear as rows on the same terms as everyone else's.

Sort the 20 rows by identity and a pattern falls out. The platforms that host agents for enterprises give the agent a principal, among them Google Cloud's Agent Identity, Microsoft's Entra Agent ID and the agent user account that hangs off it, AWS's AgentCore workload identity, GitHub's Copilot cloud agent, Cloudflare's scoped tokens, Slack's bot users, OpenAI's Codex service accounts, and Google's CC. The assistants people use at a desk act on the person's own credentials: ChatGPT's apps and agent mode, Claude's connectors, Claude Code and Claude in Chrome, the interactive Codex cloud, Cursor's cloud agents, Workspace Gemini and Perplexity's Comet.

Two consequences follow, and both are stated by the vendors rather than inferred by us. First, a borrowed login inherits the person's whole reach and outlives the task: OpenAI's help centre says app permissions do not grant an app new access, because the reach was set when the person connected the app, and that agent-mode cookies persist across sessions like a normal browser. Nothing in the agent layer narrows it, and the way to revoke it is the person's way. That is the shape of the incident we covered in our post on a hijacked assistant login. Second, an own-account agent can be scoped and revoked on its own, but the binding is work: Google's documentation warns that deleting an agent does not remove the IAM bindings that reference it and that a redeployed agent gets a new principal, so governance moves from the person's account to a lifecycle the organisation now has to run.

"Its own" means the vendor describes a distinct principal for the agent. "The user's" means the agent presents a credential that belongs to a person. A row marked "undated" rests on a living documentation page that prints no date, so the row states the design and nothing that could have changed: no version, price, count or rollout state. The Cloudflare and Google CC rows and the court row are dated documents.

The same 20 rows in the same order, this time on the questions an IT lead asks before connecting anything: how a member or admin narrows what the agent can reach, and what revoking it actually involves.

Google Labs' announcement of September 17 describes CC, a family agent for households of up to six people, and its design is the cleanest example of the first pattern. CC has its own verified Google Account, which is how it appears when it interacts with the group. It runs on its own isolated cloud computer, on Google's Antigravity harness with Gemini models. And it does not get the household's data by default: each member decides what to share, by auto-copying chosen senders, sending things one at a time, sharing particular Drive files or adding CC to a calendar. It is US-only, for adults with personal accounts, on a waitlist.

Three design choices are worth copying whatever platform you use. The agent has a name of its own on every message, so attribution is never in doubt. The agent's reach is the sum of explicit shares rather than the sum of a person's permissions. And the agent runs somewhere the person's browser and session cannot leak into. Compare that with an assistant that logs into your mailbox as you: it can see everything you can, it acts under your name, and the only way to stop it is to change your own password or disconnect it. Our post on who saves each part of a managed agent's task covers the runtime side of that separation.

Neither pattern is safe or unsafe on its own, and this census ranks nothing. The right question is what the agent needs to reach, and which rows above show a design that fits.

Cloudflare's September 15 change, which lets an account issue a token scoped to specified Workers with one of four roles, is the newest example of the third case, and its August 5 essay on agent access puts the principle in one line: "A boundary you can talk your way past is not a boundary." The credential side of running that lifecycle is in our agent identity playbook; what people are willing to grant agents, by survey, is in our access-permissions statistics post; and the evidence an agent should leave behind under either pattern is the subject of our post on the Proof-of-Control draft. If you are deciding which agents to connect to company accounts, our AI transformation service starts with exactly this table for your stack.