When an Agent Edits on Your Behalf, Who's Accountable?

A standard audit log makes one quiet assumption: one identity per action. One person clicked, at one time, and the row in the log names them. That assumption has held for decades because a human was always at the keyboard.

Now an agent runs the keyboard. It crops, reframes, transcodes, and captions thousands of assets on a user's behalf while you sleep, and the single-identity row no longer tells the truth. When a customer, a regulator, or your own incident review asks what happened to a given asset and who authorized it, you need to prove an answer for an actor that was never one person. Full disclosure: Layermetry is an SDK for AI media editing that sits at the tail of exactly this chain, so we will lay out both paths, building the audit layer yourself versus adopting one that emits it, and let you decide.

The actor is a delegation chain, not a single name

One edit, four parties, and nobody recorded the join

When an agent edits an asset, authorisation does not flow from one person. It flows from a user, to an orchestrator agent, to a tool-calling agent, to an SDK invocation, and back out. Four parties touched that one edit. The classic log has one column for "who," so it records whichever identity the system happened to attach, and the join between the human who authorized the work and the agent that performed it is lost.

That lost join is the whole problem. SentinelAgent, a 2026 research framework for securing multi-agent AI systems published on arXiv, names the gap directly: no existing framework can reconstruct "whose authorization chain led to this action" when Agent A delegates to Agent B, which invokes Tool C on behalf of User X. If you can reconstruct that chain, you can answer the accountability question cleanly, and that question is the one a customer, an auditor, or a regulator tends to ask first.

Delegation identity is its own subject, so this post links out for the depth

The engineering anchor for carrying that chain in 2026 is RFC 8693 OAuth 2.0 Token Exchange. It defines the act (actor) claim to "express that delegation has occurred and identify the acting party to whom authority has been delegated." The claim carries identity about the actor, and nested act claims represent prior actors in the chain. The standard treats nested actors as informational for access-control decisions. For an audit trail, those same nested actors are the mechanism that reconstructs who acted on whose behalf across every hop.

How you mint, verify, and enforce that delegation chain at the edit boundary is its own subject, and we cover it in depth in AI agent identity governance: verifying the delegation chain. This post takes the chain as given and focuses on the next question: once you have the identity, how do you record it so the record itself holds up.

What the record has to capture, at a glance

Six fields are mandatory, and three more make the record defensible

Three standards converge on one record

A defensible audit record for an agentic media operation draws from three sources at once. First, NIST SP 800-53 Rev 5 AU-3 mandates six elements per record: event type, when, where, the source, the outcome, and the identity of any individuals, subjects, or objects associated with the event. Second, the emerging OpenTelemetry (OTel) GenAI Semantic Conventions, in Development status as of May 2026, supply agent-native attributes such as gen_ai.agent.name, gen_ai.operation.name, gen_ai.tool.name, and gen_ai.request.model. Third, 2026 research frameworks, including the lifecycle-event model in arXiv 2601.20727 and AgentTrace (arXiv 2602.10133), establish that continuous structured trace capture is "a foundational layer for agent security, accountability, and real-time monitoring."

What a defensible record actually looks like

Here is the shape such a record would take, with each field mapped back to its source standard. This is a proposal for what a well-designed agentic media SDK should emit per operation, not a description of a shipped feature.

{
  "record_id": "rec_01j9x7kz3p8q4m5n6r7s8t9u",
  "prev_hash": "sha256:a3f2c1d9e8b7a6c5d4e3f2a1b0c9d8e7f6a5b4c3d2e1f0a9b8c7d6e5f4a3b2c1",
  "this_hash": "sha256:b4f3d2e1c0b9a8d7c6e5f4a3b2c1d0e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3",
  "event_type": "media.transcode",
  "timestamp": "2026-06-19T10:23:45.123Z",
  "service": "layermetry-media-sdk",
  "identity": {
    "sub": "user:dc@example.com",
    "act": {
      "sub": "agent:transcode-orchestrator-v2",
      "act": {
        "sub": "agent:tool-caller-v1"
      }
    }
  },
  "operation": {
    "op": "transcode_video",
    "input_ref": "s3://media-ingest/source/clip-4382.mp4",
    "output_ref": "s3://media-processed/clip-4382-720p.mp4",
    "parameters": {
      "output_format": "mp4",
      "resolution": "1280x720"
    }
  },
  "outcome": {
    "status": "success",
    "au3_event_type": "media-transcode-complete"
  },
  "telemetry": {
    "gen_ai_agent_name": "transcode-orchestrator-v2",
    "gen_ai_operation_name": "invoke_workflow",
    "gen_ai_tool_name": "transcode_video",
    "gen_ai_request_model": "frontier-llm-v1"
  },
  "provenance": {
    "c2pa_action": "c2pa.transcoded",
    "claim_generator_info": {
      "name": "layermetry-media-sdk",
      "version": "0.9.0"
    },
    "manifest_ref": "s3://media-manifests/clip-4382-720p.c2pa"
  }
}

