You connect an AI agent to your product so it can edit media for your users. Crop a hero image, retouch a headshot, reframe a launch video, swap a caption. Then a quieter question shows up, usually from someone in security. When that agent acts, what can it actually touch, on whose behalf, and what stops it from touching the rest? A common first answer is to hand the agent an API key and rely on the prompt to keep it in bounds. That is the same as giving a contractor the master key to the whole building because they need to fix one door.
This post is about how to bound an agent properly: least privilege, scoping by operation and by asset, on-behalf-of delegation, and the brand-safety guardrails that keep an automated edit from becoming a brand incident. Full disclosure: Layermetry is one of the off-the-shelf layers that enforces this at the edit boundary, so we will lay out both paths, building the boundary yourself and adopting one, and let you decide.
The default is a master key, and that is the whole problem
Tool access, not the prompt, sets what an agent can reach
An agent is a language model that has been given hands: tools it can call to take real actions in your system. The model decides what to do, and the tools are how it does it. The trouble is that a model is non-deterministic. It will sometimes take a broader action than you intended because it decided that was the best way to finish the job. The security community has a name for this. OWASP lists Excessive Agency as risk LLM06 in its 2025 Top 10 for LLM applications, and breaks it into three failure modes: too much functionality, too many permissions, and too much autonomy. The agent can do too much, reach too far, or act without anyone checking.
The scope of the credential is the size of the blast radius
When an over-permissioned agent meets an ambiguous instruction, a hallucinated step, or a prompt-injection attack hidden in a file it was asked to process, the damage is not set by how clever the attack was. It is set by how much power the agent was holding. An agent with a master key can be talked into editing assets it was never asked to touch. The same model with a scoped grant has no path to reach them. The credential matters more than the model's IQ.
Most projects are still using the master key today
This is not a hypothetical. A 2026 survey of more than 900 practitioners reported by an agent-identity research roundup found that 93% of AI agent projects were still using unscoped API keys, and 74% of respondents said their agents ended up with more access than they actually needed. The numbers come from one practitioner survey, not a universal census, but the direction is hard to miss. The default in the field is still the master key.
Scope by operation and by asset, not by "trusted or not"
Two questions bound almost everything an agent can do
Real scoping answers two separate questions, and you need both. The first is by operation: which edits may this agent run? The second is by asset: which files may it run them on? A common failure is to nail one and leave the other wide open. An agent allowed to do anything to one user's files, or allowed to crop but able to crop the entire library, is only half-bounded. Fine-grained authorization, the access model most identity platforms now ship for agents, is built precisely around this: permission to perform a specific action, on a specific resource, under a specific context, as fine-grained authorization guides describe it.
Deny: delete, replace, publish.
Deny: the rest of the library.
not a key that lives forever.
Add a time bound so access disappears with the task
The third axis is time. Security teams increasingly recommend short-lived, task-scoped credentials that expire when the work is done rather than standing access that lives until someone remembers to revoke it. Least-privilege guidance for agents frames this as dynamic scoping: grant access based on the task in front of the agent, for exactly as long as that task runs, then take it back. The shorter the window, the smaller the opportunity for a stray instruction to do harm.
On whose behalf? Delegation is the part teams skip
Acting for a user is different from acting as your service
Here is the distinction that decides whether your audit log is meaningful. When an agent edits a user's media, it is acting on that user's behalf, not as your backend service. That difference is the whole of delegated, or on-behalf-of, permission. The agent should inherit only that one user's access, for that one task, and the record should show both the agent and the user it acted for. A role-based grant where every agent shares one service identity is simpler to manage, but it cannot answer the question that lands on legal's desk: which user authorized this specific change?
The standards are converging, even where they are still drafts
The identity world is building for exactly this. On-behalf-of token exchange is grounded in RFC 8693 OAuth 2.0 Token Exchange, and a 2025 IETF Internet-Draft on on-behalf-of-user authorization for AI agents, an individual submission that has since expired and was never adopted as a working-group standard, proposed issuing tokens that carry the identity of the user, the agent, and the calling application together. The point for an adopter is not the wire format. It is the principle: the grant names the user and the agent, so the agent's reach is the user's reach and nothing more.
This is also where this post meets its companion piece on verifying the full delegation chain, which covers how that chain holds up end to end once the edit is signed.
An API key and a scoped agent identity are not the same tool
A key says "let this caller in," and that is all it says
An API key is one shared secret. It is usually long-lived, often broadly permissioned, and it carries no notion of who the agent is acting for or which single action it should be allowed to take. It is fine for a trusted server-to-server call. It is the wrong primitive the moment an autonomous, non-deterministic agent is on the other end of it. Industry write-ups are blunt that static API keys fail on the dimensions that matter at production scale: revocability, attribution, scope, and rotation cost.
A scoped identity gives you per-agent revocation and a real audit trail
A scoped agent identity flips all four. The agent gets its own credential, so you can revoke one agent without breaking every other integration. Each action is bound to both the agent and the delegating user, so attribution is built in. The grant is scoped to an operation and an asset, so reach is narrow by construction. And short-lived tokens make rotation automatic instead of a chore.
The connectivity standard most platforms have adopted, the Model Context Protocol, mandates scoped OAuth when agents act on a user's behalf for these reasons. The upgrade from a key to an identity is not bureaucracy. It is the difference between "we can mostly turn it off" and "we can tell you exactly what happened and stop it precisely."
Brand safety is the guardrail an editing agent specifically needs
Permission says it may run, brand safety says whether it should
Scoping decides what an agent is permitted to do. Brand safety decides whether a permitted action is actually acceptable. For a media agent the two are different jobs. An agent may have valid permission to recolor a logo, replace a face, or push a generated frame into a published asset, and still produce something that is off-brand, off-policy, or legally risky. Guardrails are the layer that constrains the action before it executes, checking the output against policy and blocking or modifying anything that violates it rather than letting it ship. For higher-stakes edits, you pair that automated check with a human-review gate, covered below.
The stakes are real enough that the regulators are watching
This is no longer only a taste concern. The EU AI Act's transparency obligations for AI-generated and manipulated media become enforceable in August 2026, and analysts tracking brand safety in the AI-content era describe it as a board-level risk now that synthetic content scales faster than manual review. For an editing agent the practical guardrails are concrete: an allowlist of brand-approved operations, a deny list for sensitive transforms like face replacement or logo edits, and a human-review gate on anything destined to publish. This is not about distrusting the agent. It is about giving the human the final say where taste and brand are the whole point.
The build-versus-adopt decision is yours to make
Both paths are legitimate, and they cost different things
Everything above is buildable. The honest question is whether you should build it or adopt a layer that already has. Both are real choices with real trade-offs, and the right answer depends on how central this boundary is to your edge.
Where Layermetry fits, named lightly
This is the gap Layermetry is built to fill. It is an SDK for AI media editing that enforces scoped permission at the edit boundary itself: the agent presents a delegated, on-behalf-of grant, the requested operation and asset are checked against scope before the edit runs, and brand-safety rules gate the result. Because the editor ships native operations and lets you ship your own tools alongside them, the boundary is extensible rather than a fixed wall, so your effort goes into the agentic workflow that differentiates you, not into rebuilding authorization plumbing and keeping it current as standards move. That is the trade: you give up some control and take on a dependency, and in return you stop maintaining a permission layer forever.
The boundary is the decision
When you let an agent edit media for your users, the model is rarely the hard part. The hard part is the boundary around it: what it may do, on whose behalf, to which assets, and what stops an off-brand or out-of-scope edit from shipping. You can build that boundary yourself and own it end to end, or adopt a layer that enforces it at the edit point so you can spend your effort on the work that makes you different. Either way, the master key is not the answer. If you want to see how scoped permissions, delegated access, and brand guardrails compose in one place, the Layermetry docs walk through it as a lower-maintenance alternative to wiring it together yourself.
FAQ
What is the difference between an API key and a scoped agent identity?
An API key is a single shared secret, usually long-lived and broadly permissioned, with no built-in way to say who the agent is acting for or what one specific action it may take. A scoped agent identity gives the agent its own credential, ties each action to both the agent and the delegating user, and lets you grant only the exact operation on the exact asset for a bounded time. The practical difference is revocability, attribution, and scope. With a key you can mostly turn everything off. With a scoped identity you can answer who did what, on whose behalf, and revoke one agent without breaking the rest.
How do you scope what an AI agent can edit on a user's behalf?
Scope along two axes at once. By operation, allow only the specific edits the task needs, such as crop, resize, or caption, and deny everything else like delete or replace. By asset, restrict the agent to the user's own files or a named project, not the whole library. Then bind both to a delegated, on-behalf-of grant so the agent inherits only that user's access for that task and timeframe, and re-verify scope at the moment the edit is applied rather than trusting a token issued upstream.
What is excessive agency and why does it matter for media editing agents?
Excessive agency is the OWASP LLM risk that occurs when an agent has more functionality, permissions, or autonomy than its task requires. For a media agent it shows up as the ability to touch assets it was never asked to touch, run operations outside the brief, or act without review. The damage from an ambiguous instruction or a prompt injection is bounded by the scope of power the agent was given, so the fix is least privilege: grant only the operation, only the asset, only for the moment it is needed.