Can Agents Hold Production Deploy Authority?

Last quarter I asked the same one-line question to seven customer security teams.

"Can an agent hold production deploy authority?"

The answers split completely. Three said no in principle, two said conditionally yes, two said we already do. The reason the same question gets different answers is four organizational variables.

This post is those four variables and the boundary pattern we saw across the seven.

The four variables

Variable 1 — Are decision and execution separated?

The most decisive. Is the decision to deploy to production (should this code go live) the same act as the execution of the deploy (the actual command), or different acts?

Orgs that have separated them can give an agent execution only (humans decide). Orgs that haven't end up giving an agent decision + execution, which security review almost always blocks.

Variable 2 — Can permissions carry time/state conditions?

Is the permission model permanent (RBAC) or conditional (time, state, post-approval)? Granting an agent production permission on a permanent model creates a 24/7 deploy-capable agent — which security teams almost always reject.

A conditional model lets the agent operate only inside a narrow window like within 30 minutes of PR approval, only on staging-passed commits, only between 09:00–18:00 KST. This passes review.

Variable 3 — Is audit in the same schema as humans?

Are agent actions logged into the same audit trail with the same schema as human actions? Or to a separate system?

Same schema → post-incident audit is natural. Who (human or agent), what, when answered in one query. Separate → reconstructing causality becomes manual archaeology — security has grounds to refuse.

Variable 4 — Are agent decisions deterministic?

Does the agent give the same output for the same input, or is it non-deterministic? LLM-based agents are inherently non-deterministic. A non-deterministic agent with production authority creates non-reproducible actions.

Fix: keep the non-deterministic model, but wrap decisions in deterministic rules. Model proposes candidate actions, rules verify and execute.

Why the seven split

Case | Decision/Exec split | Conditional perm | Same audit schema | Deterministic wrap | Outcome
─────┼─────────────────────┼──────────────────┼───────────────────┼────────────────────┼─────────
A    |        X            |        X         |         X         |         X          | reject
B    |        X            |        X         |         O         |         X          | reject
C    |        O            |        X         |         O         |         X          | reject
D    |        O            |        O         |         O         |         X          | conditional
E    |        O            |        O         |         O         |         O          | yes
F    |        O            |        O         |         O         |         O          | already running
G    |        O            |        O         |         O         |         O          | already running

All four O — realistically possible. Three — conditional (only certain service tiers, etc.). Two or fewer — almost always rejected.

The boundary we recommend

                  Human                            Agent
                  ─────                            ─────
Generate options   O (options A or B)              O (proposes A,B,C,D)
First evaluation   O (which is better)             O (scores them)
Approval           O                               X  (the most important boundary)
Execution          X (tedious)                     O (with credential verification)
Post-review        O                               X (no self-review)
Revocation         O                               X (no self-revocation)

This single table is the boundary the seven cases converged on. Approval stays human, execution goes to the agent, post-review and revocation stay human. Hold those three for humans and the rest can move to the agent with audit passing.

So the answer — conditionally yes

There's no single answer. Conditionally yes is correct, and the conditions are the four variables. If only two or fewer are met, the work isn't to grant the authority — it's to fill the variables first.

What we advise against

The pattern of ignoring all four variables and adopting fast — usually for demos. The demo passes; three months into production an incident occurs; that incident becomes the security team's grounds to reject all future agent adoption. One incident closes the next five years of possibility.

For CIOs, CISOs, and platform leads currently deciding the authority boundary for AI agents, the decisive check is not which model the agent uses but whether the four variables (decision/execution split, conditional permissions, same audit schema, deterministic wrapping) are in place at the org. Models can be swapped. Permission models can't.