Agent execution authority · policy-as-code · conformance · reliable autonomous systems

I work on the boundary between AI reasoning and real-world authority.

The interesting question is not only what an agent can do. It is what the system can prove the agent was allowed to cause.

My current work is centered on a simple architectural position:

reasoning authority != execution authority

A model may propose an action. The authority to approve, bind, dispatch and verify that action should come from controls outside the model's own reasoning loop.

That leads to a research program spanning three layers:

                         ┌──────────────────────────────┐
                         │  REMORA Research             │
                         │  mechanisms + experiments   │
                         └──────────────┬───────────────┘
                                        │
                                        ▼
                         ┌──────────────────────────────┐
                         │  Agent Authority Conformance │
                         │  common evidence vocabulary │
                         └──────────────┬───────────────┘
                                        │
                                        ▼
                         ┌──────────────────────────────┐
                         │  Assured Agent Execution     │
                         │  deployable control patterns│
                         └──────────────────────────────┘

The common problem is action-time authority: who authorized an action, what exactly was authorized, whether the protected effect can bypass the governed path, whether the authorization remained valid at dispatch, and whether the external effect can be verified afterwards.

A standalone, vendor-neutral evidence model for comparing authority and execution controls in agentic systems without collapsing them into a vague security score.

It separates seven properties:

The rules are deliberately conservative:

PASS requires resolved evidence
UNTESTED is not failure
OUT OF SCOPE is not a deficiency
properties are never aggregated into one score

The repository contains a normative v0.1 specification, a machine-readable assessment schema, CI validation and bounded cross-system assessments.

I am particularly interested in whether these seven properties survive contact with systems built on assumptions very different from REMORA. If they do not, the vocabulary should change.

REMORA explores policy-gated execution assurance for operational AI agents. It sits between an agent proposal and the protected tool path.

proposal
   ↓
authoritative context
   ↓
policy decision
   ↓
review / short-lived grant
   ↓
fresh pre-execution checks
   ↓
exact-call binding
   ↓
controlled dispatch
   ↓
postcondition / effect evidence

The project is intentionally evidence-heavy. Claims are tied to committed artifacts, explicit scope and permanent negative results rather than being inferred from architecture diagrams or demos.

Useful entry points:

• Claim register
• Negative results
• Evidence and claims
• Architecture

REMORA is research/shadow-mode software. It does not claim production certification or universal agent safety.

Product-oriented work on turning the research into deployable control-plane patterns: exact-payload approval binding, separate proposer/approver/executor identities, controlled dispatch, auditable execution state and postcondition verification.

An experiment in treating technical claims like build artifacts: documentation, benchmark results and reusable code are mechanically bound to the evidence that supports them, so unsupported drift can fail CI instead of silently becoming project truth.

I prefer research questions that can embarrass the architecture.

Some of the questions I am actively interested in:

• Authority provenance: can a system prove that the principal approving an action actually held the required authority, including delegation and attenuation?
• Credential topology: how do we demonstrate that a protected side effect is unreachable outside the policy enforcement path rather than merely assuming it?
• Exact-call integrity: what canonical representation is sufficient to bind authorization to complex, nested and versioned tool arguments without ambiguity?
• Distributed TOCTOU: how should single-use grants, revocation and approval freshness behave across processes, hosts and retries?
• Semantic authority: where should authoritative task meaning come from when the model itself cannot be allowed to manufacture the authority for its own proposal?
• Effect verification: what constitutes authoritative evidence that an external side effect occurred, especially when the downstream system offers weak read-back semantics?
• Conformance validity: can independent assessors apply the same authority model and reach comparable conclusions without sharing implementation assumptions?

These are more interesting to me than another benchmark claiming that an agent completed a task successfully.

My working rule is simple:

1. State the property precisely.
2. Define what evidence would support it.
3. Design a test that can disprove it.
4. Bind the result to an immutable artifact or revision.
5. Keep scope and caveats next to the result.
6. Publish negative results and failed hypotheses.
7. Change the architecture when the evidence says it should change.

A useful result can therefore be PASS, UNTESTED, OUT OF SCOPE, or a falsified hypothesis. The label matters less than whether another engineer can inspect how it was obtained.

I use external discussions to pressure-test the work, not to accumulate endorsements. The most useful response is often a precise objection that forces a property boundary or claim to become narrower.

Selected examples:

• CoSAI WS4 · Agent Manifest RFC
  Semantic correctness, execution authority and observed effect as separate properties

• CoSAI WS4 · runtime evidence / OCSF boundary
  Admission vs. closure evidence, runtime trust-base integrity and policy separation

• AEGIS Core × Agent Authority Conformance
  A cross-system dialogue around replay suppression, argument binding, scope declarations and the difference between SDK-level evidence and deployment-level guarantees. The point is not to rank implementations, but to see whether the same vocabulary describes both fairly.

reasoning authority != execution authority

a valid receipt != proof of effect

permission != semantic correctness

a pre-tool hook != an enforcement boundary

telemetry != authorization

unknown != safe

OUT OF SCOPE != failure

negative results are results

I would particularly like criticism or replication from people working in:

• distributed systems and concurrency
• IAM, capability security and delegated authority
• formal methods and protocol analysis
• policy engines, PDP/PEP architectures and policy-as-code
• agent runtimes, MCP and tool-execution infrastructure
• secure systems architecture and credential isolation
• observability, audit evidence and postcondition verification
• safety evaluation, benchmark methodology and inter-rater agreement

If you can show that an assumption is wrong, a property is underspecified, a test proves less than claimed, or an important dimension is missing, that is a useful contribution.

Good collaboration here looks like:

claim → counterexample → narrower property → reproducible test → better architecture

Independent assessment of Agent Authority Conformance, adversarial review of REMORA, and technically serious comparisons with other execution-control systems are especially welcome.

I am CEO of Luftfiber AS and work close to production telecom and operational infrastructure. That environment keeps the research anchored in mundane but important realities: credential custody, tenant boundaries, stale state, blast radius, rollback, auditability and what happens when software touches systems that matter.

My broader interests include Python systems, network automation, MCP infrastructure, trustworthy autonomous operations and the engineering gap between an impressive agent demo and an agent that should be permitted to act.