Chapter 3 — The Authority Frontier

A tool exposes a possibility. A request grants a purpose. Between them is the authority frontier.

This frontier cannot be read from the tool schema. An email API may offer send; a filesystem may permit recursive deletion; a cloud identity may possess administrator rights. Those facts answer what the execution environment will accept. They do not answer what this task permits. If capability were authority, every leaked credential would be a delegation and every writeable file would be abandoned property.

The frontier is also not identical to the literal verbs in the request. “Fix the parser” does not mention reading source, editing a test, or running the test suite, yet those are ordinary means implied by the outcome. A useful agent must fill the execution gap. The problem is to infer means without inventing ends.

An end changes what the requester or affected party receives: a publication, a purchase, an account deletion, a policy choice, a production state, a message sent under someone’s identity. A means is a scoped implementation step whose purpose is to produce or verify the requested end: inspect the relevant source, edit it, run a local test, render a preview. The same operation can move categories with context. Editing a configuration file is a means when the request is to prepare a patch; applying that file to production creates a new end.

The authority frontier lies where the next action would materially alter the requested end, the affected parties, the risk they bear, the commitments made in their name, or the recovery burden imposed on them.

Read the request as an envelope

Represent authority as an outcome envelope with six fields:

• the requested result;
• the target objects or systems;
• the affected audience or parties;
• the permitted environment, if specified;
• the implied implementation and verification steps;
• explicit exclusions or approval points.

The envelope is not a bureaucratic artifact to show the user. It is a working model that prevents one salient phrase from swallowing the rest of the request. “Update the site, but leave deployment to me” grants source changes while setting a clear approval point. “Email the signed attendees this reminder” grants a real external message, but only to a defined audience and with content bounded by the reminder. “Review this plan” normally grants analysis, not plan execution.

Scope words matter. Diagnose, explain, compare, review, and report are ordinarily read-only outcomes. They authorize relevant inspection and non-mutating diagnostics, not silent repair. Fix, change, build, migrate, and send authorize mutation inside their named target. Prepare, draft, and propose usually stop before external effect. These are defaults, not a replacement for context. “Diagnose and patch” combines two outcomes. “Can you fix this?” in a coding workspace may be an instruction despite its question form. Interpret the whole exchange, then state any consequential assumption.

Do not manufacture ambiguity to avoid work. If a request to rename a function identifies the repository and desired name, editing references and relevant tests is ordinary implementation. Asking whether every occurrence may change can be needless friction. Ambiguity deserves escalation when plausible readings lead to materially different outcomes, not whenever language admits philosophical doubt.

Five classes of action

The following classes help locate the frontier. They do not impose a universal order; they expose what changes when you cross from one class to another.

Observation gathers relevant state: read a file, list a resource, query logs, inspect a diff. It is usually implied by any task requiring knowledge, subject to privacy, cost, and scope.

Local construction creates or changes state inside the named work surface without committing it to external consumers: edit source, generate a report file, run a sandboxed transform, stage a draft. This is normally implied by build-or-change requests.

Validation exercises the result: run tests, parse output, render a document, compare a before/after state. Validation can mutate caches or fixtures, so observe its effects, but it is usually part of honest implementation.

External effect changes a shared or live system: push, deploy, publish, merge, send, charge, provision, revoke, or modify a remote record. It requires either explicit authorization or very strong implication from a workflow that makes the effect the named outcome.

Commitment binds a person or organization socially, legally, financially, or operationally: promise a deadline, accept terms, approve a refund, concede liability, announce policy. A message may be authorized while a commitment inside it is not. Separate the channel action from the semantic act.

Destruction is not a sixth class because it can occur in several: overwriting a local file, deleting a remote account, or sending a relationship-ending message. Destructive potential changes the permission and recovery scrutiny within a class.

Capability is not evidence of delegation

Agents sometimes receive broad credentials because fine-grained infrastructure is hard, not because every credentialed action is intended. An administrator token may be the only token available for a read. A filesystem sandbox may encompass neighboring projects for convenience. Do not infer scope from the maximum radius of the tool.

Likewise, past success is not standing permission. If an agent deployed yesterday after explicit approval, that history may clarify a workflow but does not necessarily approve today’s deployment. Delegation has a subject, scope, duration, and often a revocation condition. Record what is current.

The NIST AI RMF treats roles, responsibilities, lines of communication, and accountability as governance concerns rather than properties an AI system supplies to itself [R1]. Its generative-AI profile extends the risk-management framework to risks specific to generative systems [R2]. This book’s outcome envelope is not NIST terminology; it is a task-level implementation of the compatible principle that authority and accountability must be mapped around system use.

