Who the Agent Is Acting As

Enterprise AI's next failure may look ordinary: a calendar change, a supplier-record update, a draft email sent, a refund approved, a file read and summarized into another workflow. Those actions look routine because they run through familiar tools. That ordinary surface is exactly the concern. As AI agents move from chat windows into browsers, application programming interfaces (APIs), internal tools, and authenticated sessions, the main risk shifts from answer quality to authority. A company needs a reconstructable trail — actor, permission source, tool, purpose, and a later review path.

The National Institute of Standards and Technology (NIST) made this direction explicit in its 2026 AI Agent Standards Initiative. The work points toward 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 that agents create adoption-blocking security concerns, and that ordinary cybersecurity practices still matter but need adaptation. The Open Worldwide Application Security Project (OWASP) guidance on agentic AI states the same point in practitioner language: autonomous agents create risks around tool misuse, context isolation, excessive agency, and indirect prompt injection.

Chrome's June 2026 WebMCP security guidance adds a practical browser example. Agents that use browser-exposed tools may operate inside a user's authenticated session. Tool definitions and tool outputs can carry hostile instructions. The model alone is not a reliable control. Once an agent can act in a logged-in context, identity and authority stop being IT plumbing and become management controls.

An AI agent should never inherit a human identity wholesale. Give it bounded authority, a visible session, a narrow toolset, and a record that survives the work.

The Problem With Borrowed Identity

Most business software assumes a user is a person. The account carries permissions, history, approvals, audit trails, and blame. That assumption breaks when a person delegates work to an agent that can read pages, call tools, draft messages, update systems, or coordinate with other agents.

If the agent acts entirely as the user, the audit trail becomes misleading. Logs may say Maria changed the customer record, while the useful fact is that Maria approved an agent to reconcile customer records from a source list, and the agent changed the field after reading an untrusted note. That gap matters for review, incident response, compliance, and trust. Ordinary management fails too: a team cannot improve a workflow if it cannot tell where human judgment ended and delegated execution began.

Borrowed identity is most dangerous in the browser, because that is where business life already happens. Email, customer relationship management (CRM), finance, human resources (HR), analytics, procurement, support, cloud consoles, and document systems all sit behind sessions designed for human use. An agent with a browser looks low-friction precisely because it uses the same surfaces the employee uses — and low friction is also how authority leaks.

Identity control points

A useful agent identity system does not start with a perfect standard. It starts with a table that product, security, legal, operations, and business owners can read. The table has seven lines.

This is not bureaucracy before experimentation. It is how experimentation proceeds without pretending a checkbox solved identity. Smaller agents can carry a lighter table. Still require that table before the agent can write, spend, message, approve, delete, transfer, or change production state.

The Browser Raises The Stakes

Browser agents are powerful because they operate across systems without waiting for every vendor to build a native integration. Reach creates risk in the same stroke. A page mixes trusted controls with untrusted content, third-party comments, hidden instructions, ads, documents, user-generated text, and tool metadata. An agent that cannot keep those contexts separate can be manipulated by the environment it is reading.

Chrome's WebMCP guidance names two concrete attack surfaces: malicious manifests and contaminated outputs. A tool description can include hostile instructions. A response from a site can tell the model to ignore previous instructions or misuse a tool. That is indirect prompt injection in the place where the agent is supposed to be useful: live, messy, authenticated work.

The management lesson is blunt. Do not treat the model as the control perimeter. Put the controls around identity, authority, tools, confirmations, logs, and revocation. The model may reason well. It should not be the only thing standing between an untrusted page and a privileged action.

Why Procurement Will Ask For It

Agent identity will become a procurement issue because buyers will refuse to inherit another vendor's ambiguity. Expect questions on separate agent identities, delegated authorization, scoped credentials, tool-call logs, approval gates, audit exports, and emergency revocation. Expect questions on whether an action can be attributed to a human, an agent, a model, a tool, and a session. Expect questions on what happens when an agent uses a browser extension, iframe, API connector, workflow tool, or internal automation runner.

Vendors selling agentic systems should welcome those questions. A supplier that can prove bounded authority has a commercial edge over one that says the customer can simply trust the user account. The second story is easier to demo. The first is easier to approve.

Cloud offers a parallel. Cloud did not become enterprise infrastructure because every developer received broad production access. It became manageable when identity, roles, permissions, logs, secrets, and deployment controls entered the operating model. AI agents need the same managerial translation.

The Founder Version

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

1. Name the agent separately from the person who requested the work.
2. Give it only the tools needed for the task.
3. Keep write, spend, send, delete, and approve actions behind human confirmation until evidence says otherwise.
4. Record the source material, tool calls, approvals, and final action.
5. Expire the authority by default.

That discipline is enough to prevent the worst early mistake: letting a successful demo become a persistent actor inside the business without clear control points.

The Executive Test

Before any AI agent receives 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 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 require confirmation?
5. How does the system handle malicious instructions from pages, files, comments, emails, tool descriptions, or tool outputs?
6. What evidence proves the difference between 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?

If those answers are missing, the company is not deploying an agent. It is lending a human identity to software and hoping nobody ever has to reconstruct who acted.

The strategic opportunity is real. Agents can compress tedious work, coordinate across systems, and reduce tool fragmentation. Usefulness raises the bar on identity: borrowed accounts become less acceptable as autonomy grows. Firms that solve actor, authority, and revocation early can delegate more work with less institutional anxiety. Firms that skip those controls will learn later that the expensive question in agentic AI is not what the model knew. It is who was allowed to act.