A signed per-run envelope shrinks an agent's credential to two actions and two hours

The envelope the dev.to post proposes names one run. Its subject is `agent:reconciliation-prod-07`, and its `issued_for` field names one task, `task:expense-recon-2026-09-19` ^[7]. "First, the subject is the agent instance, not the agent class," the author wrote. "reconciliation-prod-07 is one run, and its credential dies with the run. A compromised prompt in one run cannot reach into the next" ^[8].

`valid_from` is 2026-09-19T06:00:00Z and `valid_until` is 2026-09-19T08:00:00Z ^[7], a window of two hours ^[1]. Against a key that is valid around the clock, that is about 8 percent of the day ^[2]. It also matches the job described, a nightly reconciliation running between 2 a.m. and 4 a.m. Eastern ^[9]; 06:00Z is 2 a.m. Eastern daylight time ^[3]. The grant lists two actions, `s3:GetObject` on one bucket and `dynamodb:PutItem` on one table ^[7], which is what matching 40,000 receipts against 40,000 ledger entries requires ^[9].

Issuing that envelope costs three things most shops do not have: an identity per run, an issuer that signs and expires grants, and a resource list known at dispatch. The resource list is the hardest of the three. The post's own explanation for standing credentials is that agent tasks are unpredictable and you cannot always pre-scope a grant when you do not know what the agent will need to touch ^[10]. A scheduled reconciliation escapes that because its resource list is fixed before it starts. A coding agent does not know which repository it reads next, and coding agents are what got hit ^[1]. The construct being stretched here is the service account, designed for long-lived daemons with fixed behavior and now handed to software that behaves differently every run ^[11]. What does carry over to an interactive agent is expiry and an instance subject: a session-scoped credential that dies with the session shortens the window even when the scope stays wide.

The credential-lifetime reading is the author's inference, not a finding in the vulnerability research the post cites. The post states that every one of the hijacked plugins held a standing credential somewhere, ready to be borrowed, and that the attacker did not need to mint new access ^[5]; it does not publish evidence for that. The supporting figure is a survey, with Exabeam reporting that 48 percent of security leaders rank AI agents operating with excessive, compromised, or unintended access as the greatest threat to their organization ^[4]. That number measures what security leaders fear. The author is candid about the design's status too: "Yes, this is a theoretical scenario, but it is hardly an unusual one" ^[12].

Two of the four vendors had not released patches at the time of writing ^[3]. Credential lifetime is the one variable in this chain an operator changes without a vendor release, and the post's case for it is that "a standing credential works at 3 a.m. on a Saturday, in a prompt injection's hands, with no human in the loop" ^[6]. The comparison offered is the access path a person already gets: scoped to the ticket, expiring, reviewed, with break-glass that sets off alarms ^[13].