From Approval to Immutable Execution, Trace, and Monitoring: Immutable Agent Execution for AI That Acts in the World

🎥 The YouTube version is also available:

How to Safely Connect AI Agents to Business Operations | Chinoba Decision Runtime Edge

Books: Runtime Al Governance Practical Guide: Dynamic Al Governance Design through Knowledge Flow, Trust Engine, and Decision Trace

AI agents are no longer limited to generating text.

They search internal documents, query databases, send email, update business systems, call external APIs, and delegate work to other agents. As AI gains the ability to act in the world, the central question is no longer simply how intelligent it is.

Under whose authority, on what evidence, and for what purpose did it act?
Can that action be verified afterward and stopped if it becomes anomalous?

Traditional AI governance often leans toward prior approval. But if people must approve every agent action, AI loses its autonomy and speed. Conversely, if agents receive broad permissions and are left to post-hoc review alone, incorrect operations and authorization violations can go unnoticed.

This article outlines an approach that moves beyond that binary: combining Immutable Agent Execution, Decision Trace, continuous monitoring, and monitoring multi-agent systems.

The Limits of Approval-Centered Governance

Human approval remains necessary for high-risk actions. AI should not independently execute money transfers, contract execution, public communications, permission changes, or actions involving medical or safety risks.

But making every action subject to approval creates its own problems.

• Even repetitive, low-risk work incurs delays.
• People cannot carefully examine an excessive volume of approval requests.
• AI becomes little more than a mechanism for proxying human operations.
• Exceptions that could not be anticipated in advance stop execution.
• The system becomes less able to learn from what happens after execution.

AI agents need an operating model that is neither complete freedom nor complete prior control.

Agents act autonomously inside defined boundaries.
Everything is traced and continuously monitored, and intervention occurs when behavior deviates.

Under this model, the human role shifts from approving each individual action to designing boundaries, exceptions, intervention conditions, and accountability.

What Is Immutable Agent Execution?

The phrase “immutable code generation” may suggest preventing AI-generated application source code from changing once it has been created. But for an AI agent that acts outside itself, the thing that should be immutable is usually not the application code itself.

What should be immutable is the execution package finalized immediately before the agent uses an external tool or API to act.

An execution package contains information such as the following.

An AI can revise its proposal before execution. But once the execution package has been evaluated by policy and fixed through a signature and hash, the AI cannot silently substitute the recipient, parameters, authority, or tool.

This is not a mechanism for restraining AI. It is a mechanism for separating an AI’s autonomous proposals from responsibility for actions in the external world.

Proposals may remain mutable.
But execution that affects the world must be fixed and verifiable.

The Execution Flow: Separate Permit, Trace, and Monitor

Immutable Agent Execution can be implemented through the following flow.

flowchart TD
  A["AI Agent: Plan / Proposal"] --> B["Execution Contract"]
  B --> C["Boundary & Policy Gate"]
  C -->|"Permit"| D["Sign & Hash"]
  D --> E["Isolated Tool Execution"]
  E --> F["External API / System"]
  B --> G["Decision Trace"]
  C --> G
  E --> G
  G --> H["Runtime Monitoring MAS"]
  H -->|"Normal"| I["Continue"]
  H -->|"Anomaly"| J["Throttle / Isolate / Stop"]
  J --> K["Human Escalation"]

The important point is not to place Permit, Trace, and Monitor within one agent.

• Permit: Evaluates predefined boundaries and policies to determine the allowable scope of execution.
• Trace: Records inputs, evidence, decisions, execution, and outcomes.
• Monitor: Continuously observes the trace and detects deviations from normal behavior or signs of risk.

Execution agents hold the limited permissions needed for their business tasks. Monitoring agents should, in principle, observe traces with read-only access. Even a coordinator that can request stopping or isolation should not have broad authority to modify external business data.

This separation of duties prevents an execution agent from becoming the system that justifies its own actions.

Decision Trace Is Broader Than an Audit Log

An ordinary audit log records who did what and when. A Decision Trace also records why a particular action was selected.

For external execution by an AI agent, the system should record at least the following.

With this trace, an incident need not end with the abstract statement that “the AI failed.” Teams can investigate whether evidence was stale, permissions were too broad, a policy was missing, or a tool constraint was too weak.

