Who the Agent Is Acting As

When enterprise AI next goes wrong, the failure may look ordinary: a calendar change, an updated supplier record, a draft email sent, a refund approved, a file read and summarized into another workflow. Each of these runs through tools people already use every day, which is what makes it hard to spot. As AI agents move out of chat windows and into browsers, application programming interfaces (APIs), internal tools and authenticated sessions, the main risk moves from the quality of the answer to the question of authority. A company needs to be able to reconstruct afterwards who acted, where the permission came from, which tool was used, for what purpose, and how the action can be reviewed.

The National Institute of Standards and Technology (NIST) set out this direction in its 2026 AI Agent Standards Initiative, which covers secure adoption, interoperability, agent authentication, identity infrastructure, and evaluations for human-agent and multi-agent interactions. A May 2026 analysis of responses on AI agent security found broad agreement on two points: agents raise security concerns serious enough to block adoption, and ordinary cybersecurity practice still applies but has to be adapted. The Open Worldwide Application Security Project (OWASP) guidance on agentic AI puts it in practitioner terms, listing tool misuse, failures of context isolation, excessive agency and indirect prompt injection among the risks autonomous agents create.

Chrome's June 2026 WebMCP security guidance gives a concrete browser case. Agents using tools exposed by the browser may be working inside a user's authenticated session, and both tool definitions and tool outputs can carry hostile instructions, so the model on its own cannot be relied on as a control. Once an agent can act while logged in, identity and authority have to be treated as management controls.

An AI agent should never inherit a human identity wholesale. It needs bounded authority, a visible session, a narrow set of tools, and a record that outlasts the task.

Agents acting under a person's account

Most business software assumes the user is a person. The account holds permissions, history, approvals and audit trails, and it tells you whom to hold responsible. That assumption fails when a person hands work to an agent that can read pages, call tools and update systems.

If the agent acts entirely as the user, the audit trail misleads. The log may say Maria changed the customer record, when what actually happened is that Maria approved an agent to reconcile customer records against a source list, and the agent changed the field after reading an untrusted note. Anyone doing a review, handling an incident or answering a compliance question needs the second version. So does anyone trying to improve the workflow, because a team cannot fix a process when it cannot tell where human judgment stopped and delegated execution started.

The risk is greatest in the browser, since that is where most business work already happens. Email, customer relationship management (CRM), finance, human resources (HR), procurement, cloud consoles and document systems all sit behind sessions built for people. A browser agent is easy to adopt because it uses the same screens the employee uses, and that same ease is how authority leaks out.

Identity control points

A workable agent identity system does not have to wait for a finished standard. It can begin as a table that product, security, legal, operations and business owners can all read, with seven lines.

The table lets teams experiment without pretending that a checkbox has dealt with identity. Smaller agents can carry a lighter version, but the table should exist before any agent is allowed to write, spend, send messages, approve, delete, transfer or change production state.

Browsers put agents in front of untrusted content

Browser agents are useful because they can work across systems without waiting for each vendor to build a native integration. The same reach is the source of the risk. A single page mixes trusted controls with third-party comments, hidden instructions, ads, user-generated text and tool metadata, and an agent that cannot keep those apart can be steered by whatever it happens to be reading.

Chrome's WebMCP guidance names two attack surfaces: malicious manifests and contaminated outputs. A tool description can contain hostile instructions, and a site's response can tell the model to ignore its previous instructions or misuse a tool. This is indirect prompt injection arriving in the live, authenticated work the agent was brought in to do.

So the model should not be treated as the control perimeter. The controls belong around identity, authority, tools, confirmations, logs and revocation. A model may reason well and still should not be the only thing between an untrusted page and a privileged action.

Buyers will ask for agent identity in procurement

Agent identity will turn into a procurement question because buyers will not want to take on a vendor's ambiguity. Expect questions about separate agent identities, delegated authorization, scoped credentials, tool-call logs, approval gates, audit exports and emergency revocation; about whether a given action can be attributed to a human, an agent, a model, a tool and a session; and about what happens when the agent works through a browser extension, iframe, API connector, workflow tool or internal automation runner.

Vendors of agentic systems have reason to welcome this. Telling the customer to trust the user account makes for an easy demo, and a supplier that can show bounded authority is the one more likely to get through the buyer's approval process.

Cloud offers a parallel. Giving every developer broad production access did not make it enterprise infrastructure; identity, roles, permissions, logs, secrets and deployment controls did, once they were built into how it was run. AI agents need the same translation into management terms.

A minimum rule for small companies

A small company does not need a standards department. It needs one rule: no agent goes into production without a named owner, scoped authority, visible logs and a kill switch. The first version can be written in plain language.

1. Name the agent separately from the person who asked for the work.
2. Give it only the tools the task needs.
3. Put write, spend, send, delete and approve actions behind human confirmation until there is evidence to relax that.
4. Record the source material, tool calls, approvals and final action.
5. Make the authority expire by default.

This is enough to stop the worst early mistake, in which a demo that worked quietly becomes a permanent actor inside the business with no clear control points.

Eight questions before an agent gets access

Before any AI agent is given access to a browser session, internal tool or production workflow, require eight answers.

1. What is the agent's separate identity in logs and user-facing records?
2. Who granted its authority, and for which business purpose?
3. Which data can it read, and which data is explicitly out of scope?
4. Which tools can it call, and which actions need confirmation?
5. How does the system handle malicious instructions in pages, files, comments, emails, tool descriptions or tool outputs?
6. What evidence separates human judgment, agent reasoning, tool execution and final approval?
7. When does the authority expire?
8. How can the company pause, revoke, investigate and repair after a bad action?

A company that cannot answer these is lending a human identity to software and hoping nobody ever has to work out who acted.

Agents can take over tedious work, coordinate across systems and reduce tool fragmentation. The more autonomy they get, the harder it is to accept them working under borrowed accounts.

Firms that settle actor, authority and revocation early will be able to delegate more work to agents. Those that skip the controls will find out what they lacked the first time they have to reconstruct a bad action from a log that names only the employee.