The identity block carries both sub, the authorising user, and nested act claims, the acting agents in the delegation chain, per RFC 8693. The prev_hash and this_hash pair is the append-only chain discussed next. The telemetry block uses the emerging OTel GenAI Semantic Convention attribute names. The provenance block ties the record to the C2PA manifest using claim_generator_info, the current v2.4 field, not the deprecated v1 claim_generator.

Three independent layers make the log impossible to alter silently

One record is not enough, so you need defence in depth

A record with the right fields still answers nothing if someone can quietly rewrite it after the fact. Tamper-evidence is what turns a log into evidence, and it takes three independent mechanisms, each defeating a different adversary.

Layer one: hash chaining catches a silent edit

Each append-only record embeds the previous record's hash, so altering record N breaks every link in the sequence after it. The intent maps to NIST SP 800-53 Rev 5 AU-9(3), which requires cryptographic mechanisms to protect the integrity of audit information, a High-baseline control. AU-9(3) does not call out hash chaining by name. Hash chaining is the standard engineering practice that satisfies that integrity requirement.

Layer two: per-record signing catches a forged entry

NIST AU-10, Non-repudiation, High baseline, requires "irrefutable evidence that an individual or process acting on behalf of an individual has performed designated actions," implemented via digital signatures. Each record carries a signature binding it to a signing key, so a forged record cannot be minted without the private key. This layer pairs directly with the delegation identity in the act claim. The signature is evidence that the specific agent named in act.sub produced the record.

Layer three: WORM storage catches a deletion

Write-once-read-many storage closes the last gap. Object-lock storage in compliance mode means no user, including the root account, can delete a record before its retention period expires, and the period cannot be shortened. Legal hold extends the same protection with no expiry. Independent assessors have evaluated object-lock cloud storage against SEC Rule 17a-4, CFTC, and FINRA requirements, which makes it a regulator-grade pattern for audit log storage.

HASH-CHAINED APPEND-ONLY AUDIT LOG

Each record embeds the previous record's hash, is individually signed, and lives in WORM storage. Three independent layers, each defeating a different adversary.

Hardware WORM is optional, and retention is yours to set

Write-once hardware media, AU-9(1), exists in NIST SP 800-53 Rev 5 but is not part of any baseline, so cloud WORM via object lock covers the intent of AU-9 without on-premises hardware.

Retention is organisation-defined under NIST AU-11, with no universal minimum. EU AI Act Article 26(6) requires deployers of high-risk AI systems to retain logs for at least six months, and whether a media-editing SDK qualifies as high-risk depends on deployment context. A practical baseline is to align retention with your contract terms and applicable data-protection law.

The internal log and the content mark are two different jobs

Conflating them is where compliance gaps open

The internal audit log proves what the agent did and under whose authority. The C2PA manifest proves what the content is, and it travels with the asset. These are two distinct layers. Conflate them and you ship a compliance gap, because the regulator asking about a published deepfake is not asking to see your database.

Article 50 marking arrives on a hard date

EU AI Act Article 50 transparency obligations enter into force on 2 August 2026. Providers of AI systems that generate synthetic audio, image, video, or text must ensure outputs are "marked in a machine-readable format and detectable as artificially generated or manipulated." Article 50(2) carves out an exception where the system performs an assistive editing function and does not substantially alter the input data or its meaning, so whether a given editing operation triggers the marking duty depends on how much it changes the asset.

The Article 50 transparency obligations apply from 2 August 2026 under the Act itself, with no transition window in the Regulation's text for systems already on the market. A separate measure may shift one piece of that. The AI Omnibus, a provisional political agreement reached in May 2026 and not yet formally adopted, would give generative systems already on the market before 2 August 2026 until 2 December 2026 to meet the Article 50(2) machine-readable marking requirement specifically. The other Article 50 transparency duties still apply from 2 August 2026 either way. Treat the December date as provisional until the Omnibus is adopted, and plan against 2 August 2026 as the firm deadline. For wider context, see the 2026 state-of-the-art in AI media editing. For breaches of the transparency obligations, fines run up to EUR 15 million or, for an undertaking, 3% of total worldwide annual turnover, whichever is higher, under the Article 99 tier for these obligations. Breaches of the Act's prohibited practices sit in a higher tier.

