OpenKedge: Governing Agentic Mutation with Execution-Bound Safety and Evidence Chains

OpenKedge is a protocol that ensures safe, scalable agentic systems by replacing direct API mutations with a governed process of declarative intent proposals, execution-bound contracts, and cryptographically linked evidence chains for verifiable auditability.

The Gist

Imagine you are the manager of a massive, busy construction site. In the past, you hired human foremen who knew the rules, checked the blueprints, and knew exactly which walls were load-bearing before they picked up a hammer.

Now, imagine you replace those foremen with a swarm of incredibly fast, super-smart, but slightly hallucinating robots. These robots can build things faster than anyone, but they sometimes get confused. They might think a wall is empty space when it's actually holding up the roof, or they might try to demolish a building that is currently hosting a party.

In the old world (traditional software), if a robot said, "I'm going to delete that database," the system would just say, "Okay, here's the hammer, go ahead!" The system trusted the robot blindly. If the robot was confused, the building collapsed.

OpenKedge is a new way of running that construction site. It doesn't trust the robots' immediate commands. Instead, it introduces a strict, magical rulebook that changes how work gets done.

Here is how OpenKedge works, broken down into simple concepts:

1. The "Intent" vs. The "Action" (The Wish List)

In the old system, a robot would shout, "Delete Database X!" and the system would immediately do it.
In the OpenKedge system, the robot has to first write a formal "Intent Proposal."

• The Analogy: Instead of shouting "Demolish!", the robot has to fill out a permit application: "I intend to remove Database X because I think it's unused."
• The Magic: The system doesn't let the robot pick up the hammer yet. It pauses and looks at the application.

2. The "Context Check" (The Detective)

Before the permit is approved, a super-smart detective (the Policy Engine) checks the robot's claim against the entire current state of the construction site.

• The Analogy: The detective checks the blueprints and the live camera feeds. "Wait," the detective says, "You think Database X is unused, but our live traffic logs show it's currently serving 10,000 users. Also, a human manager just updated it five minutes ago."
• The Result: The robot's request is rejected before any damage is done. The system knows the robot was hallucinating or acting on old information.

3. The "Execution Contract" (The Leash)

If the robot's request is valid (e.g., "I want to delete a truly empty test server"), the system doesn't just say "Go." It issues a Contract.

• The Analogy: Imagine giving the robot a temporary, magical leash. This leash says: "You are allowed to touch ONLY that one specific server. You have 10 seconds to do it. You cannot touch anything else. If you try to touch the roof or the power grid, the leash instantly turns to steel and stops you."
• The Safety: Even if the robot suddenly goes crazy and tries to delete the whole city, the "leash" (the contract) physically prevents it. The robot is trapped in a tiny, safe sandbox.

4. The "Evidence Chain" (The Unbreakable Diary)

Every single step of this process is written down in a special, unchangeable diary called the Intent-to-Execution Evidence Chain (IEEC).

• The Analogy: It's like a security camera that doesn't just record the video, but also records why the decision was made. If something goes wrong, you can rewind the tape and see:
  1. The robot made a request.
  2. The detective checked the facts.
  3. The detective said "Yes, but only for this one thing."
  4. The robot did the job within the leash.
• The Benefit: You can never say, "We don't know what happened." The system has a perfect, mathematical proof of exactly what happened and why.

Why is this a big deal?

Currently, AI agents are like wild horses running through a china shop. They are fast and powerful, but they break things because they don't understand the context or the consequences.

OpenKedge puts a governor on the engine. It says:

"We love your speed and power, but you cannot touch anything unless you fill out a form, we check the facts, and we give you a tiny, temporary tool to do exactly one thing."

It shifts the safety from "hoping the robot is smart enough" to "making sure the system is smart enough to stop the robot if it gets it wrong."

In short: OpenKedge turns AI agents from reckless drivers into passengers in a self-driving car that has a super-brain, a seatbelt, and a black box recorder that never lies.

Technical Summary

1. Problem Definition

The paper identifies a critical architectural flaw in modern software systems as they transition to being operated by autonomous AI agents. Current systems rely on API-centric architectures where agents issue direct API calls to mutate state. This model assumes callers are deterministic, context-aware, and isolated, which fails in probabilistic agentic environments.

Key Failure Modes Identified:

• Contextual Blindness: API requests are executed in isolation, ignoring real-time system state, dependencies, or temporal constraints (e.g., deleting a database that appears "unused" but is actually critical).
• Multi-Agent Conflict: Concurrent actors (humans and AI) issue mutually exclusive updates without deterministic resolution, leading to state oscillation or corruption.
• Unsafe Mutation: Probabilistic agents may generate hallucinated or syntactically valid but semantically destructive actions.
• Unbounded Authority: Execution relies on persistent, broad credentials, allowing agents to exceed their intended scope if they hallucinate or are compromised.
• Lack of Traceability: Traditional audit logs capture what happened (API calls) but not why or how the decision was made, making post-incident reasoning impossible.

