Simply put, background agents run on a schedule or a trigger, as opposed to agents that only work when directly prompted.
For example, a sync job fires at 2 a.m., a monitoring agent reacts to an alert, a workflow picks up where a teammate left off. That type of automation is what makes background agents so valuable, but they also raise the question security teams ask before one of these ships: if nobody is sitting there to approve access, how does the agent get in, and what stops it from becoming an over-permissioned service account?
Arcade.dev’s answer is to decouple authorization from the live session, so a background agent acts under real, delegated user authority without a human in the loop at runtime.
Service account considerations
An interactive agent can pop an OAuth consent screen and wait for the user to click approve. A background agent has no one to click. The tempting shortcut is to give it a service account with broad, static credentials and let it run. That approach can get you up and running quickly, but carries longer-term downside. One credential holds broad permissions, no action ties back to a specific user, and a single compromise exposes everything the account can touch. It works in a demo and quietly becomes a major liability in production.
Authorization is decoupled from the live session
Arcade brokers the full OAuth lifecycle: token acquisition, refresh, rotation, and storage. Tokens live in encrypted token storage and never reach the model. Because Arcade owns that lifecycle, a user can grant delegated authorization once, and the background agent can act later under that same authority. The token refreshes on its own, so that job that ran at 2 a.m. doesn’t fail because something expired overnight. The agent still acts as a specific user, scoped to the specific tool and action, never as a shared identity.
Permissions are checked at the moment of action, not at setup
This matters more for background agents than for interactive ones, because real time passes between when authorization is granted and when the agent acts. Arcade evaluates permissions just-in-time at execution, evaluated on every action through Arcade’s contextual access hooks, which you can wire to your identity provider and entitlement systems. If the user’s role changed, their access was downgraded, or you revoked them entirely, the background agent loses that access instantly on its next call. An authorization that was valid when the job was scheduled can be invalid by the time it runs, and Arcade enforces the current answer, not the stale one.
When consent is genuinely needed, the agent waits instead of faking it
Sometimes a background action needs authorization that hasn’t been granted yet, like a new scope or a first-time connection to a system. Arcade doesn’t paper over that gap with a service account. It pauses the action that needs access and issues a flexible authorization link the user can complete out of band, through whatever channel fits the workflow. Once the user grants it, the agent proceeds. The unattended job stays blocked on the one action that needs a human decision, rather than escalating its own privileges to keep moving.
None of this costs you the audit trail. Every background action stays attributable to the user it acted on behalf of, with the delegated scope, the inputs and outputs, and the policy decision applied, all streamed to your security information and event management (SIEM) system through OpenTelemetry. An agent running while you sleep is as accountable as one a person is watching.
The short version: background agents don’t change how Arcade works, they make it matter more. Authorization is delegated, per-user, and re-checked at the moment each action runs. The token lifecycle is managed for you, credentials stay away from the model, and nothing falls back to a standing key. The agent runs on its own schedule, still only doing what its user is allowed to do.
