The Agent Was Authorized. The Schedule Never Was.

Routines in Foundry Agent Service, in public preview, attach a trigger to an agent so it runs unattended on a timer, a cron schedule, or an external event, and the routine record captures the trigger, the action, and the run history but not the named decision-maker, the business justification, or a review date. Agent 365 lifecycle governance can reassign an ownerless agent to a new owner, and Microsoft's documentation does not state that reassignment reauthorizes or revalidates a standing routine's continuing business purpose, so ownership transfers while intent does not. On the Deployment Accountability Map, authorizing the schedule sits with the deploying organization at Tier 3, and the correction is a standing-trigger clause on the Agent Authorization Document recording owner, justification, and review date, with an orphaned trigger treated as an unauthorized deployment from the day its owner departs.

The routine fired at six on Monday morning, the way it has every Monday for nine weeks. By the time the first person badged in, it had processed nine hundred and twelve records. The incident review, convened for an unrelated data question, opened with the standard question: who ran this? The run history answered with a timestamp. The agent's authorization record was current, signed, and complete. The engineer who configured the trigger left the organization in June. Nothing in the record mentions Monday.

Your authorization process approves agents. What approves the trigger that wakes them?

Start with the mechanism, because Microsoft built a clean one. Routines in Foundry Agent Service, currently in public preview, let an agent run automatically when a defined trigger fires: a one-time timer, a recurring schedule, or an external event, currently a GitHub issue or a new Teams channel message (Microsoft Learn, Routines documentation, updated August 5, 2026). Microsoft describes Routines as a project-native alternative to assembling this layer from components such as schedulers, Logic Apps, and Azure Functions ( Microsoft Foundry blog, July 1, 2026 ). Each routine has exactly one trigger and one action, and the trigger, the action, the permissions, and the run history live in the same Foundry project as the agent. As engineering, this is exactly what enterprises asked for. The preview ships without a service-level agreement, and Microsoft does not recommend it for production workloads. The Monday routine above is, of course, already production.

Read the routine record closely, though, and notice what it holds. A trigger. An action. A history of runs. It does not hold the name of the person who decided the run should exist, the business reason it exists, or the date anyone will ask whether it still should. The documentation is careful about what even the run record proves: a completed run means the dispatch succeeded, not that the work the agent started ever finished. A trigger is intent frozen at configuration time. The organization reorganizes, reprioritizes, moves on. The cron expression attends none of those meetings and keeps firing.

The routine record, per Microsoft's Foundry documentation. Three things in. Three questions out.

The obvious objection is that Microsoft already governs agent ownership, and the objection is correct. The Agent 365 May 2026 update introduced rules-based lifecycle governance, including standard rules for auto-reassignment of ownerless agents, initially for agents built in Agent Builder (Microsoft Agent 365 blog, May 2026). Microsoft's documentation now covers reassigning ownership of ownerless agents and quarantining noncompliant ones, with shared-agent reassignment currently documented for Agent Builder and Copilot Studio (Microsoft Learn, July 1, 2026). In the constructed tenant above, ownership governance did its job. The agent was flagged as ownerless, and an administrator reassigned it to her manager. Every dashboard showed a current owner. That is precisely why nobody looked. The product documentation does not state that reassignment reauthorizes, reviews, or validates a standing routine's continuing business purpose. Authorizing the schedule was never its job.

The controls operate on the agent, and the agent was fine. The reassignment handed the agent to a manager who had never heard of the Monday run, along with a standing schedule encoding a decision made once, informally, by someone no longer in the building.Ownership transferred. Intent did not.The distance between what that agent is authorized to do and what anyone currently at the organization intends it to do is the Intent Gap , and a standing trigger is where it compounds weekly, on schedule.

The agent moved to a new owner. The schedule never noticed.

Nobody ran the agent this morning. That is the finding.

The Deployment Accountability Map is built for exactly this landing. Three tiers. Tier 1, the AI provider, built and maintains the Routines capability, and its accountability ends at published specifications. Tier 2, the control infrastructure. Microsoft Entra Agent ID gives the agent its identity. Microsoft Purview brings data governance, compliance, and audit capability. Foundry holds the routine configuration, fired the schedule on time, and recorded every run. Those controls enforce and evidence what was configured. None of them authors the decision that a Monday six o'clock run should exist, or still exist. That decision belongs to Tier 3, the deploying organization, and when the incident review went looking for it, they found it had been made once, informally, by someone who no longer works there, and recorded nowhere. Accountability does not cascade through the tiers. It lands, and it lands on Tier 3, because the boundary between what the platform handles automatically and what requires a deliberate organizational decision is where the gap lives.

The repair is a standing-trigger clause on the Agent Authorization Document . Every schedule and every trigger gets three things on the same record that authorized the agent: a named owner, this is the Consequence Owner for the runs, a business justification one sentence long, and a review date. Two operating rules give it force. An orphaned trigger, meaning its owner has departed, is treated as an unauthorized deployment from the day of departure, suspended until a new owner signs. And the offboarding checklist gains the line it was missing: every standing trigger this person configured, listed and reassigned before the badge is collected. The agent was authorized. The schedule never was, and the clause exists so that sentence can never be true again in your environment.

The standing-trigger clause. Three fields, two rules, one page.

Somewhere in your tenant a schedule will fire tomorrow morning encoding a decision nobody present remembers making.

How many standing triggers in your environment are currently owned by former employees, and who would even produce that list?

Frameworks referenced: The Deployment Accountability Map · Intent Gap · Agent Authorization Document

Citable research: Sougata Roy,Who Owns the Agent?, DOI 10.5281/zenodo.20481551 · The Authorization Layer, DOI 10.5281/zenodo.21245690

The scenario in this edition is constructed. Product facts: Microsoft Learn (Routines documentation, updated August 5, 2026; agent lifecycle actions, July 1, 2026), Microsoft Foundry blog (July 1, 2026), Microsoft Agent 365 blog (May 2026). Intent Gap, the Deployment Accountability Map, the Consequence Owner role, and the standing-trigger clause are the author's published frameworks (sougataroy.com/frameworks), not Microsoft product features. Views are my own.