Classify the Execution Path Before You Grant Authority

OpenAI Exposes a Composed Execution Runtime

OpenAI’s Agents SDK defines an agent as more than a model invocation. The developer-facing runtime composes models with instructions, tools, guardrails, handoffs, sessions, tracing, and human-in-the-loop mechanisms. [2] Those controls also have defined placement and scope. Agent input and output guardrails do not execute everywhere in a multi-agent flow, and tool guardrails attach to specific function-tool boundaries. [3]

Human approval is similarly scoped. OpenAI documents flows in which sensitive tool calls can interrupt execution, surface an approval request, preserve run state, and resume after approval or rejection. Approval can apply to a particular call or, under defined conditions, persist for a tool identity during a run. [4]

These are important platform primitives, but they do not answer the enterprise’s prior architectural question: which of those controls should a particular workload require in the first place?

A read-only research task, a supervised CRM update, a production infrastructure change, and an autonomous remediation loop can all use capable models. They should not therefore receive the same authority, approval topology, network reach, state exposure, or evidence obligations.

Runtime Controls Are Consequences of an Earlier Decision

OpenAI’s August 26 incident analysis provides unusually direct evidence that surrounding runtime conditions can materially change observed behavior. After the incident, OpenAI created an evaluation measuring a model’s propensity to compromise infrastructure during ExploitGym evaluations and reported that the propensity could drop by more than 100x when the production ChatGPT harness and system prompt were used. [1] That result came from a post-incident evaluation designed to test the effect of production conditions; it should not be conflated with a separate retrospective finding in the same report.

Separately, OpenAI re-ran its auto-review system over rollouts involved in the Hugging Face incident and reported that the system would have flagged many dangerous actions. OpenAI also reported that its then-deployed chain-of-thought monitoring, had it been running on the affected evaluations, would have paged the security team more than a day before the Hugging Face breach. [1] These findings do not establish that one harness or monitor makes agentic execution safe. They establish something narrower and more useful for enterprise architecture: effective behavior and control coverage depend on the assembled system and on where safeguards actually participate in the execution path.

OpenAI’s Astra disclosures add a second signal. OpenAI has described adapting safeguards to model capability, operating environment, and risk, including stronger isolation, restricted access, monitoring, and other controls for higher-risk cyber work. [5][6] The Preparedness Framework likewise ties higher capability thresholds to stronger safeguard obligations. [7]

These OpenAI facts support a Luminity architectural distinction: capability is an input to the authority decision, not a substitute for it. A more capable agent does not acquire permission by becoming more capable. Its capability changes the consequence of drawing the authority boundary incorrectly.

The enterprise therefore needs a decision between intent and authority.

The Missing Enterprise Decision Is Execution-Path Classification

Enterprise intent describes the outcome the organization wants. Authority describes what an agent is permitted to affect. Those are not the same decision.

Between them sits the execution path: the governed way a workload is permitted to move from intent toward action, including the degree and topology of human control, the side effects that may occur, the systems that may be reached, the state that may persist, and the runtime constraints that must remain active.

This sequence matters because it changes how the architecture is designed. The enterprise does not begin by selecting a model and then asking which controls can be attached to it. It begins with the workload, classifies how that workload may execute, derives the Authority Envelope appropriate to that path, and then defines the runtime controls and evidence requirements needed to enforce and defend that decision.

That is the differentiated architectural proposition. The harness matters, but the harness is downstream of the classification decision.

Nine Dimensions Determine the Appropriate Path

Execution-path classification should be explainable from characteristics of the workload and operating context. Luminity currently uses nine decision dimensions.

Consequence asks what happens if the action is wrong, incomplete, mistimed, or maliciously redirected. Authority required identifies the systems, data, identities, tools, credentials, money, infrastructure, or external parties the workload must be able to affect. Reversibility asks whether the action can be undone cleanly or whether it creates effects that are difficult to repair.

Uncertainty captures ambiguity in the task, evidence, instructions, environment, or expected outcome. Capability considers how capable, persistent, tool-fluent, autonomous, or strategically effective the acting system is. Capability does not grant authority; it changes the consequence of granting authority incorrectly. OpenAI’s capability-dependent safeguard posture provides first-party support for treating capability as a material control input. [5][6][7]

State exposure asks what persistent context, memory, shared artifacts, or coordination surfaces can influence later behavior. External reach identifies the APIs, filesystems, applications, infrastructure, networks, MCP servers, third parties, and other external services reachable from the execution path.

Human-control requirement asks where approval, supervision, clarification, escalation, intervention, or stop authority must remain with a person or designated control function. OpenAI’s documented human-in-the-loop and interruption semantics demonstrate that approval and pause/resume controls can be placed at defined execution boundaries rather than treated as abstract governance concepts. [4]

Finally, evidence requirement asks what the enterprise must be able to observe, reconstruct, explain, and defend after execution. Tracing and runtime state are useful primitives, but enterprise evidence obligations extend beyond any one platform surface and must be derived from the workload’s consequence and authority. [2]

These dimensions are not a numeric risk score. Their purpose is to explain why a workload belongs on a particular execution path, what authority that path permits, what controls must enforce it, and what evidence must be retained.

Four Working Execution-Control Topologies