2. Methodology: The OpenKedge Protocol

OpenKedge proposes a paradigm shift from passive execution to active governance. It redefines state mutation not as an immediate consequence of an API call, but as a governed lifecycle process.

Core Architecture Components

1. Intent-First Mutation:

   • Agents do not call APIs directly. Instead, they submit declarative intent proposals (structured outcomes).
   • The system decouples "what" is desired from "how" it is executed.

2. Governance Layer (Context + Policy):

   • Contextual Expansion: Proposals are enriched with real-time global context (resource status, dependency maps, traffic metrics).
   • Policy Evaluation: A deterministic policy engine (using Cedar language) evaluates proposals against authorization rules, conflict resolution logic, and operational constraints.
   • Conflict Resolution: Uses a multidimensional arbitration function combining Static Authority (role), Dynamic Trust (performance history), and Temporal Recency (freshness of data) to resolve competing intents deterministically.

3. Execution Contracts & Bounded Identity:

   • Approved intents are compiled into Execution Contracts ($C = (a, r, t)$), strictly defining the permitted action ($a$), resource scope ($r$), and temporal validity ($t$).
   • Task-Oriented Identities: Execution is enforced via ephemeral, short-lived credentials (e.g., AWS STS tokens) scoped strictly to the contract parameters. This physically prevents privilege escalation or out-of-scope actions, even if the agent hallucinates.

4. Intent-to-Execution Evidence Chain (IEEC):

   • A cryptographically linked, append-only log that records the full lineage of a mutation: Intent $\to$ Context $\to$ Policy Decision $\to$ Contract $\to$ Execution Outcome.
   • This transforms mutation into a verifiable, reconstructable process, enabling deterministic auditability.

5. Event-Sourced State Derivation:

   • System state is not overwritten in place. It is derived functionally ($S_n = f(E_{\le n})$) from the immutable event log, ensuring determinism, auditability, and replayability.

3. Key Contributions

The paper introduces three primary technical contributions:

1. Intent-Governed Mutation Protocol: A framework that restructures state mutation by decoupling intent from execution. It ensures only semantically valid, conflict-free, and policy-approved mutations are admitted.
2. Execution-Bound Safety via Contracts: The introduction of execution contracts enforced by ephemeral, task-oriented identities. This guarantees that physical execution remains strictly bounded by the approved scope, mitigating the risks of hallucinated or adversarial agent behavior.
3. Intent-to-Execution Evidence Chain (IEEC): A cryptographic lineage that binds intent, context, policy decisions, and outcomes into a unified event structure. This establishes a new invariant: every mutation must be both execution-bounded and explainable in lineage.

4. Results and Evaluation

The authors implemented a reference system named Riftront and evaluated it in two domains: a multi-actor operational platform and a high-impact AWS cloud infrastructure simulation.

• Conflict Arbitration: In high-concurrency scenarios involving humans and agents, OpenKedge deterministically resolved conflicts based on authority and trust scores, rejecting unsafe agent intents when human operators were present or when trust scores were low.
• Safety Under Hallucination:
  • Scenario 1: An agent attempted to terminate a "unused" compute instance. OpenKedge detected active downstream dependencies via the context layer and blocked the mutation.
  • Scenario 2: An agent proposed scaling down a cluster during peak traffic. The policy engine intercepted this context-blind request, preventing service outage.
  • In all cases, unsafe mutations were "caged" at the execution boundary before any state change occurred.
• Performance & Determinism:
  • The system processed 3,200 mutations per second with no throughput degradation.
  • Policy evaluation latency averaged 11 ms, with state derivation latency under 30 ms (99th percentile).
  • Repeated runs with identical workloads produced strictly identical event logs and system states, proving the elimination of observable race conditions.

5. Significance and Impact

OpenKedge addresses the "existential challenge" of operating AI agents at scale by moving safety from a reactive filtering problem to a preventative, execution-bound guarantee.

• Paradigm Shift: It moves the industry from "trust but verify" (API-centric) to "verify then execute" (Governance-centric).
• Scalability: By using event sourcing and lock-free coordination, it scales to enterprise levels without the bottlenecks of distributed locking.
• Auditability: The IEEC provides a mathematical proof of why a system state changed, transforming infrastructure management from opaque operations into deterministic, reconstructable decision artifacts.
• Generalizability: While demonstrated in DevOps and Cloud, the protocol applies to any domain requiring safe, concurrent state mutations under partial information (e.g., IoT, distributed ledgers).

In conclusion, OpenKedge establishes that for agentic systems to be safe, the system governing them must be more robust than the agents themselves, ensuring that execution is permitted if and only if it is bounded in action and explainable in lineage.