Agent Authority Matrix

Having a tool is not the same as having authority to use it. A support agent may technically be able to read an order, draft a reply, issue a refund, or mutate a production account. Those actions do not carry the same authority. If they are collapsed into a broad label such as “admin agent,” capability silently turns into permission and the boundary between read, recommend, draft, and execute disappears.

The owned artifact in this lesson is Agent Authority Matrix & Approval Gate v1. For each agent and action, it records subject/resource/environment scope, authority level, allow/deny state, approval requirement, approver role, guardrail and tool-contract references, deny-default behavior, escalation, audit evidence, and review timing.

Primary rule: when the matrix cannot prove permission, a high-impact action fails closed. “Possibly allowed” is not equivalent to “allowed.”

Route orientation and owned boundary

AGN-004 owns only the authority matrix and approval gate. AGN-003 owns typed contracts, versions, and handoff interfaces; AGN-005 owns memory boundaries. This lesson grants no standing authority, stores no real user data, and executes no live production mutation. It builds a bounded decision from synthetic offline evidence.

AGN-001 is the hard prerequisite: the learner must understand the agent/human accountability boundary. AGN-003 is a soft prerequisite because stable identity and tool contracts make authority rows traceable. If required contract evidence is missing, preserve HOLD/UNKNOWN; do not invent authority.

Mental model: capability is not authority

Use this sequence for every request:

agent + requested action → action/scope/environment lookup → deny-default → guardrail → approval if required → allow | deny | escalate → audit

Keep three layers separate:

1. Capability: what tool or function can the runtime technically call?
2. Authority: what action may this agent perform on this subject/resource in this environment?
3. Approval: even when the action is in scope, does this individual invocation need a human decision?

Authority is row-level, not role-level. A support-agent may directly read an order, draft a response, execute a small refund only after approval, and have no authority at all for an unrelated production-account mutation.

HOLD, UNKNOWN, PARTIAL, DISPUTED, STALE, and BLOCKED are healthy states when evidence is incomplete. They prevent fabricated success.

Foundations: external mechanism versus local policy

Current OpenAI Agents SDK documentation supports approval rules for tools: a tool that needs approval can interrupt the run until a person approves or rejects the call. The SDK also provides tool guardrails around custom function-tool invocation so calls can be checked or blocked before execution and outputs checked afterward. The OpenAI Model Spec separately describes a chain of command in which higher-authority instructions override lower-authority ones, demonstrating that availability and authority are different concepts.

These are FACTS about a vendor mechanism or behavior model. They do not decide who may approve a refund in your organization, what refund threshold is acceptable, or which environment is production. Those are local MAKNOW DESIGN/policy choices.

Therefore:

• an approval primitive executes policy; it does not create policy;
• a guardrail is an enforcement hook; it is not the source of authority;
• the Model Spec is a bounded example of instruction authority, not a universal enterprise authorization standard.

Deep explanation of the matrix and gates

The working contract contains twenty fields:

agent_id, action_class, verb, subject_scope, resource_scope, environment_scope, data_classification, authority_level, allowed, approval_required, approver_role, guardrail_ref, tool_contract_ref, exception_policy_ref, deny_default, escalation_path, decision_state, decision_reason, audit_ref, review_due.

Gate 1 — Action identity

action_class and verb must be explicit. draft is not execute. Changing a request from draft to execute is an authority mutation.

Gate 2 — Subject / resource / environment

All three dimensions must match. Staging authority does not inherit into production, and authority over a customer-owned order does not expand to all accounts.

Gate 3 — Authority level

Keep read / recommend / draft / execute distinct. READ_RECOMMEND does not create side-effect authority. An action above the row's authority level must deny or hold.

Gate 4 — Allowed plus deny-default

allowed=true is meaningful only when the row is complete and traceable. Missing rows, owners, or decisive evidence flow to fail-closed HOLD/DENY rather than implicit allow.

Gate 5 — Approval

When approval_required=true, approver_role cannot be empty and the approval must bind to the same action and scope. “Someone approved it” is not sufficient evidence.

Gate 6 — Guardrail and tool contract

A guardrail can reject unsafe input and a tool contract constrains parameters, but neither grants authority. A new bulk_update tool whose parameters exceed current subject scope requires authority recomputation.

Gate 7 — Exception and escalation

Exceptions must be bounded and auditable. Without an exception policy, the agent cannot invent a bypass. Escalation defines where UNKNOWN, DISPUTED, or high-impact requests go.

Gate 8 — Audit and review