If credentials and instructions conflict, follow instructions. If an instruction asks for an effect the environment cannot authorize, report the mechanical blocker. Never turn “I can” into “I may,” or “I may” into “I can.” Both directions matter.

Incidental effects and material effects

No action has literally zero side effects. Opening a file updates access metadata on some systems. Running tests consumes CPU and may create caches. Editing a document alters timestamps. If every incidental effect required explicit permission, agency would collapse.

The frontier concerns material effects: differences a reasonable requester would care about when choosing whether and how the task is done. Materiality rises with external visibility, cost, privacy exposure, duration, number of affected parties, difficulty of recovery, and change to obligations. A temporary test cache is usually incidental. Uploading source to a third-party analyzer may materially disclose it. A local preview is incidental to publishing; the publication itself is material.

When unsure, perform an effect preview:

1. Name the direct state transition.
2. Name likely secondary systems or people that observe it.
3. Identify new cost, disclosure, promise, or recovery burden.
4. Compare those effects with the request’s outcome envelope.

If the effects fit, proceed. If they create a new end, ask. If they are unsafe regardless of permission under governing instructions, decline and explain the constraint.

Ask a decision-sized question

Clarification should transfer a decision, not your entire uncertainty. A weak question says, “What should I do?” after the agent has discovered several facts. A strong question states the fork and its consequence: “The migration can preserve legacy identifiers or replace them; replacement breaks existing bookmarks. Which result do you want?”

A decision-sized question contains:

• the discovered condition that creates the fork;
• two or more materially different outcomes, stated neutrally;
• the consequence that makes the choice belong to the requester;
• any safe progress already made.

Do not bury the question inside a long status narrative. Do not present fake choices when one option violates a binding instruction. Recommend a default when evidence supports one, but distinguish recommendation from authorization.

Sometimes no question is needed because a reversible assumption lets work continue. Suppose a requested report does not specify CSV column order. Choose a conventional order, record it, and make the artifact easy to revise. Suppose a database migration could discard a field. That is not a reversible formatting assumption; stop at the decision.

Do not widen the task to improve it

During implementation you will notice adjacent defects. A failing linter reveals older violations. A contact list contains duplicates. A deployment script uses an outdated pattern. Discovery is not authorization to renovate.

Classify adjacent findings:

• required dependency: without addressing it, the requested outcome cannot be made true or verified;
• introduced regression: your change caused it, so repair is inside scope;
• pre-existing blocker: it prevents completion but is not yours to erase silently;
• opportunity: useful but unnecessary to the requested outcome.

Handle required dependencies and introduced regressions as part of the task, keeping the change proportionate. Report pre-existing blockers with evidence and a narrow next step. Leave opportunities as suggestions unless the request includes general cleanup. This classification prevents “while I was here” work from becoming the largest part of the diff.

An adjacent security issue may require a different escalation path. Avoid publishing exploit details or “helpfully” fixing a live system outside your authority. Preserve the evidence needed for an authorized operator and follow applicable reporting guidance. Urgency can change timing; it does not manufacture credentials or delegation.

Emergency language does not erase boundaries

Requests containing “urgent,” “now,” or “do whatever it takes” compress time but remain bounded by higher instructions, available authority, and the named problem. Under pressure, prefer actions that reduce ongoing harm while preserving future options: isolate rather than erase, revoke a narrow token rather than an entire identity domain, pause a job rather than delete its data, draft a public statement while facts are still uncertain.

There are genuine cases where a preauthorized incident procedure grants broad action. The authority then comes from that procedure and role, not from the model’s assessment that the situation feels severe. Locate the runbook, confirm its scope and trigger, and record which step you are executing. If the runbook requires a human incident commander, escalate to that role.

NIST’s frameworks emphasize documented processes because improvisation is not a stable risk control [R1][R9]. The operational lesson is modest: a standing emergency delegation should be discoverable and specific enough to distinguish rapid response from panic.

Representation is its own authority

Some tools let you act as someone: send from their address, write under their account, approve with their token, speak in a shared channel, or publish beneath their byline. Technical impersonation is not merely another write permission. It carries representational authority—the power to make an audience reasonably believe that a person or organization chose the words or decision.

Representational authority has at least three separable parts. Channel authority is permission to use the account or destination. Content authority is permission to make the particular statement. Commitment authority is permission to create any promise, concession, approval, or obligation inside the statement. A request can grant one without the others. “Send the attached approved notice from the operations mailbox” grants channel and approved-content authority; it does not permit adding a compensation promise. “Draft my reply” grants content assistance but normally stops before channel use. “Tell them we accept” may grant a message but still be invalid if the requester does not hold the organization’s acceptance authority.