The EU Code of Practice on AI-Generated Content, published in final form on 10 June 2026, separates provider obligations, machine-readable marks on outputs, from deployer obligations, visible disclosure of deepfakes and AI-generated text. The final Code does not name C2PA, the Coalition for Content Provenance and Authenticity, explicitly. The Code describes a sub-measure requiring digitally-signed, time-stamped metadata in a tamper-evident form, and analysts at IPTC read that description as effectively pointing to C2PA, since it is the technology that meets those criteria. The Code itself refers to mechanism categories rather than named standards.

How C2PA satisfies the mark

C2PA v2.4 defines a manifest containing a Claim, Assertions including the Actions assertion, Ingredients tracking upstream provenance, and a cryptographic Signature. The Actions assertion's digitalSourceType field identifies when an action was performed by an AI or machine-learning system, which is the marking that Article 50(2) calls for. A standard manifest requires a creation action (c2pa.created or c2pa.opened), and that action plus the signed claim_generator_info, the current v2.4 field where claim_generator is the deprecated v1 name, together form a machine-readable record that aligns with Article 50(2) marking. The spec and the Code describe mechanism categories rather than named standards, and C2PA fits those categories.

One trade-off that bites media pipelines specifically

C2PA hard binding uses SHA-256 over the file bytes, so any transcode or recompression breaks the binding. Soft binding via invisible watermarking or perceptual fingerprinting survives format conversion. Pipelines that need provenance to survive transcoding should plan for soft binding as the durability layer. For context on adoption, the first smartphone series to ship C2PA Content Credentials applies them to AI-edited images, a signal that the standard is reaching production beyond specialised toolchains.

Build the audit layer, or adopt one that emits it

Both paths are real, and the honest answer depends on what you are optimising for.

If you build it yourself, you own every line: the delegation-aware schema, the hash chain, the signing keys, the WORM lifecycle, and the C2PA manifest generation on every transcode. You get total control and no vendor dependency, which matters when audit is your differentiator or your compliance team needs to certify every component directly. The cost is that this is not a one-time build. Each new standard revision, each new model attribute in the OTel conventions, and each change to the delegation format is yours to track and re-certify, forever, while it sits well off the edge of what most teams ship as their actual product.

If you adopt an SDK that emits this record for you, you trade some control for speed and lower standing maintenance. The audit layer arrives wired into the editing operations, so the delegation identity, the chained and signed record, and the C2PA provenance tie are produced as a by-product of the edit rather than a project you staff. The cost is a dependency, and you should confirm the emitted record actually carries the fields your auditors will ask for before you rely on it. The August 2026 Article 50 deadline sharpens the question, because the content-marking layer becomes a legal requirement on a fixed date, and a retrofit under deadline pressure is the expensive way to arrive.

If you are building an agentic media pipeline today, the /docs reference covers how Layermetry surfaces these governance controls in the SDK, and the delegation-chain governance post covers the identity half in depth. Whichever path you pick, design the schema for a delegation chain from the start, because the one thing you cannot retrofit cheaply is the answer to "who authorized this."

FAQ

Who is the actor in an audit log entry when an autonomous agent edits a video?

The actor is the delegated agent identity, not the human alone. RFC 8693 defines the act (actor) claim to express that delegation has occurred and identify the acting party, so one log entry can carry both the authorising human, via sub, and the acting agent, via act.sub. Nested act claims record prior actors in the chain, which is exactly what reconstructs who acted on whose behalf.

Does the EU AI Act require me to log AI-generated media operations from 2 August 2026?

Article 50 requires that outputs be marked machine-readable and detectable as artificially generated or manipulated, not that you keep an internal audit log. Internal logging sits elsewhere. Article 26(6) requires deployers of high-risk AI systems to retain logs for at least six months. Article 50 also carves out an exception for assistive editing that does not substantially alter the input. Marking of AI-generated output is what Article 50 makes mandatory for generative systems from 2 August 2026.

How do I make agentic media audit logs tamper-evident?

Layer three independent mechanisms. Hash-chain each append-only record so altering one entry breaks every link after it, satisfying the cryptographic-integrity intent of NIST AU-9(3). Sign each record for non-repudiation per NIST AU-10. Then write records to WORM storage such as object-lock storage in compliance mode, which blocks deletion before retention expires.