Owner Exception Management

An urgent request from an owner is not automatically an authority grant. If an agent is normally forbidden to perform an action, a one-off exception must prove who may authorize it, what exact action/subject/resource it covers, when it starts and ends, what evidence supports it, what compensating controls apply, and how it can be revoked and audited.

The dangerous shortcut is: “the owner asked in chat, so allow it.” That collapses a request, an approval, and a policy change into one message. This lesson builds Owner Exception Request & Decision Ledger v1 so the normal rule stays visible and a bounded exception can never silently become permanent authority.

Core rule: keep the normal rule intact. An exception is a separate, narrow, expiring, revocable record. If decisive authority or evidence is missing, fail closed into a typed non-success state.

Lesson boundary and route

AGN-001 owns owner-exception governance. COM-037 owns the Native App Decision Gate; AGN-001 owns evidence-bound recommendations and confidence. This lesson does not absorb either outcome.

The authorized prerequisites are FND-003 (hard) and AIE-009 (soft). Carry forward only the boundary needed here: a high-impact action needs explicit evidence and accountable authority; urgency does not erase governance.

Everything in the lab is synthetic and offline. No refund, billing, customer, tenant, production system, or real approval is mutated.

Mental model: exception is a constrained delta, not a new default

Use this sequence:

normal rule → exception request → authority check → evidence/risk check → reject | hold | approve-bounded → compensating control → expiry/revoke → audit → separate policy-change path

Keep four objects separate:

1. Normal rule: what the agent may do by default.
2. Exception request: what someone is asking to deviate from, and why.
3. Exception decision: a narrow authorization record, if justified.
4. Policy change: a separately governed change to the default rule.

A valid exception does not rewrite the normal rule. Repetition also does not automatically make it policy. HOLD, UNKNOWN, PARTIAL, DISPUTED, STALE, BLOCKED, EXPIRED, and REVOKED are legitimate states when evidence is incomplete or the bounded grant is no longer valid.

Foundations: FACT, INFERENCE, and DESIGN

FACT — NIST: NIST AI 600-1 says GAI use may warrant additional human review, tracking, documentation, and management oversight. It also says organizations can restrict AI applications that exceed stated risk tolerances. This supports explicit oversight and bounded risk treatment; it does not define MAKNOW exception roles or expiry rules.

FACT — OpenAI Agents SDK: the current human-in-the-loop flow can pause a tool call that needs approval, expose pending approval interruptions, record a decision, and resume the paused run. That is a technical approval mechanism; it does not prove the person approving has organizational authority.

INFERENCE: auditability improves when the normal rule and exception record are kept separate and the exception carries exact scope, authority evidence, compensating controls, expiry/revocation, and audit references.

DESIGN: the ledger fields, state vocabulary, fail-closed rules, revalidation and policy-promotion gate in this lesson are local MAKNOW design choices.

The 22-field Owner Exception ledger

The working record has twenty-two dimensions:

exception_id, requester_id, owner_authority_ref, normal_rule_ref, requested_action, subject_scope, resource_scope, reason_code, evidence_refs, risk_class, approval_required, decision_state, decision_by, decision_at, effective_from, expires_at, compensating_controls, audit_event_ref, revocation_trigger, revalidation_due, policy_change_candidate, final_disposition.

Gate 1 — Preserve the normal rule

normal_rule_ref must survive the exception. Do not edit the baseline rule to make the exception look ordinary.

Gate 2 — Verify exception authority

owner_authority_ref must identify the local authority that can approve this class of exception. “Owner” as a conversational label is not enough. If authority is absent, unknown, stale, disputed, or outside the requested risk/scope, HOLD.

Gate 3 — Bind action, subject, and resource scope

A grant for one refund action, one synthetic customer, and one account/resource cannot be reused for a whole customer tier, another action, or a different resource. Scope expansion is a new decision.

Gate 4 — Record reason, evidence, and risk

Urgency is context, not authority. reason_code, evidence_refs, and risk_class make the trade-off visible. A high-risk exception needs stronger evidence and controls.

Gate 5 — Make approval explicit

If approval is required, decision_by must resolve to an authorized approver and decision_at must be recorded. A prefilled APPROVE_BOUNDED state cannot compensate for missing approver authority.

Gate 6 — Bound time

effective_from and expires_at define the validity window. After expiry, execution must be blocked. A new request needs a new evaluation, not silent renewal.

Gate 7 — Add compensating controls

Examples include secondary review, lower amount ceilings, single-use execution, post-action reconciliation, or enhanced monitoring. Controls reduce bounded risk; they do not create authority.

Gate 8 — Audit and revoke

Every exception needs an audit_event_ref and a revocation_trigger. If the trigger fires, the exception is REVOKED/BLOCKED even before nominal expiry.

Gate 9 — Revalidate and separate policy change

Repeated exceptions can signal that the normal rule should be reconsidered. Set policy_change_candidate=true when appropriate, but do not auto-promote. A governed policy-change path is separate from exception approval.

Worked examples

1. Baseline bounded exception

A support agent normally cannot issue a synthetic refund above 500 units. During an incident, an authorized service owner requests one 750-unit refund for customer C-104. Authority is verified for incident exceptions, evidence is current, risk is high but bounded, a second-person reconciliation control is required, the grant expires after 30 minutes, and a revocation trigger is defined. APPROVE_BOUNDED is defensible because every decisive field is visible.