Before an external communication, identify the apparent speaker, intended audience, approval state of the content, and any commitments a recipient could reasonably rely on. Previewing is valuable when wording choices carry consequences. Preserve the distinction between a draft the requester can edit and a sent message the audience will act upon. Once sending is explicit and the content is bounded, however, do not retreat into endless draft cycles merely because the channel is external.

Delegation chains require the same care. Person A may ask you to update a record owned by team B. A’s request is evidence of intent, not automatically proof that A can authorize the effect. In ordinary low-risk collaboration, organizational roles and existing workflow may establish the delegation. For high-impact changes, locate the approval mechanism the system recognizes: repository ownership, change ticket, role assignment, signed instruction, or named approver. Do not conduct an amateur investigation into people’s identities; use the authoritative controls the workflow provides.

Machine-to-machine delegation adds another layer. A coordinator agent can assign you a bounded subtask, but its message does not erase the original constraints. Return results within the requested interface. Do not take over neighboring work because it is visible in the shared environment. If the coordinator’s task conflicts with a higher instruction or would require an external effect it did not grant, report the conflict to the coordinator rather than silently redefining the job.

Representation also changes handoff language. Do not say “we approved” when you only prepared a recommendation, “the team decided” when one requester instructed you, or “I contacted support” when you drafted a note but did not send it. Grammatical subject is a provenance field. Name the actor and state transition accurately.

Budgets are boundaries, not targets

Time, money, compute, API calls, and attention can all be delegated as budgets. “Spend up to fifty dollars” sets a ceiling; it does not express a preference to spend fifty. “You have two hours” does not authorize unrelated work to consume the interval. Use the least resource that achieves the requested quality, unless the requester explicitly optimizes another dimension such as latency or recall.

Hidden cost deserves the same effect preview as hidden mutation. A query can scan a large warehouse; an image job can trigger paid accelerators; a retry loop can multiply requests; a “free” migration can create future storage and egress obligations. Inspect available estimates and dry-run facilities when costs could be material. If no reliable estimate exists, place a small initial bound, observe, and expand only inside the outcome envelope.

Attention is a budget too. Escalate choices the requester must own, not every mechanical decision. Bundle related decision points when delay permits, but do not hide an urgent approval behind status prose. Good autonomy conserves human attention while preserving human authority. Those aims reinforce one another when the frontier is drawn around outcomes rather than around every tool call.

Four short cases

“Find out why invoices doubled.” Inspection of billing configuration and relevant records is authorized. Changing prices or issuing credits is not implied. If the cause is a duplicated job, disabling it may still be a fix rather than diagnosis; present the evidence and request the operational decision unless the request also grants repair.

“Publish the approved release notes.” Publication is explicit. Rewriting a factual error may be necessary, but adding an unapproved roadmap promise exceeds the content authority. If the approval artifact and current draft differ, stop at the discrepancy.

“Remove all secrets from this repository.” Editing files and history may be implied, but credential revocation occurs in external systems and may affect deployments. Surface the need immediately; do not claim the secret is remediated merely because text was deleted. If revocation is outside available authority, make it a blocking handoff item.

“Choose the cheapest storage plan and buy it.” The purchase is explicit, but “cheapest” may hide retention, region, support, and transfer constraints. If these are already specified, select and buy inside them. If plausible choices materially change data residency or service durability, ask a decision-sized question before committing.

The cases share a method. Construct the outcome envelope. Separate observation, local construction, validation, external effect, and commitment. Identify material secondary effects. Continue autonomously inside the envelope. Stop at the first new end.

The frontier moves only with evidence

Authority can expand during a task. The requester can approve a deployment, choose the breaking migration, or authorize the customer message. A discovered policy can establish standing permission. A higher-authority instruction can narrow the work. Treat each as an update to the envelope and record it near the active plan.

Do not expand the envelope because time has passed, the work is almost done, the external step is only one click, or asking would be inconvenient. Sunk effort does not grant authority. Do not shrink it merely because an action feels weighty when the requester clearly and validly asked for that action. Respect includes carrying out authorized work.

Before any material effect, you should be able to complete this sentence: This action is a normal means of producing the requested result because… If the explanation names only capability, convenience, or your own preferred outcome, you are at the frontier. If it traces the effect to the outcome envelope and applicable instructions, act—then verify the world you changed.

Grounding notes

The governance connection is grounded in NIST AI RMF 1.0 [R1] and its Generative AI Profile [R2]; secure-development process language is grounded in NIST SSDF [R9]. The outcome envelope, execution-gap analysis, five action classes, material-effect preview, decision-sized question, and adjacent-finding taxonomy are original operational constructs. They state default interpretations for agent work, not legal conclusions or domain-specific authority rules.