Why approval should expire.

People tend to treat approval as a button.

An agent asks to do something. A person clicks approve. The system moves on.

That is fine for low-stakes workflows. It is not enough for AI agents that can touch production systems, customer records, repositories, financial workflows, support queues, or external communications.

The uncomfortable question is not whether a human approved something. The question is what the approval still allows five minutes later.

Approval reuse is where governance gets sloppy

Imagine an agent asks to deploy a change to a production-adjacent service.

A reviewer approves it because the diff is small, the target is known, and the action is happening during an allowed window. The first execution succeeds.

Now the agent retries. Or the wrapper replays the request. Or another action looks similar enough to inherit the same approval. Or a later session uses the same command text but a different target. Or the branch now contains a different commit.

Was the original approval still valid?

Most systems do not answer that cleanly. They store an approval event and then rely on convention.

BAF, short for Bounded Action Firewall, exists because convention is not a control.

The approval should become a lease

OSuite does not treat approval as a permanent badge. It turns approval into an Action Gate Lease.

The lease says what is allowed, under which boundary, for how long, by which actor, against which target, and with which proof.

That means approval is not merely:

approved = true

It is closer to:

{
  "action_hash": "sha256:...",
  "actor": "codex-runtime",
  "target": "production/payment-api",
  "policy_version": "enterprise-strict:2026-07-16",
  "scope": "single-use",
  "expires_at": "2026-07-16T18:15:00Z",
  "reuse": "denied unless action fingerprint matches",
  "closure_required": true
}

This is the difference between "someone approved it" and "this exact action is allowed under this exact boundary."

Why expiration is not bureaucracy

Buyers sometimes worry that strict approval controls will slow their teams down.

That concern is real. A governance system that requires human approval for everything becomes a tax, and users will route around it. OSuite should not be a machine that converts every action into paperwork.

But expiration is not paperwork. It is blast-radius management.

An approval is based on context. Context changes. The code changes. The target changes. The environment changes. The reviewer may have approved during a maintenance window. The policy may have changed. The agent may have shifted from local work to production impact.

If approval does not expire or narrow itself, it becomes standing permission.

Standing permission is exactly what many organizations are trying to avoid when they adopt runtime governance in the first place.

Same text, different consequence

Approval reuse is especially dangerous when systems rely on text.

The same command can carry different consequence depending on where it runs:

npm publish

In a private test package, this may be harmless. In a public production package, it can affect customers immediately. In a compromised environment, it can become supply-chain damage.

BAF does not ask whether the text is familiar. It asks whether the action object and its boundary still match the lease.

If the target changes, the lease fails. If the policy version changes, the lease can fail. If the actor changes, the lease can fail. If the time window closes, the lease can fail. If the action hash changes, the lease fails.

That is not friction for its own sake. It is what makes approval meaningful.

The firewall is not only a block button

The word "firewall" can make people imagine a hard allow or deny rule.

BAF is more nuanced. It can support several lanes:

• —allow once and close with evidence;
• —allow within a narrow time window;
• —require approval again if target, actor, or policy changes;
• —require dual approval for sensitive classes;
• —block actions that cannot produce enough evidence;
• —expire stale approvals automatically;
• —preserve an exception reason when a business owner accepts risk.

The product should make this feel simple. The buyer does not need to see every lease field. They need to know whether the approval can be reused, when it expires, and what would invalidate it.

Why this matters to executives

Executives do not buy BAF because they want another policy object.

They buy the outcome: an agent cannot turn one human click into unlimited permission.

That line is easy to understand in a boardroom. It is also easy to defend after an incident.

"The action was approved for one use, against this target, under this policy, before this expiry, and the proof bundle shows whether it closed correctly."

That is a stronger statement than "we had human oversight."

The practical answer

If a buyer asks, "Why not just approve the agent once and let it keep working?" the answer is:

Because approval without a boundary becomes permission.

BAF gives OSuite a way to preserve speed without pretending every approval should last forever. Agents can move quickly on routine work. Risky actions receive a lease. The lease makes the approval useful, narrow, and reviewable.

That is what runtime governance should feel like: not constant interruption, but controlled consequence.