Your legal team flags an AI-edited image. The agent ran correctly, the OBO (on-behalf-of) token was valid, and the C2PA manifest is signed. The question on the table is simple. Which user authorized that agent to make that specific change? The answer sitting in your logs is a service account ID. That gap is the governance problem. AI agent identity governance is the discipline of ensuring every autonomous media edit carries a verifiable delegation chain from the authorizing user through the orchestrating agent to the signed asset. Layermetry is built to close it at the one place that matters: the edit boundary itself.
TL;DR
- When an agent edits media, identity is a delegation chain, not a login, and the chain has to be verifiable at every hop.
- C2PA records what transformation occurred and which signing key was used. It does not record who authorized the agent to act.
- The IETF OBO Internet-Draft (August 2025, an individual submission that expired February 2026) extends OAuth to carry the agent identity in the token, but it is not yet an adopted standard.
- EU AI Act Article 50 transparency obligations become enforceable August 2, 2026 and require machine-readable marking of AI-modified media.
- The only place to simultaneously verify the OBO token, write the C2PA action assertion, and emit an audit record is the SDK at the edit boundary.
When the editor is an agent, "who authorized this?" has no simple answer
A human edit has one author, an agent edit has a chain
A human edit has one obvious author: the person who clicked save. An agent edit has a chain. The user delegated to an orchestrating agent, which called a tool over a protocol like the Model Context Protocol (MCP), which applied the edit to the asset. Legal asks which user authorized a manipulated image, and the honest answer from many of today's implementations is "we logged the agent, not the delegation."
A national standards body has already named the gaps
The U.S. standards body NIST NCCoE made this precise in a concept paper on software and AI agent identity published February 5, 2026 (an initial public draft seeking comment, not a finalized standard). It asks for feedback on identification, authorization, auditing and non-repudiation of AI agents, and controls to prevent and mitigate prompt injection. A national standards body taking up these questions signals the problem is recognized at infrastructure scale. A separate 2025 scan of internet-exposed MCP servers found that close to 2,000 of them carried no authentication mechanism at all.
The argument here is not that the standards are broken. Each standard covers one slice of the chain, and none of them join at the place where the edit happens. Understanding how to enforce the identity-authorization-provenance chain is the subject of the governance controls.
Three standards cover one plane each, and none of them own the join
The governance problem resolves into three distinct questions, each with its own standards stack, and none of those stacks span all three.
Which agent is this? WIMSE (Workload Identity in Multi System Environments), the IETF-chartered working group, treats AI and ML intermediaries as a special case of delegated workloads that inherit the upstream principal's security context and are expected to operate within that delegation. Its architecture says an agent should propagate that context to downstream workloads unless it has been explicitly authorized to translate or reduce its scope, which keeps each hop from quietly widening its own privileges. A separate independent preprint from March 2026 called Agent Identity Protocol proposes single-hop signed JWTs and multi-hop Biscuit tokens with Datalog policies for finer-grained capability scoping.
On whose behalf? The IETF Internet-Draft from August 2025 (an individual submission that expired February 2026, not an adopted standard) adds requested_actor and actor_token parameters to the OAuth 2.0 authorization code flow. The issued access token carries an act claim with an act.sub field identifying the acting agent, so the token names both the user and the agent. A managed agent-runtime platform shipped OBO token exchange to general availability on April 30, 2026 across 14 regions, producing a scoped-down token that carries both the user identity and the agent identity and is targeted to the specific outbound resource.
What did the agent do to the content? C2PA (Coalition for Content Provenance and Authenticity) v2.4 records cryptographically signed action assertions and requires AI-disclosure marking. EU AI Act Article 50 requires machine-readable marking of AI-generated or manipulated media, enforceable from August 2026.
Every standard owns a column, the join is unowned
The diagram below maps these stacks to the edit pipeline. The structural point it carries is the one the prose can only state sequentially: every standard owns one column, and the edit stage where they must meet has no owner. Read the agent primitives spec to understand how these layers compose.
C2PA records what changed, not who ordered it
The manifest proves the transformation, not the authorization
C2PA removed the "actors" field entirely in version 2.0. Version 2.4, published April 2026, records action assertions describing what transformation occurred and identifies the signer through an X.509 certificate subject field. As the specification states: "only signed C2PA created_assertions are attributed to the signer." So a C2PA manifest can prove that an image was edited and which signing key sealed the manifest. It cannot tell you which user authorized the agent that performed the edit.
C2PA is necessary but not sufficient for the identity question
An independent security analysis (preprint, arxiv.org, April 2026) studied the C2PA v2.2 specification and a set of validator implementations and reported that the specifications do not yet meet their stated security goals, citing issues such as timestamp binding and inconsistent validator behavior across implementations. The point here is not that C2PA falls short. It is the best available media-provenance standard, and it is steadily improving. The point is that provenance and authorization answer different questions: C2PA records the transformation, and the "who ordered it" dimension needs a separate identity-layer binding, one that takes the act.sub claim from the OBO token and links it to the manifest before the edit lands.
Article 50 lands in August 2026, and it applies whether a human or an agent clicked go
Machine-readable marking becomes enforceable on a fixed date
EU AI Act Article 50 transparency obligations are enforceable from August 2, 2026. Article 50(2) requires AI systems generating synthetic audio, images, video, or text to mark outputs in a machine-readable, detectable format where technically feasible, with assistive functions that perform standard editing left out of scope. The EU Code of Practice on Transparency of AI-Generated Content was published June 10, 2026, and sets out practical marking and labelling steps, including treating content that has undergone genuine human review and editorial responsibility differently from fully automated output.
The text is silent on agents, but the direction is clear
Article 50 addresses disclosure to natural persons and is silent on autonomous agents. Legal analysts expect the scope to extend to agents modifying media regardless of whether a human initiated the request. That reading is not settled text, but the enforcement date is fixed and the direction is clear.
Marking alone is a weaker position than attested identity
Marking alone covers less ground than marking plus attested identity. An independent preprint (arxiv.org, March 2026) ran a simulated multi-agent routing experiment and found that self-claimed agent identity scored below random selection (0.55 versus 0.68 for random), while attested identity reached near-optimal performance (0.95). It is one simulation, not a universal law, but the direction is clear. For compliance, a machine-readable mark backed by a self-asserted agent claim is a weaker position than one backed by an OBO token verified before the edit was applied.
The delegation chain has to be enforced at the edit boundary
Three of the four stages have standards coverage, the edit stage has none
The chain for any agent-driven media edit runs: the user authorizes, the orchestrating agent acts, the SDK applies the edit, and the asset is signed. Three of those four stages now have standards coverage. The user-authorization layer has OBO tokens, the agent-identity layer has WIMSE scope propagation and the IETF draft's act.sub claim, and the asset layer has C2PA and Article 50 marking. The edit stage has none.
The SDK is the only component at the moment of the edit
The SDK applying the edit is the only component present at the exact moment the transformation is applied. That makes it the one place capable of doing all three actions in a single call: verify the inbound OBO token, confirming the act.sub claim and the scoped-down access token before allowing the edit; write the C2PA action assertion as the transformation occurs; and emit a structured audit record binding the user ID to the agent ID for non-repudiation. One call, one atomic record.
Each hop must re-verify scope, not inherit it
One concrete example makes the risk tangible. On a major agent-runtime platform, a request header that carries the end-user identifier (X-Amzn-Bedrock-AgentCore-Runtime-User-Id) is treated as an opaque value and is not verified against an authenticated end-user identity, which is precisely why re-verification at the edit boundary matters. That platform's own documentation recommends the JWT bearer path for production deployments, because it validates the token's issuer, signature, and expiry. The WIMSE principle applies here: each hop should re-verify its scope rather than inherit it from the previous hop's header.
One atomic call instead of a three-stage integration
This is the problem Layermetry solves. Layermetry is an SDK for AI media editing built agent-first, with the entire governance sequence collapsed into a single agent-facing call at the edit boundary: the agent presents its OBO token, the edit is applied only after the token verifies and the act.sub claim resolves to the authorizing user, the C2PA action assertion is written as part of the same atomic operation, and the audit record is emitted before the response returns. There is no three-stage integration to wire together. The delegation chain does not break at the edit boundary, because that boundary is where Layermetry enforces it.
FAQ
Does C2PA track who instructed an AI agent to edit an image, or only what was changed?
C2PA v2.4 records action assertions (what transformation occurred) and identifies the signer through an X.509 certificate subject field. It removed the "actors" field entirely in version 2.0. So a C2PA manifest can prove that an image was edited and which key signed the manifest, but the human or agent who initiated the edit is not part of the signed provenance. Binding that authorization needs a separate identity layer.
What is OAuth on-behalf-of (OBO), and how does it apply to AI agents editing media?
OBO token exchange builds on RFC 8693. An IETF Internet-Draft from August 2025 (an individual submission that expired in February 2026, not an adopted standard) adds requested_actor and actor_token parameters so the issued access token carries an act claim identifying the acting agent. The result is a token that names both the user and the agent, so an agent's media edit can be traced to the authorizing user without a fresh consent prompt.
When does EU AI Act Article 50 apply to AI agents that modify media on a user's behalf?
Article 50 transparency obligations are enforceable from August 2, 2026, and require AI-generated or manipulated audio, image, video, and text to be marked in a machine-readable, detectable format where technically feasible. Article 50 addresses disclosure to natural persons and is silent on autonomous agents, so legal analysts expect, rather than confirm, that the scope extends to agents modifying media regardless of whether a human initiated the request.
The standards landscape for agent identity governance has split into three planes, each well-specified in isolation, each missing the join. The only architecture that survives the legal question is one that treats identity as a delegation chain and enforces the chain where the edit happens. Token verification, provenance signing, and audit emission have to occur as one atomic event, at the SDK boundary, or the chain is advisory rather than verifiable. If you are building or operating an AI media editing pipeline, you can wire on-behalf-of verification, C2PA assertion writing, and audit emission yourself across three components, but each hop becomes a separate integration surface to maintain. The Layermetry docs walk through how the delegation chain composes in practice as a lower-maintenance alternative.