DEV Community: Christian Serrano

An AI Agent Was Authorized. Then the Permission Changed. What Happens Next?

Christian Serrano — Sat, 31 Oct 2026 04:35:39 +0000

An AI agent can be authorized at planning time—and still be unsafe at execution time

Imagine an autonomous agent receives permission to perform an action. It collects evidence, plans its steps, and prepares an external write.

Before that write occurs, something changes: a permission is revoked, the target resource changes, or the evidence used to admit the action is no longer applicable.

Should the original approval still be enough?

My technical preprint, Authority-Bound Execution for Agentic Systems: A Formal Architecture for Provenance-Validated Admission, Revocation Fencing, and Recoverable Effects (CC-RP-001, v0.5), investigates this problem as one of authority, provenance, time, and recoverability.

Read the paper: Zenodo DOI: 10.5281/zenodo.23823408

Author: Christian Serrano, Caivra Tech LLC

Preprint version: v0.5, October 30, 2026

Status: Public theoretical research preprint, not independently peer reviewed.

Why a valid approval can become insufficient

An action can appear authorized when planned yet be inadmissible when executed.

For example:

A security review approves a change for one repository revision, but the underlying code changes afterward.
A capability is granted with a limited scope, but the proposed effect targets a resource outside that scope.
A delegated permission is revoked while a job is waiting in a queue.
A network operation times out after the remote system may already have committed the effect.

Each example requires more than asking whether an AI's initial request was plausible. It requires checking which authority applies to which exact action, based on which evidence, at what point in the workflow, and how outcomes are recovered.

The paper proposes an architectural vocabulary for reasoning about these boundaries.

1. Provenance-validated admission

A provenance record is not automatically evidence that a proposed operation is admissible.

Suppose a test result was produced for revision A. An agent now wants to mutate revision B. The fact that a test passed is real historical evidence—but whether it applies to the new target is a separate question.

The proposed approach treats admission as dependent on evidence that is:

Authentic: Who or what produced it?
Applicable: Does it refer to this operation, resource, revision, and context?
Fresh enough: Has a relevant dependency changed since it was produced?
Within scope: Does the evidence support this requested decision, rather than a broader claim?

A model-generated explanation cannot resolve these questions by assertion alone. Admission must be tied to the relevant authoritative mechanisms.

2. Revocation fencing near consequential effects

A common timing problem appears when authorization is checked upstream, but execution happens later.

Conceptually:

Agent proposes action
        |
Resolve applicable authority
        |
Validate evidence and admission conditions
        |
Prepare candidate operation
        |
Check revocation/freshness at the effect boundary
        |
Commit permitted effect OR refuse/hold

The important idea is that an earlier permission check should not automatically survive a material authority change.

A design intended to enforce this property needs a reliable relationship between the authoritative revocation state and the consequential effect boundary. Otherwise, a race between a revocation and an operation can leave the system acting on stale authority.

The manuscript explores a proposed fencing approach and related conditional safety properties. The challenge is to show, under explicit assumptions, that a relevant revocation cannot be bypassed by queued work, alternate execution routes, or stale authorizations.

3. Recoverable effects and unknown outcomes

Now consider a different failure.

An agent asks a remote service to create a resource. The request times out. The agent cannot tell whether the remote operation committed.

Blindly repeating the request may create duplicates. Assuming it failed may be wrong. Assuming it succeeded may also be wrong.

Recoverable execution needs to distinguish:

An effect that is known not to have happened.
An effect that is known to have happened.
An effect whose outcome remains unknown.

That third state matters. The research discusses durable reconciliation of uncertain outcomes rather than treating every timeout as a safe opportunity to retry.

Depending on the external service, a practical strategy may involve stable operation identifiers, idempotency support, state queries, or controlled recovery workflows. No single mechanism works universally across all APIs.

4. Authority is not the same as trust, evidence, or execution

The paper emphasizes boundaries that are often collapsed in agent discussions:

Intent: What a caller or agent wants.
Authority: Who can permit the consequential action.
Admission: Whether the specific candidate satisfies applicable conditions.
Capability: What bounded operation has actually been granted.
Execution: What effect was attempted.
Evidence: What can be substantiated about that attempt.
Reconciliation: How uncertain or partial outcomes are resolved.

Keeping these concepts distinct helps reveal where systems otherwise confuse a caller's claim with a governing decision or a successful tool call with an approved final state.

A research agenda—not a declaration of proof

The preprint proposes an architecture, conditional safety propositions, and a falsifiable evaluation plan.

It does not report completed machine-checked proofs, controlled comparative benchmarks, independent peer review, or production validation. The proposed properties still need rigorous implementations, explicit threat models, failure-injection tests, and comparative evaluation.

Useful negative tests include:

Revocation committed immediately before effect-time checks.
Revocation racing with execution.
Replayed or duplicated requests.
Evidence that is genuine but stale or inapplicable.
Alternate entry points that bypass expected checks.
Remote timeouts after a possibly committed effect.
Process restart during unresolved reconciliation.

A design should be assessed by the failures it can rule out under specified assumptions—not just by successful demonstration paths.

Why publish this work?

Agent tooling is rapidly increasing the number of systems capable of making consequential external changes. The difficult engineering problem is not simply generating better decisions; it is preserving valid decision authority across the full path from proposal to effect and recovery.

This preprint contributes a proposed framework and an explicit set of questions that can be examined, challenged, and experimentally tested.

Read and cite

Paper: Authority-Bound Execution for Agentic Systems: A Formal Architecture for Provenance-Validated Admission, Revocation Fencing, and Recoverable Effects

Identifier: CC-RP-001

Version: v0.5

Published: October 30, 2026

Citation: Serrano, C. (2026). Authority-Bound Execution for Agentic Systems: A Formal Architecture for Provenance-Validated Admission, Revocation Fencing, and Recoverable Effects (Version 0.5). Zenodo. https://doi.org/10.5281/zenodo.23823408

Research integrity note: This is an independent explanatory article about a theoretical preprint, not an announcement of completed verification or deployment. The Zenodo version DOI identifies the authoritative archival manuscript. The related CEOS repository is contextual material, not the source repository for this distinct CaivraCore preprint.

Who Authorizes the AI Agent? A Systems Architecture for Governed Autonomous Software Engineering

Christian Serrano — Sat, 31 Oct 2026 04:35:13 +0000

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:

Propose: An agent produces a candidate action and supporting rationale.
Resolve authority: A designated authority owner determines whether the proposed action is within the applicable scope.
Bind scope and state: Capabilities, exact target state, freshness constraints, and preconditions are made explicit.
Admit and execute: Only a permitted transition reaches the controlled effect boundary.
Validate and record: Results are checked against the intended transition and retained with provenance.
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

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.