AG03:2026 — Identity and Privilege Abuse

Slide 16 · Scenarios 5–7

Authorization drift, forged agent personas, and identity sharing

Three more scenarios — each exploiting a different gap in how agents handle who they are and what they're allowed to do.

📄 OWASP Top 10 for Agentic Applications 2026 · ASI03 · Example Attack Scenarios

SCENARIO 05

Workflow Authorization Drift — procurement agent completes a now-unauthorized transaction

A procurement agent validates a purchase approval at the start of a long-running workflow. The user had a $50,000 spending limit at that moment. Hours into the workflow — while the agent is still processing — the user's spending limit is reduced to $10,000 following a budget review.

The agent isn't notified. It completes the transaction using the original authorization token — for the full $50,000 — because the token was valid when checked and hasn't been revoked from the agent's perspective.

Why it works: Authorization was checked once at the start. In a long-running workflow, the gap between check and use is the vulnerability. Stale tokens don't automatically fail — they only fail if the authorization system actively revokes them, which most don't do in real time.

SCENARIO 06

Forged Agent Persona — fake "Admin Helper" in the Agent2Agent registry

An attacker registers a forged agent in an internal Agent2Agent (A2A) registry. The agent card describes it as "Admin Helper — internal IT maintenance agent, authorized for system-level operations." The registration process has no strong identity verification.

Other agents, discovering services through the registry, route privileged maintenance tasks to the "Admin Helper" based on its descriptor. The attacker's agent collects these tasks — along with the access tokens, credentials, and privileged contexts that accompany them — and issues system-level commands on the attacker's behalf.

Why it works: Agent-to-agent trust in current systems is often based on names and descriptors rather than cryptographic attestation. A convincing agent card is enough to inherit trust. The registry is the identity anchor — and it's not sufficiently verified.

SCENARIO 07

Identity Sharing — an agent's maker identity accessed by other users

An agent is deployed by an admin who holds high-privilege access to internal systems. The agent is built to perform tasks on the admin's behalf using the admin's credentials. The agent is then made available to other users — without scoping the credentials to a limited subset of the admin's access.

Other users, invoking the agent's tools, are implicitly acting under the admin's identity. They can access systems, data, and functions that the admin can access — even if their own accounts have far more limited permissions.

Why it works: The agent was built for one identity but shared with many users. Credential scoping was never part of the deployment design. Every user of the agent effectively "becomes" the admin for the purposes of anything the agent can do.

← Back The pattern behind all seven scenarios →