The UN's telecom agency, the ITU, launched a Focus Group on Agentic AI on July 9 in Geneva. Its brief is to build frameworks that keep AI agents identifiable, trustworthy, and under meaningful human control — and it names the specific fear out loud: agents impersonating people and taking unauthorized actions in financial transactions and critical infrastructure.

Do not over-read the timeline. A focus group is the slowest instrument in the standards toolbox: first meeting in Paris in November, a second in Geneva in January, then months of drafting technical reports. Whatever comes out of it is a 2027-or-later story. It will not bind you next quarter.

Read the direction instead. This is the first multilateral body to treat "which agent did this, and on whose authority" as a problem worth standardizing. And on that question, almost every agent in production today gives the wrong answer.

The uncomfortable default: your agents don't have identities#

Look at how a typical agent authenticates. It runs inside a human's session. It calls your database with the service key the whole app shares. It hits third-party APIs with a token minted for a person. When it does something — writes a row, sends an email, moves a dollar — every log line says the human did it.

That is not an identity. It's a borrowed one. And it fails the exact test the ITU is circling: when an agent takes a consequential action, can your system prove which agent, which instance, and acting for whom? For most stacks the honest answer is "a user did it," which is another way of saying you cannot tell your agent apart from the person it's impersonating — the precise thing the standard wants to make impossible.

An agent that authenticates as its operator hasn't been given trust. It's been given a disguise.

This isn't only a compliance problem waiting to arrive. It's an operational one you already have. When an agent loop misfires at 3 a.m. and drains a rate limit or fires a bad write, "a user did it" is the worst possible starting point for the incident.

What "agent identity" actually means#

Four properties, and you can adopt them incrementally:

  1. Its own credential. The agent presents an identity that is the agent's, not its operator's. At minimum a dedicated service account per agent; better, a distinct identity per agent instance.
  2. Scoped. That credential carries only the permissions the agent needs for its job — not the human's full grant. A support agent cannot reach billing; a billing agent cannot email customers.
  3. Short-lived. The credential expires on its own, in minutes, so a leaked token is a small window rather than a standing liability.
  4. Attributable. Every action lands in a signed, tamper-evident log that records which agent, which instance, and on whose behalf — so attribution survives a dispute.

What you can do this week — no standard required#

Stop sharing human keys. The cheapest, highest-leverage move: give each agent a dedicated service credential, scoped down, and never let an agent authenticate as a person. This alone changes your audit log from "a user" to "agent X."

Move to short-lived, cryptographic identity. This is what SPIFFE and SPIRE were built for. SPIRE issues each workload a short-lived SVID — a signed identity document, delivered as an X.509 cert or JWT, that expires in minutes. Your agent proves who it is on every call, and a stolen SVID is worthless almost immediately:

# A SPIFFE ID names the agent, not the machine or the human
spiffe://acme.internal/agent/support-triage/instance-9f3k

# SPIRE rotates its SVID automatically; the agent fetches a fresh one
$ spire-agent api fetch jwt \
    -audience billing-api \
    -spiffeID spiffe://acme.internal/agent/support-triage

Bind delegation explicitly. When an agent must act for a specific human, don't hand it the human's token — mint one that says so. OAuth 2.0 Token Exchange (RFC 8693) is the on-behalf-of flow for exactly this: the resulting token encodes agent X acting for user Y, scope Z, and it's revocable without touching the human's own credentials.

# On-behalf-of: exchange the user's context for an agent-scoped token
POST /oauth/token
  grant_type=urn:ietf:params:oauth:grant-type:token-exchange
  subject_token=<user_context>           # who we act for
  actor_token=<agent_service_credential> # who is acting
  scope=payments:create:single           # narrowed to the task

Sign the action log. Whatever the agent does, append it to a log you can prove wasn't edited after the fact. When the dispute comes — and with agents touching money, it will — attribution you can defend is the difference between an incident and a liability.

We've written the mechanics of each layer before: how to authenticate an agent's identity, and the cautionary tale of an agent issued an identity that proved it belonged to someone else.

The bet#

The ITU's spec is two years out. The China shutdowns on July 15 are two days out. The lesson connecting them is the same one that catches every team on the wrong side of a rule: the cost of identity isn't the standard — it's the retrofit. Teams that gave their agents real, scoped, revocable identities early will read the eventual framework as a checklist they've already passed. Teams that didn't will read it as a migration.

Give your agents their own names now. You'll want them long before Geneva does.