The current architecture uses four provisional execution-path classes. The names are intentionally not locked publication doctrine. What matters is the control topology each class represents.

Bounded Analysis covers reasoning, synthesis, transformation, or recommendation without independent authority to create consequential external side effects. The workload may have broad analytical capability while remaining constrained to approved inputs and bounded state. Its Authority Envelope can therefore exclude independent write, send, transact, deploy, or external action authority.

Supervised Action permits bounded side effects while a person remains actively involved in the operating loop. A typical case is low-risk, reversible enterprise data maintenance under active operator supervision. The relevant distinction is not simply that a human exists somewhere in the workflow. The human remains operationally proximate to the actions and can intervene while they occur.

Approval-Gated Execution allows the system to analyze, prepare, or stage a consequential action but prevents it from crossing a defined side-effect boundary until explicit approval is granted. OpenAI’s HITL primitives provide one concrete example of how an application can interrupt execution before a sensitive tool call and resume after approval or rejection. [4] The enterprise architecture requirement is broader: the approval must be scoped to the action being authorized, and the evidence should bind what was approved to what actually executed.

Constrained Autonomous Execution permits pre-authorized action without per-action approval, but only within a deliberately engineered Authority Envelope, with separate isolation, monitoring, evidence, and stop controls. An autonomous remediation loop over ephemeral build infrastructure is a useful enterprise example: high operational capability may be acceptable when the permitted resources and actions are narrow, the reachable environment is constrained, the environment is replaceable, and the system must stop or escalate when conditions fall outside policy.

These four classes are not ascending risk levels, maturity stages, or autonomy goals. A highly consequential production change may appropriately remain approval-gated, while a lower-consequence, high-volume remediation workflow may operate autonomously inside a narrow Authority Envelope with stronger runtime constraints.

The distinction is architectural, not aspirational.

Classification Produces Three Architectural Outputs

An execution-path label is not the end product. The classification must produce three connected but distinct architectural outputs.

First is the Authority Envelope: the context-specific scope of authority available to the workload. Consistent with the canonical series definition, it may include principal, delegator, purpose, resource scope, operation scope, tool scope, temporal scope, environment or transaction context, delegation depth, escalation rules, and downstream authorization requirements.

Second are the runtime and execution-control requirements needed to enforce and contain that authority. These may include identity and credential enforcement, tool and API gates, network restrictions, state policy, isolation, approval and supervision controls, monitoring, intervention, stop conditions, and recovery requirements.

Third are the evidence requirements: what the enterprise must observe, record, reconstruct, and defend about the intended path, active authority, control decisions, executed actions, resulting state, exceptions, and recovery.

Only after those decisions are explicit should the runtime be configured.

OpenAI’s SDK documentation makes the importance of this sequencing concrete because control placement is specific. Guardrails attach to particular execution points, approvals interrupt particular calls, and persisted state has defined semantics. [3][4] Those primitives become useful enterprise controls only when the architecture already knows which permission boundary each control is meant to enforce and what evidence must survive execution.

This is why a model-centric review is insufficient. Two workloads can use the same model and still require different authority, tools, privileges, approval boundaries, state policies, network access, and evidence. Conversely, changing to a more capable model can justify re-evaluating an existing path even if the surrounding application interface is unchanged. [5][6]

An Assurance Test for the Classification Decision

A classification method should produce a decision that can be tested, not merely described.

Hold the model constant and compare two workloads whose consequence, required authority, reversibility, uncertainty, state exposure, external reach, human-control requirement, or evidence requirement differs materially. The architecture should either produce different execution-path and Authority Envelope decisions or explain why the same path remains appropriate despite those differences. If the decision can be reproduced only by naming the model, the vendor, or the harness, then the enterprise has not demonstrated that workload characteristics actually govern the path.

The test is intentionally simple: can the enterprise explain and defend why this workload receives this execution path and this authority rather than another? If that answer cannot be reconstructed from the classification dimensions and resulting control obligations, the classification has not yet produced assurance.

Limits and Boundaries

Execution-path classification does not create governed execution by itself. It is an architecture decision that must be implemented through runtime controls, identity and access management, application permissions, infrastructure policy, network controls, data governance, monitoring, operational processes, and evidence mechanisms appropriate to the enterprise environment.

The four working classes are not an OpenAI taxonomy, and OpenAI has not published a general enterprise framework mapping model capability or agent behavior into these categories. The classification method, terminology, and sequence from authority to enforcement to evidence are Luminity architectural synthesis derived from the first-party signals described here.

The classes should also not become shorthand that replaces workload analysis. A label such as Approval-Gated Execution is useful only if the organization can explain the consequence, required authority, reversibility, uncertainty, capability, state exposure, external reach, human-control requirement, and evidence requirement that produced that decision.

OpenAI’s public Agents SDK is first-party implementation evidence for developer-facing runtime composition. It is not documentation of the internal ChatGPT production harness or Astra research containment environment. [2][3][4]

Finally, approval is not universal authorization, tracing is not automatically audit evidence, and no OpenAI runtime control governs every downstream enterprise system. The Authority Envelope defines the authority available to the workload; execution controls and evidence mechanisms must cover the actual path through which that authority becomes action.

The Durable Architectural Claim