What Is Stateful Governance?

What is stateful governance?

Yuxiang Peng (Purdue University) and Xiaodi Wu (University of Maryland) set out the problem in Stateful Governance for Concurrent Agentic Systems (arXiv, August 2026). Agents now issue refunds, reserve inventory and initiate transfers, and "These workflows require governance over effects, not only over model outputs." Yet "Existing safeguards often decide whether an action is allowed from the information available when the action is requested."

A stateless policy reads only the request: deny any transfer above 10 credits. A stateful policy reads state the governed system maintains: deny the transfer if the team's spend over the last 24 hours plus this amount exceeds the team's limit. Once a policy reads state, the decision and the effect have to be protected together.

The paper names two failures. Stale authorization is when "the system acts on an allow decision after the state that justified it has changed." Stale approval is the slow form: a person approves an action that was valid when requested, but other actions consume the budget before the approval resolves. The authors' correctness condition, policy-state serializability, requires "committed effects to be explainable as authorized against the policy state immediately before they occur."

How stateful governance works

The paper's minimal example: a team has spent 9 credits of a 10-credit daily limit, and two agents each transfer 1 credit from different accounts. A request-context integration looks like this:

spent = budget.spent(team, window)
decision = policy_engine.check(req, {"spent_24h": spent})
if decision == "allow":
    db.commit_transfer(sender, receiver, amount)
    budget.add_spend(team, amount)

Both requests read 9, both are allowed, and the team ends at 11. The account writes don't overlap, so ordinary write-conflict detection sees nothing. The paper calls this a policy-induced conflict: one operation's effect writes state that another operation's policy has already read.

The fix is to name the shared state. In the authors' MasuGate runtime, the provider that owns the budget declares contracts like these, from the paper's Figure 5:

view budget.spent(team, window)
  scopes { team-budget:{team} }
  role consumed_capacity

view budget.limit(team)
  scopes { team-budget:{team} }
  role capacity_limit

effect transfer(sender, receiver, amount, team)
  reads team-budget:{team}
  writes team-budget:{team}
  idempotency request_id
  enforcement transaction | reservation

Because the policy's read and the effect's write map to the same scope, the runtime locks, validates or reserves that scope from policy evaluation through commit. Transaction mode evaluates and commits inside one provider transaction. Reservation mode sets capacity aside escrow-style, so a pending approval keeps its basis while unrelated work proceeds. Policies stay separate, reviewable programs. A hand-written transaction around one fixed policy also works, but it "moves policy logic into trusted provider code."

Why stateful governance matters in real-time systems

Concurrent agents make the check-then-act window routine. A prompt, the paper notes, "can ask an agent to respect a budget or wait for approval, but it does not create an enforcement boundary around the effect or the state that justifies it." An allow at request time describes the state at request time, which under concurrency is not the state at commit. The same shape appears in refund caps and quota counters, covered in race conditions between AI agents.

The guarantee has limits. It requires complete mediation: "Direct database writes, administrative scripts, or alternate tools that mutate the same policy state are outside the guarantee" unless they use the same contracts. And external APIs that cannot join a database transaction need a separate protocol, which the authors leave to future work.

Where the policy state lives decides what can be guaranteed. For budgets, per-agent limits, holds and approval records held in Tacnode, the policy read and the effect's write can share one transaction, so two agents cannot both commit past the same limit. For state another system owns, the policy check gets accurate context, and the commit-time guarantee comes from the system that holds that ledger.

FAQ