Every decision needs an audit_ref and must be revisited when policy, tool, or environment assumptions change. Authority is not permanent metadata.

Worked examples

1. Read an order

The support agent has READ authority for order.read on the current customer's order in production. The action has no side effect, needs no approval, and a tenant/identity guardrail applies. Result: ALLOW.

2. Draft a customer response

The same agent may draft a response, but the row does not authorize final sending. If the verb changes to send/execute, the draft row is no longer an oracle.

3. Bounded refund

A refund.execute row may set allowed=true but still require approval. Until support_lead approves that specific call, the correct state is APPROVAL_REQUIRED, not executed.

4. Invalid mutation: staging to production

A staging-only row does not authorize the same tool call in production. Same agent plus same tool does not create new authority. Return DENY_ENVIRONMENT_SCOPE or a bounded hold.

5. Invalid mutation: draft to execute

If the action changes from draft to execute while approval_required remains false, the matrix is inconsistent. Recompute authority and approval policy.

6. Transfer: new bulk-update tool

Treat bulk_update as a new capability. Because its accepted parameters may exceed the old subject/resource scope, keep HOLD_AUTHORITY_RECOMPUTE until the matrix is rebuilt.

Failure modes

• Tool-list authorization: tool availability is treated as permission.
• Role collapse: read/recommend/draft/execute are merged into one broad role.
• Environment inheritance: staging permission is copied to production.
• Subject creep: authority over one customer expands to a wider population.
• Approval theater: approval is required but approver, call identity, or audit evidence is absent.
• Guardrail-as-authority: technical validation is treated as organizational permission.
• Missing-row allow: lack of a matching row becomes implicit allow instead of fail-closed.
• Exception leak: a temporary exception turns into standing authority.
• Tool expansion: a broader tool appears without authority recomputation.
• Stale authority: tool/policy/environment changes while the old review evidence remains active.

Alternatives and trade-offs

A fine-grained matrix provides stronger control but costs more to maintain and review. A coarse matrix is easier to operate but increases privilege-creep risk. Human approval reduces risk for sensitive actions but adds latency and operating load. Automated guardrails are fast but only enforce rules that are explicitly implemented.

The goal is not “approval for everything.” The goal is to match evidence strength and approval burden to action impact without ever allowing more than the evidence supports.

Experienced bridge

For each sensitive call, ask eight questions:

1. Which stable agent identity is acting?
2. What exact action and verb are requested?
3. Which subject and resource are affected?
4. Which environment is targeted?
5. What authority level does the matching row grant?
6. Is approval required, and by which role?
7. What do the guardrail and tool contract enforce—and not enforce?
8. If evidence is incomplete, should the request deny, hold, or escalate, and where is that recorded?

If questions 2–6 do not match the row, do not convert capability into permission.

Guided and independent practice

Review the authority table, then run the offline lab:

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

For independent practice, mutate the baseline four ways: target production instead of staging, change draft to execute, remove the approver, and add a new bulk_update tool. For each mutation, recompute the decision from the changed evidence. Do not copy the baseline result.

Verification evidence

Acceptance means the decision is reproducible from visible deterministic evidence. The lab must detect at least:

• staging-only authority against a production request;
• draft→execute without approval recomputation;
• approval_required=true with no approver;
• a new tool whose scope exceeds existing authority;
• missing decisive evidence that must remain UNKNOWN/HOLD;
• transfer that copies the baseline decision without recomputation.

No network call, API key, production credential, or real customer data is required.

Assessment and transfer

In transfer, move the same support agent into staging and add a bulk_update tool. Rebuild the matrix by action, subject, and environment. Staging does not mean “all tools are allowed”; the new tool needs its own contract, subject scope, authority level, and approval requirement.

A complete answer distinguishes ALLOW, DENY, APPROVAL_REQUIRED, and HOLD/UNKNOWN and supplies a traceable decision_reason, audit_ref, and escalation path for each.

References and freshness

• OpenAI Agents SDK — Human-in-the-loop: pause/approve/reject for tool calls requiring approval.
• OpenAI Agents SDK — Guardrails: input/output and function-tool guardrails as enforcement hooks.
• OpenAI Model Spec (2025-04-11): chain of command and instruction authority within the OpenAI model-behavior boundary.
• Frozen Lesson Bible lesson://AGN-004: local MAKNOW authority for fields, states, and fail-closed policy.

The SDK sources were rechecked on 2026-09-14 and should be reviewed again by 2026-10-18 or earlier after a material semantic change. This lesson performs no live production action.