OWASP's Top 10 for LLM Applications has a name for an agent that can do more than its task requires: Excessive Agency. A coding agent running on a schedule, triggered by a ticket, acting with nobody at the keyboard, is the purest form of it. It has the capability, the autonomy and the automatic trigger all at once.
Unattended agents are not a future scenario. Teams already run them for on-call triage, dependency updates and backlog work, because the productivity case is obvious. The security case is the one that tends to be made informally, in a hallway, as "it should be fine." That is not a standard you would accept for any other system with production access.
Before approving an agent to run unattended, a CISO should be able to answer a short list of questions with evidence rather than intentions. The checklist below is organized the way an approval review should run, and each item is mapped to the OWASP category it serves.
Unattended changes the risk, not just the speed
The instinct is to treat a headless agent as an interactive one that is simply faster. It is a different risk class.
Interactive approvals assume a human is watching the terminal, ready to catch the odd action. Remove the human and that assumption is gone, but the approval prompt is often still there, now with nobody to answer it, so it either blocks forever or gets switched off. Worse, headless agents are usually triggered by untrusted input: a ticket someone filed, an email that arrived, a pull request from outside. The thing that starts the run is exactly the thing an attacker can shape. Unattended operation raises both the likelihood and the blast radius at the same time.
The checklist
Ten requirements, grouped. For each, the question is not "do you intend to?" but "can you show me?"
Identity and credentials
- The agent holds no long-lived secrets. Credentials live outside its process, environment, files and logs. Maps to the sensitive-information-disclosure risk. Evidence: run
envin the agent runtime and show it is empty of keys. - Credentials are scoped per task and destination, short-lived, and revocable. Maps to Excessive Agency. Evidence: show the scope and lifetime of a credential issued for one run.
Actions
- Tools, CLIs and databases are governed by verb-level policy, not command-name allowlists. Maps to Excessive Agency. Evidence: show a destructive verb being denied.
- Destructive actions are blocked before they execute, on every path the agent can take. Evidence: show the block happening ahead of the action, not a warning after it.
Inputs and supply chain
- MCP servers and skills are pinned to known versions and inventoried. Maps to the supply-chain risk. Evidence: the version list for a given run.
- Package installs run under policy, not with open network access. Maps to the supply-chain risk.
- Untrusted input is treated as untrusted. A ticket or email that triggers a run cannot silently widen what the run may do. Maps to the prompt-injection risk.
Evidence
- Every request is audited to storage you own, not a vendor dashboard. Maps to the inadequate-monitoring risk. Evidence: point at the bucket and the retention.
- Every action is tied back to the trigger that started the run, so a ticket-triggered write is reviewable after the fact.
Containment
- You can stop any run instantly without destroying its evidence, and change a policy on running sessions without a restart. Evidence: stop a run and show the volume preserved.
Where Marshal is the answer to one of these, the claim stays at the level stated publicly: the agent never holds the credential, actions are judged by verb and target, audit lands in your own storage, and headless runs use pre-declared, brokered grants with escalation to a live human.
How to run the evaluation
Do not approve on a slide deck. Run a two-week pilot against the checklist, with a red-team prompt set that deliberately tries to make the agent exceed its task: injected instructions in a ticket, a request that needs a credential it should not have, a destructive action aimed at production. Watch what the controls do, and keep the results.
The pilot's output is not a feeling that it went well. It is a record: here is what the agent tried, here is what was blocked, here is where every request went.
What good looks like in a board update
When the checklist passes, a CISO should be able to say three plain sentences to a board: our agents cannot read a long-lived secret, and we can prove it. They cannot run a destructive action without it being blocked or approved, on any path. And every action they take is recorded in storage we own, tied to the person or ticket that triggered it. Three sentences, each backed by evidence, is the bar for letting anything run unattended.
A headless agent is not an interactive one that is merely faster. It is Excessive Agency by design: capability, autonomy and an automatic trigger, often fed by untrusted input. Before approving one, require evidence against a checklist, run it against a red-team prompt set for two weeks, and keep the record. The question is never whether the team intends to be careful. It is whether they can show you.
For why the controls have to sit outside the agent in the first place, see the false choice between banning agents and letting them run →
Marshal keeps credentials out of the agent, judges actions by verb and target, records every request to your own storage, and runs headless agents with pre-declared grants and live escalation. Book a demo →