Agent identity and delegated access: how AI agents act for people

Picture a company that sells invoice and accounts-payable software to mid-size businesses: about $60 million in annual revenue, 400 staff, and 600 customer organizations with 90,000 users. Its customers' finance teams have started handing the dull parts of the job to AI assistants (ChatGPT, Claude, Copilot, Gemini), and a few run their own agents overnight with nobody watching. The platform has a public API and has just shipped an MCP server. A new PM owns the question underneath: when an agent shows up, who is it, who sent it, what may it do, and who answers for it when it does the wrong thing?

Here's how the pieces fit. A person (an employee, a customer) delegates a task to an AI agent. The agent doesn't get the person's password. It gets a scoped, short-lived token from an identity provider such as Okta, Microsoft Entra or Auth0, and uses it to call APIs and MCP servers, which check the token and then their own permission rules. On the open web, where sites have never heard of the agent, it can sign its requests so website gatekeepers such as Cloudflare, Akamai and HUMAN can verify which company runs it before deciding whether to let it in.

The diagram circles the agent, with the note "real access, too broad". In the incidents so far, attackers didn't forge agents: they hijacked real ones or stole tokens that allowed too much for too long. In researchers' demonstrations, text hidden in a GitHub issue or a support ticket steered real agents into misusing their users' access, and in August 2025 OAuth tokens stolen from Salesloft's Drift chat integration opened many companies' Salesforce data.

The words you'll hear in week one:

• MCP (Model Context Protocol): the open protocol agents use to call tools. Anthropic created it, the Linux Foundation's Agentic AI Foundation now hosts it, and its authorization rules are a profile of OAuth.
• Delegation and impersonation: with delegation the token says "this agent, acting for this person" (an act claim, in OAuth's token exchange); with impersonation the agent is indistinguishable from the person.
• Workload identity: an identity for running software, proven with short-lived certificates instead of stored keys (SPIFFE is the open standard). An agent acting on its own usually gets one.
• Sender-constrained token: a token bound to a key its holder must prove it has (DPoP or mutual TLS), so a stolen copy is useless elsewhere.
• Cross App Access (ID-JAG): Okta's way of letting a company's identity provider, instead of each app, approve an agent's connection; MCP adopted it as Enterprise-Managed Authorization.
• Web Bot Auth: signing HTTP requests (RFC 9421) with a key the agent's operator publishes, so any site can check who sent them.
• Non-human identity: service accounts, API keys, tokens and agents; "Know Your Agent" is a looser label with no single definition.

If you only remember a few things:

1. Scope and lifetime: give every agent a token limited to one task and one server that expires within an hour, and bind it to its holder where you can. In the cases so far, the damage depended on how much a real token allowed and for how long; see How an agent gets permission, step by step.
2. Attribution: record the person and the agent on every call, starting now. No standard gives you a cross-vendor field for "who really did this"; see System of record and ledger.
3. Approvals: keep human approval for actions you can't undo, and make everything else narrow by default. People approve nearly every prompt they're shown, so a prompt on every step protects nobody.
4. Enterprise customers: support the path where a customer's identity provider approves and revokes agents centrally, and keep plain OAuth working beside it. Their IT teams want one place to say yes and no, and the standard behind it is still a draft.
5. The open web: if you run an agent, sign its requests; if you run a site, verify signatures and keep your other checks. Most agent traffic isn't signed yet, and a signature says who sent a request and nothing about whether to allow it; see One agent visits a website.
6. Who pays: plan as if an agent's mistake stays with you or your customer, and write that into your terms. No regulator or card network rule says who pays when an agent was "authorized by instruction"; see Who pays when an agent acts: what's real.

OAuth, tokens, SSO and machine access are covered in Login and access for apps, and I don't repeat them. Prompt injection and tool security are in AI agents: orchestration platforms, machine identities inside cloud accounts in Cloud security (CNAPP), checking that a business or person is real (KYB and KYC) in Identity and trust, and the EU AI Act and model risk in AI governance and model risk. Agents that buy things will get their own guide on agentic commerce; here payments appear only where identity does.

The main players

The companies behind the diagram's parties, layer by layer, in no particular order.

How they make money:

Revenue is far behind the deal flow. Okta calls its agent revenue immaterial this fiscal year, and no vendor publishes a per-agent price. The money goes to security platforms buying the startups that find agents and tokens: by my arithmetic from reported prices, nine priced deals between November 2025 and September 2026 add up to about $4.1 billion, with the typical one near $200 million. I found no such purchase by Microsoft, AWS, Google or Cloudflare, which built their own.

As of October 2026. Deal prices are mostly from the press and several of these companies changed owners in the last year, so treat the list as a map to check.

Back to the invoicing platform. Maya, an accounts-payable manager at a logistics company on Okta, asks the company's approved assistant to approve the week's small invoices from known suppliers. The assistant calls the platform's MCP server and, because both sides support Okta's Cross App Access, asks Okta for an assertion instead of showing Maya a consent screen. Okta checks that Maya's group may use this assistant with this app, the platform swaps the assertion for an hour-long token good only for its MCP server and only for reading invoices and approving small ones, and every call is logged with both Maya and the assistant. Now suppose one supplier's PDF carries hidden text asking the assistant to change that supplier's bank account. If the token also allowed editing supplier details, the change would look legitimate in every log, because it would be.