2. Approval state remains, owner authority disappears

Remove owner_authority_ref but leave decision_state=APPROVE_BOUNDED. The state is now unsupported. The system must return HOLD_AUTHORITY_UNVERIFIED; approval text is not self-validating evidence.

3. One customer becomes an entire customer tier

The baseline exception covers C-104; the mutation broadens subject_scope to premium_customers. That is not the same exception. The system must return HOLD_SCOPE_BROADENED until a separately authorized decision is made.

4. Expiry passes while the agent still treats the grant as executable

An expired exception cannot be “probably still okay.” The evaluator returns BLOCKED_EXCEPTION_EXPIRED and requires a new request/re-evaluation.

5. Repeated exception becomes behavior

If the same deviation keeps recurring, mark it as a policy_change_candidate. Continuing indefinitely through fresh exceptions is not a substitute for governed policy review.

Failure modes

• Chat-as-authority: a request message is treated as permission.
• Normal-rule overwrite: the exception edits the default rule instead of remaining separate.
• Scope creep: one subject/action/resource quietly expands to a class or tier.
• Approval without approver: the decision field says approved while authority evidence is absent.
• Permanent temporary: no expires_at, or expiry is ignored.
• Control theater: compensating controls are named but not tied to risk.
• No revocation: a grant stays valid even when conditions change.
• Audit gap: no event reference allows reconstruction of who decided what and when.
• Exception-to-policy drift: repeated exceptions become normal behavior without governed policy change.
• Baseline reuse: a new request after expiry copies the previous approval even though action or customer class changed.
• External-mechanism overreach: SDK approval features are mistaken for organizational authority.
• Forced success: missing evidence is coerced into approval instead of HOLD/UNKNOWN/BLOCKED.

Alternatives and trade-offs

A team can reject all high-risk exceptions, or allow carefully bounded exceptions with stronger compensating controls. Reject-all is simpler and more conservative; bounded exceptions preserve operational flexibility but require more evidence, ownership, expiry, and audit discipline.

You can make exceptions single-use or time-windowed. Single-use is easier to reason about; time windows can support incident operations but increase risk of unintended repeated execution.

For recurring deviations, you can keep granting exceptions or open a policy-change review. Repeated exceptions are faster in the moment but create drift and inconsistency. A policy review costs more governance effort but makes the default rule explicit and testable.

The controlling rule is: an exception may narrow and time-bound a deviation; it must not create broader or longer-lived authority than the evidence supports.

Experienced bridge

Review an owner-exception request with eight questions:

1. What exact normal rule is being bypassed?
2. Who is requesting the exception, and what evidence proves their approval authority?
3. What exact action is permitted?
4. Which subject and resources are in scope—and explicitly out of scope?
5. What evidence and risk justify the deviation?
6. What compensating controls apply?
7. When does it expire, and what can revoke it earlier?
8. Is this still a one-off exception, or has repetition become a policy-change signal?

If question 2 resolves only to “they are the owner,” the decision is not yet auditable.

Guided and independent practice

Run the offline lab:

python -B lab/AGN-001-LAB1/learner/run_checks.py

Start with the bounded baseline. Then run these mutations: remove owner authority while retaining approval, broaden one customer to a customer tier, let the exception expire while still executable, remove a high-risk compensating control, fire the revocation trigger, and repeat the same exception without a governed policy-change disposition.

For transfer, evaluate a new request after expiry for a different action and customer class. Do not copy the baseline approval or its authority reference without checking applicability.

Verification evidence

Acceptance requires a decision reproducible from visible deterministic fields. The lab must catch at least:

• approval with no verifiable owner authority;
• scope expansion beyond the authorized subject/action/resource;
• execution after expiry;
• active revocation trigger;
• high-risk exception without compensating controls;
• repeated exception treated as normal policy;
• transfer that reuses the baseline approval;
• missing decisive fields becoming typed non-success rather than success.

The oracle is the visible fixture plus deterministic rules—not hidden model reasoning and not a live vendor/service.

Assessment and transfer

The learner must: explain the owned boundary; build the complete baseline ledger; diagnose the mutation where owner authority is removed while approval remains; and recompute a changed-context request after expiry.

A strong diagnosis names the invalid field, consequence, and smallest repair. Example: owner_authority_ref=UNKNOWN → approval unsupported → HOLD_AUTHORITY_UNVERIFIED → resolve authority evidence before any execution.

In the final transfer, the action and customer class change. The prior approval is historical evidence only. It is not standing policy, not inherited authority, and not the answer key.

References and freshness

• NIST AI 600-1 — Generative AI Profile: official basis for additional human oversight, tracking/documentation, management oversight, risk tolerance and governance controls; not the source of MAKNOW exception states.
• OpenAI Agents SDK — Human-in-the-loop: current technical mechanism for pausing approval-required tool calls and resuming after approve/reject; not organizational authority proof.
• Frozen AGN-001 Lesson Bible: local authority for ledger fields, state rules, negative cases, transfer and policy-change separation.

NIST and the OpenAI Agents SDK documentation were rechecked on 2026-09-14. Recheck volatile SDK behavior by 2026-10-18 and practice-level NIST/inference boundaries by 2027-01-01, or earlier if material semantics change.