The QA-to-prod escalation is where agent identity taxonomies earn their keep

Mid-task escalation is where the three models stop being vocabulary. Delegated authority makes a named human the delegation subject and requires every action to trace back to that person, including what scope was granted and the steps taken ^[9][10]. Escalation under that model is a consent event with a hard ceiling, because the agent inherits the human's permissions inside an explicitly scoped boundary ^[15]: it cannot be lent production rights the developer does not hold. Bounded authority has no human subject in the chain at all, since the agent acts for a system or workflow within a defined operational boundary ^[12]. There is nobody to ask, so the only honest escalation is an edit to the workflow definition, reviewed before the run rather than during it. Autonomous authority inverts the problem. 1Password describes agents that evolve their access needs over time, spawn sub-agents, and reach systems the initiator never explicitly planned for ^[13]. For those, escalation is the normal operating mode, and anything issued as a durable role rather than a short-lived per-action credential is over-provisioning by construction ^[1].

Underneath all of it sits attestation, which tends to get discussed after policy and should be argued first. An IDE agent executes under the same OS user account as the developer, so without additional controls any other process under that account can present credentials claiming to be the agent: malicious code, a compromised package, or a payload delivered by prompt injection ^[16]. 1Password says that route was documented in a production environment, where indirect prompt injection turned a long-lived local agent session into an attack vector ^[19]. Put that together with real-time escalation and the request for production arrives from a process the authorization server cannot reliably identify. The delegation-level question the post poses, proving whose authorization the agent holds in a way that is cryptographically verifiable and auditable ^[15], has to be answered before dynamic authorization means anything. And this is the profile the post calls both the most common deployment pattern and the highest attestation risk ^[3].

The six-profile framing carries a build cost that the three-model summary hides. The same coding agent is a different profile depending on whether it runs on a laptop or a CI/CD platform, and 1Password says that local-versus-remote split drives a significant portion of the protocol choices in each profile ^[14]. Three authority models across two deployment locations is six sets of controls to build or explicitly refuse ^[18]. The supplied text begins to answer for the remote side, introducing a Workload Identity Broker that replaces static API keys and passwords with ephemeral, policy-driven credentials and is already common in cloud-hosted work such as CI/CD, then breaks off mid-sentence on what is typically absent locally ^[4]. Anyone whose worst-case agent lives on a developer's machine is still waiting for that half of the argument.