The Backend Was Registered For The Delegate. The Primary Agent Kept The Route.
GitHub's own Agentic Workflows compiler needed a GitHub MCP backend to stay registered in a workflow run's runtime so a narrowly bounded, dynamically delegated identity could use it. Issue 59045 and its merged pull request 59046 describe a runtime that also left that same backend in the primary agent's own unrestricted, routable server set, even when the workflow granted the primary agent no top level GitHub tool access of its own. The gap and its fix both landed the same day, 6 to 7 September 2026, and the corrective principle generalizes past this one workflow runtime.
Event analysed: . This analysis was published on 7 September 2026.
In github/gh-aw's own account of its dynamic repository enclave feature, yes, until issue 59045 and pull request 59046 fixed it. A dynamic enclave lets a workflow request a bounded, runtime issued GitHub read policy for a delegated identity rather than only a policy fixed at compile time, and the GitHub MCP backend has to stay registered in the run for that delegated identity to reach it. Issue 59045, opened 6 September 2026 and closed the same day pull request 59046 merged, 7 September 2026, states plainly that the runtime also carried that same backend into the primary agent's own unrestricted, routable server set whenever a dynamic enclave was configured, even when the workflow granted the primary agent no separate tools.github access of its own. The merged pull request's own stated fix keeps the backend registered for the delegated identity while deriving the primary agent's routable servers independently, so registration for one principal's delegated use stops standing in for another principal's own grant. This record independently confirms the delegated policy itself is closed to exactly two read only tools, list_issues and issue_read, with GraphQL, search and every write denied by the runtime's own documentation, and that the fix shipped in gh-aw release v0.88.5 on 7 September 2026, a release GitHub's own listing marks pre release. This record found no evidence that a working production dynamic enclave was ever exploited through the gap: issue 59045 states the runtime's own generated delegation controller configuration was rejected by the mcpg gateway version then in place, so the real controller never started and the runtime rejected dynamic policies outright rather than running them insecurely.
A GitHub Agentic Workflow can ask, at compile time, for a fixed GitHub tool policy. GitHub's own dynamic repository enclave feature adds a second path: a workflow can request that a policy be issued at runtime instead, bounded to a set of allowed owners and, optionally, exact repositories, so an agent working across many jobs does not need every possible target baked into the workflow file in advance. Making that work requires a GitHub capable MCP backend to exist inside the run's own gateway process, reachable by whatever delegated, narrowly scoped identity the runtime mints for that dynamic policy.
Issue github/gh-aw#59045, opened 6 September 2026 at 22:35 UTC and closed the following morning when its linked pull request merged, states the resulting gap directly, in its own words, as a requirement the runtime was not yet meeting: keep the GitHub backend registered so delegated identities can use it, but remove it from the primary agent's policy unless the workflow separately enables top level tools.github. Read the other way round, as a description of the behavior the issue was filed against, that sentence says a dynamic enclave's own registration requirement had been leaking into the primary agent's own routable server set, with no independent grant behind it.
One registration, two principals
The distinction the issue is drawing is not subtle once stated, and it is exactly the distinction this desk keeps finding missing in delegation infrastructure elsewhere: a backend existing inside a runtime's own process is a fact about the runtime. Which principal may address that backend is a separate fact, decided per principal, not inherited from the backend's mere presence. A dynamic enclave's delegated identity needing the GitHub backend registered is a true and unavoidable requirement, the backend has to be somewhere for the delegated identity to reach it, and it does not, by itself, say anything about whether the workflow's own primary agent, the one actually driving the run and reading the workflow's own instructions, should be able to address that same backend too. Those are two different questions a runtime has to answer separately, and the pre fix behavior the issue describes answered them together, with one registration decision silently deciding both.
Pull request github/gh-aw#59046, opened minutes after the issue and merged 7 September 2026 at 02:39 UTC into merge commit beginning e79e368, is the same day's stated fix. Its own account of what changed, read directly from the pull request, names the primary agent isolation piece specifically as a fix to a routing gap: the GitHub MCP backend had stayed in the primary agent's unrestricted, routable server list whenever a dynamic enclave was configured, independent of whether the workflow granted tools.github at the top level. The pull request's own stated correction keeps the backend registered, so the delegated identity's own bounded policy continues to work, while deriving the primary agent's own routable servers from the primary agent's own grants rather than from what the runtime happens to have registered for someone else's use.
What the delegated policy actually grants, verified directly
The pull request and the issue both describe a fixed, closed policy identifier, github-repository-read-v1, as the only policy a dynamic enclave may currently request. This record fetched the runtime's own documentation directly, at the .github/aw/enclaves.md path in the repository at the v0.88.5 tag, rather than relying on the pull request's own prose description of it, and confirms the policy's own stated tool set precisely: exactly two tools, list_issues and issue_read, with the same document stating plainly that GraphQL access, search, every write operation and every other GitHub tool remain denied. Those two tools are the entire permitted set, not an excluded pair inside a larger one, a distinction worth stating exactly because it is easy to misread a closed policy's own name as naming what it forbids rather than what it permits. The same document states the dynamic policy also carries allowed-owners or allowed-repositories selectors, a fixed sensitivity level, finite resource limits including a maximum repository count, invocation count, output size and execution time, an absolute expires-at timestamp no later than the job's own lifetime, and audit labels. This record's own direct fetch did not find a documented schema hash mechanism, a separately stated maximum identity TTL distinct from expires-at, or a documented generation field in this specific markdown file, and states that absence as what it is, an undocumented detail in the one source this record could reach, not a claim that no such mechanism exists in the runtime's own code.
What was not running, and why no exploitation is claimed here
Issue 59045's own text is specific about why this was a routing gap in generated configuration and a rejected runtime path, not a live production exposure: the compiler's own provisional gateway.delegationControllers configuration was not accepted by the mcpg gateway version then in place, so the real delegation controller never started, and the workflow runtime rejected dynamic policies outright as a result. That is a fail closed outcome on the controller integration itself, independent of and prior to the separate routing gap this record describes above. This record found no report, in the issue, the pull request or any advisory it could locate, of a dynamic enclave actually running in a real workflow while the primary agent's routing gap was live, and does not claim one occurred. What the evidence supports is narrower and still worth stating on its own terms: a concrete authority boundary defect existed in the runtime's own generated configuration and routing logic, verified from the project's own issue and merged fix, independent of whether a live session was ever exposed to it.
Where the fix has, and has not yet, reached
This record confirms directly that pull request 59046 is named in the release notes for gh-aw v0.88.5, published 7 September 2026, the same day the pull request merged, and that GitHub's own release listing marks that tag pre release rather than a full, stable release. The pull request's own description mentions a companion mcpg gateway upgrade; this record's own direct read of the repository's checked in .github/aw/actions-lock.json file at the v0.88.5 tag finds two pinned mcpg container image entries, v0.4.15 and v0.4.16, and no v0.4.17 entry anywhere in that file, while the same tag's own enclaves.md continues to state a minimum of mcpg v0.4.16 for a dynamic entry, not a newer version. This record does not confirm a claimed mcpg v0.4.17 upgrade or a specific internal version gating constant name against the repository's own checked in files, and states that specifically as unconfirmed rather than repeating an earlier, less directly sourced description of this pull request that named one. What this record does confirm directly is that a minimum mcpg version check for a dynamic entry exists in the runtime's own current documentation, and that the fix landed in a pre release tag rather than a confirmed stable release as of this record's own verification.
The Authority Provenance ledger
Authority grantor. Two distinct grantors sit behind the two principals this record separates. The workflow's own author, through the workflow file's tools.github configuration, is the grantor of the primary agent's own GitHub authority, when any exists. The dynamic enclave configuration itself, compiled into the run and reconciled through the delegation controller the merged fix wires into AWF, is the grantor of the delegated identity's own bounded read authority. Neither grantor is the runtime's own act of registering a backend; registration is infrastructure the runtime performs, not a decision either grantor makes.
Mandate or basis. Documented for the delegated identity specifically: its authority traces to the workflow's own dynamic enclave configuration, compiled and reconciled against the closed github-repository-read-v1 policy this record verified directly. Undocumented for the pre fix primary agent state: nothing in the issue or the pull request describes an intended basis for the primary agent receiving the GitHub backend's route absent its own tools.github grant, which is exactly why the issue names it a gap to close rather than a documented design choice.
Delegated scope. Documented and specifically bounded, verified directly against the runtime's own documentation: exactly list_issues and issue_read, scoped further by allowed-owners or allowed-repositories, a fixed sensitivity level, finite resource limits and an absolute expiry no later than the job's own lifetime.
Explicit limits. The two tools named above, the owner and repository scoping, the resource limits and the expiry ceiling are each stated directly in the runtime's own documentation this record fetched. A separately stated maximum identity TTL distinct from the expiry timestamp, a schema hash mechanism and a generation field are each described in this pull request's own account of the fix; this record's own direct read of the one documentation file it could reach did not independently confirm those three specifically, and states that as an evidentiary gap in what this record itself verified, not as evidence the runtime lacks them.
Inherited permissions or assumptions. This is the entry's own center. Before the fix, the primary agent inherited a route to the GitHub backend from the fact of the backend's own registration for the delegated identity, an inheritance the issue itself names as a gap rather than an intended assumption. After the fix, per the pull request's own stated correction, the primary agent's routable servers are derived from the primary agent's own grants, and registering a backend for a delegated identity's use carries no inherited route to any other principal.
Revocation or modification path. The pull request's own description states an absolute expires-at ceiling bound to the job's own lifetime, resolved at runtime as the earlier of the configured expiry and the job start plus the enclave's own timeout, rather than only a compile time absolute check; this record was not able to independently verify that specific runtime resolution formula against the repository's own checked in source and states it here as the pull request's own account, not as this record's own direct confirmation.
Challenge authority. Not documented as a distinct mechanism in anything this record could reach; a rejected or incompatible delegation controller configuration causes the runtime to fail closed and decline to run the dynamic policy at all, per issue 59045's own account of the pre fix state, rather than a separate party formally contesting an already granted delegation.
Recovery path. Not applicable to the pre fix routing gap in the sense of undoing a completed action: this record found no report of a dynamic enclave actually running while the gap was live, so there is no reported action to recover from. The fix itself is the recovery path for the gap's own future recurrence, verified merged and confirmed present in the v0.88.5 tag's own release notes.
Provenance evidence quality. Layered, and stated exactly rather than rounded up. The issue's own text, the pull request's own stated changes, the delegated policy's exact tool set and the pull request's inclusion in the v0.88.5 release notes are each independently confirmed by this record's own direct fetch of GitHub's repository and release pages. The specific mcpg version the fix moved to, and an internal version gating constant name attributed to the pull request in an earlier, less directly sourced pass over it, are not confirmed against this record's own direct read of the repository's checked in configuration at the v0.88.5 tag, which shows mcpg pinned no higher than v0.4.16 and a documented minimum of v0.4.16 for a dynamic entry; this record states that specific claim as unconfirmed rather than repeating it as established.
Why this is not a claim about GitHub specifically
Nothing in this record depends on GitHub Agentic Workflows, MCP or the Model Context Protocol's own vocabulary to be true. Any runtime that keeps a capability registered because some delegated, narrowly bounded identity needs it faces the identical question this issue names: does that registration, by itself, give a different principal, the one that created or is running alongside the delegation rather than the one the delegation was scoped for, a route to the same capability. A runtime that answers yes by default, or by omission, has let an infrastructure fact stand in for a principal specific authorization decision it never actually made. This desk's own existing coverage of authority inheritance has so far concerned a delegate receiving too much from whoever created it. This occurrence names the same failure running the other way: a capability that exists only because a delegate needed it, reaching back to a principal that was never delegated to at all.
What this does not show
This is not a claim that a working production dynamic enclave was ever exploited through this gap; issue 59045's own account states the real delegation controller never started under the mcpg version then in place, and the runtime rejected dynamic policies rather than running them with the routing gap live. It is not a claim that the delegated identity itself ever held more than list_issues and issue_read, which this record verified directly as the policy's entire permitted set. It is not a claim that every detail this pull request's own prose describes, the exact mcpg version, an internal version gating constant, a schema hash mechanism or a generation field, is independently confirmed here; each of those is stated above exactly as confirmed, partially confirmed or unconfirmed by this record's own direct reads, rather than rounded into a single verified account. There is no CVE or security advisory here, and none is claimed. What stands is a first party issue and its own merged fix, both dated 6 to 7 September 2026, describing and closing a routing gap in which a capability registered for one principal's delegated, bounded use also reached a different principal that held no independent grant for it.
Sources
This analysis interprets third-party reporting, research and announcements. Moona is not the original reporter of the underlying events.
Protocol evidence
This record does not assess these architectures. The connection runs through the Risk Registry requirement each one bears on, and these published authority architectures are what the evidence says about that requirement.
Protocol evidence related through AEW-006 Delegated authority inherited without attenuation
- Supports requirement
Agent Flight Recorder
Laurent Bindschaedler, Quentin Botha, Christoph Siebenbrunner (independent research, arXiv preprint)
Requirement Delegation provenance (the requesting agent's identity, the parent event's hash, and the delegated scope) is recorded per event, but attenuation of that scope is not itself enforced
This weakness names authority spreading past its granted boundary because a delegated grant is not checked for narrowing, expiry, or revocability against its parent. Agent Flight Recorder's own delegation provenance field records a requesting agent's identity, a parent event's hash, and a delegated scope per event, which would let an investigator reconstruct after the fact whether a given delegation ever attenuated relative to its parent. That is evidence supporting the need for an attenuation check, not an attenuation check itself: nothing in the material available to this record describes the construction rejecting, narrowing, or expiring a delegated scope at the point delegation happens, only recording what was claimed about it.
- Supports requirement
An Architecture for Auditing Agent Delegation and Interactions (audit-architecture)
Mirja Kuehlewind (Ericsson) and Henk Birkholz (Fraunhofer SIT), individual submission to the IETF
Requirement The draft keeps a Delegation Record's existence separate from the delegatee's current effective authority
This weakness's own corrective principle states that a delegated grant must not exceed its parent's scope, must not outlive its parent's expiry, and must be revocable together with it. The draft's own separation of a Delegation Record, which states that a delegation occurred, from an Authorization Transition Record, which states the delegated scope's current standing, is structural support for exactly that principle: evidence that authority was delegated is kept apart from evidence of the delegatee's currently effective authority, rather than one record class being asked to carry both facts. Recorded as design evidence for the attenuation principle this weakness names, not as a claim that any implementation of it exists outside the draft's own text.
- Supports requirement
ARC, Agentic Runtime Control
Britive
Requirement Elevated privilege is documented as minted directly in a target system through its own native API and revoked automatically when a task ends, with credential brokering as a separate path for systems that require one
Britive's own documented model brokers or mints credentials ephemerally and scoped to a task, rather than leaving a standing credential ambiently reachable by whatever caller happens to connect. argocd-mcp's pre fix ARGOCD_API_TOKEN is the failure that principle answers, made concrete at an MCP server rather than at the CI or SSH targets Britive's own material names: a standing, environment configured credential, reachable in full by any network caller whose request the server's own credential check would accept regardless of what, if anything, the request itself supplied. The shipped fix, a separate MCP_AUTH_TOKEN, narrows who can reach the server at all rather than narrowing or brokering the ARGOCD_API_TOKEN itself, which remains one long lived, ungraded credential shared across every holder of the new inbound token.
- Supports requirement
Cross App Access (XAA), Okta Agent SSO and MCP Enterprise-Managed Authorization
Okta
Requirement Enterprise Managed Authorization governs the cross app connection, not the individual action an agent later attempts
Cross App Access places the decision of which requesting identity may open a connection to a resource application with the enterprise identity provider and an administrator's own configured policy, independent of whether that resource application, or a server fronting it, is separately reachable inside the same environment. That connection level, principal specific decision is the same corrective github/gh-aw's own merged fix applies to a dynamically registered GitHub MCP backend: a backend's registration for one principal's delegated use is deliberately not read as a connection grant for a different principal, which must clear its own independent check.
This record is the cited evidence for this relationship.
- Supports requirement
Grantex and the Delegated Agent Authorization Protocol (DAAP)
Sanjeev Kumar, Grantex
Requirement Child scopes MUST be a subset of the parent's scopes, and a child may hold exactly the parent's scopes
Grantex enforces that a child grant's scope is a subset of its parent's and its expiry the earlier of the two, which is the attenuation these inheritance and shared credential failures lack. Unit 42's account of a real enterprise intrusion, corrected 3 September 2026 to clarify the event was an intrusion rather than ransomware, is a longer instance of the same missing attenuation: credentials a reconnaissance and repository search step discovered reached a secrets manager, then CI/CD and cloud identity, with no subset or expiry check narrower than what each step happened to find described at any hop.
- Supports requirement
Verifiable Attenuated Delegation for AI Agent Chains (draft-asor-wimse-agent-delegation-chain)
Rafael Asor, Attenu
Requirement A child's authority must be a verifiable subset of its immediate parent's: scopes under the wildcard containment rule, every parent constraint present and equal or narrower in the child, and expiry and delegation depth no greater than the parent's
The draft requires a child's scopes, ceilings, constraints and expiry to be a verifiable subset of its immediate parent's, cryptographically checkable offline through a parent hash, which is the attenuation these inheritance and shared credential failures lack. OpenCode issue 47819 documents the same missing subsumption check at the level of a single agent's own permission configuration: the merge composing a custom agent's frontmatter block against the platform's own defaults is a union of the two rather than a verified subset of the wider one.
- Supports requirement
Verifiable Attenuated Delegation for AI Agent Chains (draft-asor-wimse-agent-delegation-chain)
Rafael Asor, Attenu
Requirement Revision 01 adds a min constraint type whose safe attenuation direction is upward, a floor that can only rise as authority narrows
Revision 01's own min constraint, and its explicit statement that a maximum narrows downward while a minimum narrows upward, makes precise a point this weakness otherwise leaves implicit: narrowing is not one direction for every dimension of authority, and a delegation mechanism that only checks subset and shorter expiry can miss a floor that widened rather than a ceiling that loosened.
- Reveals bypass
Agent Identity and Agent Identity Auth Manager
Google
Requirement Agent identities are not shared by multiple workloads by default, cannot be impersonated, and do not allow long lived keys
Google's own comparison states that an agent identity, unlike a service account, is not shared by multiple workloads by default, cannot be impersonated and does not allow long lived keys. argocd-mcp's own ARGOCD_API_TOKEN is exactly the shape this property contrasts against: one long lived, environment configured credential, shared by construction across every caller able to reach the server, with nothing this entry's own reading of the affected source found narrowing which caller could exercise it. This does not fault Google's own architecture, which the property itself only describes rather than mandates elsewhere; it evidences why the comparison the property draws is the attenuation this weakness's own known examples keep missing.
- Reveals bypass
AI Agent Identity Certificate (AIC) extension for X.509 v3
Jijie Wei, individual submission to the IETF
Requirement Authority can go stale after issuance
AIC's authorized mode locks the permission set into the certificate at issuance, so authority can go stale: a change to the principal's grants after issuance does not reach an already issued certificate, a delegation gap the inheritance failures illustrate.
- Reveals bypass
Verifiable Attenuated Delegation for AI Agent Chains (draft-asor-wimse-agent-delegation-chain)
Rafael Asor, Attenu
Requirement Nothing in the token profile establishes that the root token holder was actually entitled to grant the authority the root token represents
A verified chain proves lineage forward from a trusted root key, not that the root holder was ever entitled to the authority it represents, so a mistaken or illegitimate grant at the root produces a chain every hop of which still narrows correctly, an inheritance failure the subsumption check alone does not reach.