Decision Trace is not only for accountability. It is operational data that enables anomaly detection, rollback, recurrence prevention, and rule improvement.

The Goal of Monitoring Is Not Approval, but the Adjustment of Autonomy

In monitoring-centered governance, people do not decide whether each action is allowed. The agent is allowed to act within its assigned boundaries, while the degree of its autonomy changes according to observed behavior.

A coordinator can manage states such as the following.

The objective is not to give agents a simple allow-or-deny decision. It is to dynamically control the level of autonomy according to risk and observed behavior.

Monitoring Multi-Agent Systems

If a single monitoring AI observes everything, it can itself become a black-box governor. A more effective design separates monitoring by responsibility: multiple agents observe the same trace from different perspectives.

Not every decision needs to be made by an LLM. The control mechanisms should be selected according to the task.

• Check explicit limits, expiration, and permissions with deterministic rules.
• Observe frequency, failure rate, and target expansion through statistical anomaly detection.
• Use LLMs to assist with semantic contradictions in documents or unnatural purposes.
• Require human confirmation for high-risk intervention and policy changes.

The coordinator of a monitoring multi-agent system should not be the AI that makes the final judgment about what is correct. It should serve as a control plane that integrates observations and transitions operating states: Normal, Observe, Ask, Throttle, Isolate, and Stop.

Immutability and Data Retention: Do Not Put All Data on a Blockchain

Hash chains, digital signatures, append-only logs, WORM storage, external timestamps, and blockchain can all make traces harder to tamper with.

But immutability does not mean that full prompts, personal information, customer data, or confidential information should be stored directly on a blockchain or in permanent retention. That would conflict with retention limits, deletion, privacy, and confidentiality requirements.

A practical design separates data content from verification evidence.

When deletion is required, delete the data content or destroy its encryption key, while retaining only minimal evidence in the trace that records when and under which rule the deletion occurred.

Blockchain is particularly useful when multiple organizations—such as an enterprise, vendors, auditors, and regulators—need to verify the same execution evidence. For a single enterprise, signed append-only logs and WORM retention are often sufficient.

What This Approach Can and Cannot Protect Against

Immutable Agent Execution and trace monitoring are powerful, but they do not make AI judgment correct in every case.

This is therefore not a technology that makes AI correct.

It is a technology that makes it difficult to hide what evidence an AI used, under what authority it acted, and what external effect it produced—and makes it possible to observe and stop that behavior when necessary.

Implementation Priorities

There is no need to introduce blockchain or a complex monitoring multi-agent system from the beginning. The design should mature in stages according to the strength of the agent’s external effects.

1. Minimize tool permissions: Limit the APIs, data, targets, and frequency available to an agent.
2. Design the Decision Trace: Retain inputs, evidence, decisions, execution, outcomes, and version information.
3. Define Act/Ask/Stop: Make decision and execution boundaries, as well as conditions for human handoff, explicit.
4. Introduce immutable execution packages: Begin by adding signatures, hashes, expirations, and constraints to high-risk actions.
5. Automate monitoring and intervention: Implement Throttle, Isolate, and Stop for anomalous behavior.
6. Expand to monitoring multi-agents: Divide responsibility for monitoring policy, behavior, data, security, and outcomes.
7. Consider cross-organizational trace sharing: Use permissioned ledgers or blockchain only when needed.

Conclusion: Do Not Stop AI Autonomy—Make It Observable

What is needed in an era when AI agents act in the world is not a system in which people approve every action.

What is needed is a system that keeps AI proposals flexible while fixing execution into immutable units, tracing evidence, authority, and outcomes, allowing monitoring multi-agents to detect deviation, and reducing, isolating, or stopping autonomy when necessary.

Permit within Boundary → Trace Everything → Monitor Continuously → Intervene on Anomaly → Learn from Outcome

This is not governance designed merely to stop AI. It is a Runtime OS that enables AI to participate safely in society and business, learn from failure, and take on greater responsibility over time.

References

• NIST AI Risk Management Framework
• NISTIR 8202: Blockchain Technology Overview
• OWASP: Prompt Injection

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance