Whose Authority Does a Background Agent Use?

A scheduled agent can start work without a person opening a chat. Its permissions still need to identify whose resources it may use and which actions it may take.

Consider a hypothetical hotel group. A regional manager asks an agent for an occupancy summary covering her properties. Later, a nightly schedule starts the same reporting workflow. That background run needs an approved account, a defined set of hotels and an agreed distribution list. It should not inherit whichever manager's credentials happened to be used most recently.

The report can be routine. Deciding whose data it may include is part of the deployment's authority.

Identity depends on how work starts

In The five components of building a "company harness", Harrison Chase and Caspar Broekhuizen describe LangChain's approach to interfaces, identity, memory, code execution and scheduled or event-triggered work.

The identity examples are especially useful. OpenSWE acts as a user during interactive work but uses a GitHub app for background code review. Their sales agent uses a fixed Salesforce identity, while email access acts on behalf of the user and is available only in direct messages. Identity varies by tool and invocation context, rather than belonging to the agent as one universal account.

This is an engineering design account. It describes how the authors organize their systems, without a controlled evaluation of how effectively those arrangements enforce security.

A trigger needs an authority context

Our signals-and-triggers note asks what observation should start work. This adds another question: under whose authority should the resulting run operate?

For a WTK catalog package compiled into a target environment, the answer needs to connect the trigger to the permitted account, resources, tools and recipients. A schedule identifies when to run. It cannot, by itself, authorize access to every resource the agent can reach.

In the hotel example, the background account might read occupancy totals for specified properties and send a summary to an approved operations channel. Guest-level records could remain outside that task. Overly broad credentials or an unrestricted destination could expose information from unrelated properties even when the summary itself is correct.

The run record should therefore show which authority applied, what information was accessed and where the result went. A record that the schedule fired leaves those questions unanswered.

Move oversight to the policy

People should define the reporting scope, audience and exception rules once, then review changes to those decisions. Routine nightly reports can proceed within that policy. Adding a property, changing the service account or widening the audience deserves a separate authorization decision.

Our agent-update review asks how changes affect the use of existing access. Scheduled work extends that concern to the identity selected when no user is present.

For WTK, the useful design question is whether the compiled deployment preserves that connection from trigger to account to recorded effect. That would support higher-level human oversight while keeping each automated run within an explicit scope.