JExec

JExec / Execution Admissibility Ontology / EAF-3

Admissibility failure class

EAF-3 — Unverified Authority

Authority is claimed, but never verified against an identifiable source.

DENY no authority source at all
ESCALATE source named but not verified

Definition

The execution asserts that it is permitted — “approved”, “authorized”, “routine” — without an identifiable, checkable source of that permission: no policy, no approval reference, no role grant, no change request.

The most common form is silent: authority is inferred from capability. The token works, therefore the action must be allowed. JExec treats this inference as the central confusion of automated systems. Credentials prove that the system will obey; they say nothing about whether it should.

How it appears

Across actors

Agent

An agent holds a repository-admin token and force-pushes to a protected branch. Nothing authorized the force-push; the token’s capability was silently treated as permission.

CI / pipeline

A release pipeline promotes an artifact to production whenever it reaches the final stage. The “authority” is the pipeline’s structure itself — unverifiable and unowned.

Human operator

An engineer with production database access corrects live data by hand. Access existed; authority for this change was never established.

Why it defeats admissibility

An admissibility decision must be able to point at the source of the authority it relied on, and at who or what verified it. Otherwise the verdict reduces to “the actor was able to,” which is precisely the condition JExec exists to interrogate. Capability without verified authority is how automation scales mistakes into incidents.

Remediation

In the JExec Record

Primarily affects: authority. The JExec Protocol maps EAF-3 to the consequences above; JExec Check detects it deterministically and links back to this page.

Related classes

EAF-2 Unattributed Actor · EAF-4 Authority–Scope Mismatch