When an AI agent can act, who decides what it is allowed to change?

An AI model can propose a patch, choose a tool, or recommend a deployment. That does not mean it should possess the final authority to change a repository, infrastructure environment, or canonical system state.

This is the central engineering question explored in my technical research preprint, CEOS Infrastructure as a Governed Transactional Assurance Substrate for Autonomous Software Engineering (CEOS-RP-001, v1.0).

Read the versioned research preprint: Zenodo DOI: 10.5281/zenodo.22991325

Author: Christian Serrano, Caivra Tech LLC

Publication date: September 26, 2026

Status: Technical research preprint; not independently peer reviewed.

The problem is bigger than a model's reasoning quality

Consider an agent that discovers an issue, generates a fix, runs tests, and proposes applying the change.

A useful result may still be unauthorized. Tests can pass against the wrong revision. Permissions can expire between planning and dispatch. An external API can time out after performing the requested effect. A merged commit can be mistaken for evidence that a system was deployed.

The agent's confidence is not an authority decision. A passing check is not a capability grant. A request to mutate state is not proof that the requested transition is admissible.

These are systems-engineering distinctions, not merely prompt-design considerations.

The architectural proposal: separate reasoning from authority

CEOS studies an architecture in which probabilistic intelligence participates in engineering while deterministic mechanisms govern consequential effects.

At a conceptual level:

1. Propose: An agent produces a candidate action and supporting rationale.
2. Resolve authority: A designated authority owner determines whether the proposed action is within the applicable scope.
3. Bind scope and state: Capabilities, exact target state, freshness constraints, and preconditions are made explicit.
4. Admit and execute: Only a permitted transition reaches the controlled effect boundary.
5. Validate and record: Results are checked against the intended transition and retained with provenance.
6. Reconcile uncertainty: If a timeout or partial failure leaves the external outcome unknown, the system does not simply assume success or retry without considering duplicate effects.

This is a research model, not a claim that every aspect of the full design is already enforced in a production system.

Several distinctions matter

1. Intent is not authorization

A user request, agent plan, or tool invocation can describe a desired outcome without supplying the authority to perform it. Authority should be resolved by the relevant governing mechanism, rather than inferred from the language of the request.

2. Evidence is not authority

A successful build, a green CI pipeline, and a clean code review are important evidence. They do not independently authorize merge, release, migration, or deployment. These remain separate decisions.

3. A candidate is not canonical state

A model-generated proposal should remain a candidate until the governing process admits it. Historical execution evidence must remain distinguishable from current live truth.

4. Time is part of correctness

Approval may have been valid when a plan was formed but no longer applicable when a consequential action is dispatched. A system that relies on stale permission or state assumptions can violate its own intended controls.

5. Unknown outcomes need reconciliation

Suppose an API call times out. Did the operation fail, or did the operation succeed while the acknowledgment was lost? Blind retries can duplicate effects. A transactional design needs an explicit strategy to classify and reconcile such ambiguity.

The testable research question

The research asks whether integrated enforcement of exact mutation, exact state, current authority, bounded capability, dispatch freshness, evidence, validation, and canonical disposition can improve assurance—or reduce the burden of integrating assurance mechanisms—relative to a correctly configured composite of existing technologies.

That is a falsifiable hypothesis, not an empirically demonstrated competitive advantage.

The paper outlines a formal systems architecture, security model, candidate invariants, and an adversarial evaluation program. Further work is needed to test the design and compare it with established approaches.

For engineers building autonomous workflows

A practical design review can start with questions like:

• Which component owns the final decision to permit an effect?
• Can a caller bypass that component through a different entry point?
• What happens if permissions change after planning?
• How does the system know it is acting on the exact intended revision?
• What happens after a timeout where the external outcome is unknown?
• Can logs distinguish a proposed change, an admitted change, and an observed effect?

These questions apply to coding agents, infrastructure automation, CI/CD orchestration, and other systems where model output has real consequences.

Read, cite, and review the research

Paper: CEOS Infrastructure as a Governed Transactional Assurance Substrate for Autonomous Software Engineering

Subtitle: Formal Systems Architecture, Security Model, and Falsifiable Research Program

Version: 1.0

• Archival preprint — Zenodo (version DOI)
• CEOS research publication repository
• CEOS-RP-001 supporting documentation
• Author ORCID

Citation: Serrano, C. (2026). CEOS Infrastructure as a Governed Transactional Assurance Substrate for Autonomous Software Engineering (Version 1.0). Zenodo. https://doi.org/10.5281/zenodo.22991325

Research integrity note: This article is an accessible summary of a technical preprint, not a report of independent peer review, completed comparative benchmarks, or established production deployment. The linked versioned preprint is the authoritative research artifact.