KedgeFlow: A Programmable Control Plane for Enterprise AI Agents

What it claims

KedgeFlow targets three specific failure modes of agents that hold production credentials:

• Parameter substitution. A grant approved for draining a test node is presented with a production database node as the target.
• Concurrent reuse. Two tasks present the same permission, and separate gateway checks both pass.
• Lost-response retries. A timeout leads to a duplicate non-idempotent call.

The fix is architectural, modelled on OpenFlow's controller/switch split. The agent never holds target mutation credentials. A privileged gateway holds them and only acts on a signed grant bound to the exact action, target and parameters. Positioning matters for adoption: KedgeFlow does not replace a policy engine or token exchange. Cedar and RFC 8693 are named as pluggable components. KedgeFlow specifies how their decisions stay consistent from approval through execution.

How it works

Three planes split nine logical roles. Roles may share processes, but they then share compromise risk.

flowchart LR
  subgraph Agent["Agent Plane (untrusted)"]
    A[Agent Adapter<br/>freezes proposal q]
  end
  subgraph Control["Control Plane (trusted)"]
    AC[Admission + Evidence] --> GA[Grant Authority<br/>signed G, root ρ]
    OS[Outcome Service]
  end
  subgraph Enf["Enforcement Plane (privileged)"]
    GW[Gateway] --> RA[Resource Adapter<br/>holds target creds]
  end
  ST[(etcd authority store)]
  A -->|proposal| AC
  GA -->|grant G| A
  A -->|request + G| GW
  GW <-->|atomic claim of ρ| ST
  RA -->|guarded call| T[Target]
  RA -->|result or Unknown| OS

The gateway runs a fixed order of steps:

1. Authenticate the caller.
2. Verify G against the exact request.
3. Atomically claim the execution root ρ in shared state.
4. Exchange for a target-only credential.
5. Re-authorize dispatch against current policy and ownership.

Two details the summary omits:

• One allowance across grant versions. Root ρ is shared by all replacement grants ("generations"). Reissuing an unclaimed grant or retrying a request never creates a second allowance.
• Uncertain outcomes stay consumed. If the outcome is uncertain, the gateway records Unknown. A later query correlates observations with that attempt but never redispatches.

A versioned Consequential Tool Descriptor records the following, and its digest is bound into the grant so a substituted descriptor fails validation:

• action and parameter schemas
• resource-incarnation rules, which distinguish a recreated resource from an earlier one with the same name
• adapter contract: guard, fencing, commit point and query behaviour
• consequence tier
• conflict domain
• compensation availability

The paper is explicit that an operation ID alone does not make a check atomic with the mutation. A shell tool also may not restrict execution to fixed actions.

Evidence

The setting is a three-member etcd cluster on one host, synthetic authentication and authorization inputs, and a mock target that atomically checks its guard and rejects stale requests.

Two caveats on these results:

• The adversary is a scripted component that deterministically emits the redirected request. The tests measure the execution boundary, not LLM prompt-injection success rates.
• Admission and identity are fixtures. Outcome reconciliation is a library tested separately with scripted observations, not a deployed query service.

Limits

• The trust base is large. It includes policy administration, issuer keys, admission, the etcd store, gateway, credential broker, resource mapping and target-side checks. A compromised issuer or a permissive policy defeats the guarantees. The paper shows this directly: a permissive policy authorized an undesirable effect.
• Complete mediation is your job. Direct APIs, shell credentials, remote sessions, subagents, admin clients and inherited tokens must be inventoried and restricted. An agent-side hook or a localhost-only gateway does not close those routes.
• No cross-allowance coordination. Two agents each approved to drain a different node of a three-node service that needs two available nodes would both succeed. Shared reservations to prevent this are proposed but not implemented.
• Untested:
• distributed reservations
• enforcement of every production access route
• native crash recovery
• exactly-once effects at real targets
• interoperability between independent implementations
• Truncated page. The fetched text stops at the start of Section 3. The message formats, the formal property statements (Section 4) and full evaluation details (Section 5) were not available. No code repository, install steps or licence appear in the fetched text.