Bind Identity, Delegation, and Consent

AR-04 v1.0.0 defines five capabilities. Each contract contains a principal and scope field, but placeholder text is not authorization. If FieldOps copies a user’s broad access token into model context, every prompt, tool argument, trace, and retrieved instruction becomes a possible credential boundary. If it treats the browser session as the user, a resumed run can inherit authority that was never revalidated. If an approval says only “allow reservation,” a changed part or slot can pass under yesterday’s consent.

Identity must be separated before it can be bound.

FieldOps distinguishes the human principal, service principal, agent instance, task, run, protected resource, delegation envelope, access token, proposal, approval, and effect record. Each has a different job. An access token proves something to a resource server under a protocol and policy. It does not by itself say that the business permits this reservation. A user interaction records a choice. It does not prove the person had formal authority.

Current OAuth security guidance supports audience-restricted and least-privileged tokens, resource indicators, contemporary authorization-code protections such as PKCE, and avoidance of token passthrough. These controls are necessary for the applicable flows, but they are not sufficient for task delegation or effect approval. [CLM-011]

This chapter creates AR-05 v1.0.0, a synthetic identity and delegation envelope that binds one FieldOps proposal to one principal, task, run, resource, scope, and time window. It is a teaching fixture, not enterprise IAM, legal consent, or regulated authorization.

1. Separate the identity layers

Human principal

The human principal is the person represented by a verified application identity. FieldOps uses human:fieldops-reviewer-07. The identifier is synthetic and says nothing about assurance level. A real system would carry issuer, authentication context, organizational status, and applicable policy references supplied by identity specialists.

The human can request a task without being authorized for every effect. Request, benefit, review, and authorization are separate relationships.

Service principal

The harness has its own workload identity: service:fieldops-harness. It authenticates to infrastructure and capability adapters. It is not the human and must not turn its broad service access into user authority. The adapter evaluates both service trust and delegated user/task scope.

Agent instance

The agent instance identifies the bounded model-directed component participating in the run. agent:fieldops-reader-001 is useful for policy, audit, and incident attribution. It is not a legal person and does not create independent authority. A new instance must not inherit a previous instance’s delegation without an explicit rule.

Task and run

task:fieldops-104 identifies the governed objective; run:fieldops-001 identifies one execution. Binding both prevents a token or approval created for one task from drifting into another and prevents replay across runs.

Resource

The protected resource is the intended service audience, here https://synthetic.inventory.fieldops.example. Resource identity keeps a token intended for manuals from being presented to inventory. A resource can still be malicious or misconfigured; metadata and audience matching do not prove trust.

Proposal, approval, and effect

The proposal is immutable intended effect content. The approval is one principal’s scoped authorization for that exact proposal. The effect record is the service’s authoritative account of what happened. None can substitute for another.

This layered map reflects an emerging problem space discussed in a 2026 NIST NCCoE concept paper. That document is a concept paper, not a standard, control set, or completed reference architecture. FieldOps uses it only to frame identity and delegation questions. [CLM-012]

2. Respect the OAuth resource boundary

OAuth answers a bounded protocol question: how a client obtains and presents access delegated under an authorization server’s rules to a protected resource. An agent application still needs local task and effect semantics.

Audience restriction

An access token should be usable only by its intended resource. RFC 8707 defines resource indicators for authorization requests, and current OAuth security practice supports audience restriction. RFC 9728 defines protected-resource metadata that can describe the resource’s authorization-server relationship. Current MCP authorization uses these mechanisms for HTTP transports.

FieldOps requests a token for the synthetic inventory audience. The inventory adapter rejects a token whose audience is the manuals service, even if the same user owns both. Cross-audience rejection prevents a compromised or confused component from turning one grant into a general credential.

Metadata discovery must be constrained. The client validates configured origins, TLS, issuer relationships, and applicable security policy. A URL returned by untrusted content cannot redirect credential discovery. Metadata identifies protocol endpoints; it does not establish business trust.

Least privilege

The delegation enumerates equipment:read, manual:read, inventory:read, reservation:propose, and reservation:effect:one. The resource server enforces scopes relevant to itself. A broad inventory:admin token would collapse the capability boundary even if the model usually calls only reserve_part.

Scopes are necessary but coarse. reservation:effect:one still needs resource, part, slot, quantity, task, run, and approval checks. OAuth scope does not encode the whole action contract.

Authorization-code protection

For applicable public-client authorization-code flows, current best practice includes PKCE and contemporary protections against code interception, mix-up, replay, and redirect abuse. FieldOps records pkce: required in the synthetic packet without teaching a full OAuth implementation. Identity specialists and the chosen authorization server own correct deployment.

Use normative words carefully. RFC requirements apply within their stated protocol and threat-model context. They do not become universal claims about every local tool call.

No token passthrough

The harness must not accept a token from a user or upstream client and blindly forward it to another resource as if it were intended for that service. Current MCP security guidance prohibits token passthrough in its context and emphasizes audience validation. FieldOps obtains or resolves a resource-appropriate credential through a trusted boundary. [CLM-011]

Never place the token in model context. The run stores a credential reference. At invocation, a trusted adapter resolves the reference, validates delegation and resource, and attaches the token outside model-visible arguments. Logs record token metadata needed for audit, not the secret.

3. Issue a delegation envelope

A delegation envelope narrows human authority into task-specific permission. AR-05 contains:

• verified principal reference;
• service and agent identities;
• task and run IDs;
• intended audience and resources;
• enumerated scopes;
• issue and expiry times;
• consequence ceiling;
• revocation state;
• credential reference and resolution rule;
• audit and policy versions.

The consequence ceiling is “one synthetic reservation.” It is not inferred from scopes. Product and formal authorities define whether such delegation is permitted. The agentic AI engineer makes the local representation enforceable.

At every capability invocation, verify the principal, task, run, agent, audience, resource, scope, expiry, revocation, and current run state. Reads need no effect approval but still need delegation. Proposals need proposal scope. Effects need both delegation and an exact approval.

Short lifetimes reduce blast radius but create refresh and waiting complexity. If FieldOps waits for human review until the delegation expires, resume cannot simply refresh in the background and continue. It must reestablish applicable identity and policy, then determine whether the old proposal and approval remain valid.

Credential resolution occurs at the tool boundary. The model sees credentialRef: inventory-for-run, not a token. The adapter maps that reference to current credentials under platform and security controls. A retrieved manual asking for the token has no path to it.

The envelope is not a portable universal standard. It is a local application contract that can be mapped to enterprise IAM. Cryptographic token format, workload identity, key management, federation, and authentication assurance remain specialist-owned.

4. Bind approval to the exact effect

Chapter 3 established exact approval fields. Chapter 6 adds verified identity, authority basis, audience, revocation, and resume behavior.

The approval binds:

• principal and authority basis;
• task, run, and proposal hash;
• protected resource;
• part, slot, quantity, and scope;
• evidence view shown during review;
• issue and expiry times;
• one-use, consumed, and revoked state.

An approval interface can serialize a run, show a proposal, receive approve or reject, and resume later. Current SDK documentation demonstrates such mechanics. It does not establish whether the reviewer was authorized or whether the resumed proposal still matches. The local harness must enforce those properties. [CLM-012]

Current MCP elicitation provides structured and URL interaction modes plus accept, decline, and cancel responses. It warns about sensitive data and session-only state binding. Elicitation is an interaction primitive, not authority proof. Never request passwords, tokens, or private credentials through a model-visible form.

Consent is contextual

Use “consent” precisely. In this chapter it means an informed application interaction in which a verified principal accepts one described synthetic effect. It does not claim legal consent, clinical consent, privacy consent, or sector-specific authorization. Those meanings belong to their named authorities.

The reviewer must see effect-relevant fields and consequence. A friendly summary can accompany them, but the displayed object and executed canonical proposal must be the same. If the proposal changes, the previous approval no longer matches.

5. Revalidate expiry, revocation, and resume

Authority can change while a run waits.

Before every invocation, FieldOps checks delegation expiry and revocation. Immediately before an effect, it repeats those checks and validates the approval. Revocation wins over cached eligibility. Expiry at the exact boundary is treated as expired in the fixture.

Approval can be revoked independently of the access token. A user can retain permission to read inventory while withdrawing approval for this reservation. A token can be revoked while an approval record remains historically valid. Both must pass at dispatch.

A consumed approval cannot be replayed. Consumption requires concurrency-safe enforcement in a real authority/effect boundary; the local fixture demonstrates only the semantic rule. If two workers race, storage and transaction design must ensure at most one permitted dispatch under the application’s guarantee.

Resume is a new decision point. Revalidate:

1. principal status and authentication context;
2. service and agent eligibility;
3. task and run still active;
4. token audience and scopes;
5. resource still admitted;
6. delegation not expired or revoked;
7. proposal hash and effect fields unchanged;
8. approval live, unused, and unrevoked;
9. inventory and domain evidence still fresh;
10. budgets and cancellation state.

A serialized framework state can help resume control flow. It cannot carry stale authority across time.

Audit every decision with principal, service principal, agent, task, run, resource, audience, scope, proposal hash, approval and effect identifiers, result, reason, and timestamp. Redact credentials. Preserve enough to distinguish authentication failure, audience mismatch, missing scope, proposal mutation, expiry, revocation, replay, and service failure.

6. FieldOps attack lab

Begin with one valid synthetic invocation. It carries the exact AR-05 delegation, inventory audience, proposal, and live unused approval. The deterministic check passes.

Changed slot

Replace slot-B2 with slot-C9. Deny with approval_slotId. Compatibility does not matter; the effect is different.

Changed part

Replace part-A17 with another part. Deny with approval_partId. A category approval cannot cover substitution.

Another run

Copy the approval into run:fieldops-999. Deny. Stable task and run binding prevents context replay.

Expired approval

Evaluate at expiresAt. Deny. The time comparison is deterministic and does not ask the model whether the approval remains reasonable.

Revoked delegation

Set delegation revocation before dispatch. Deny even though the token and approval have not yet expired. Record the revocation reason without exposing credential material.

Cross-resource audience

Present a manuals-audience token to inventory. Deny. The presence of a valid signature or user identity does not make the token suitable for this resource.

Credential in prompt

Attempt to pass a token through model-visible arguments. Deny and raise a security audit reason. The correct path is credential reference resolution inside the trusted adapter.

Session hijack

Supply only session-123 with no verified principal. Deny. A session locator can retrieve state; it is not a principal or authorization grant.

Every attack ends with a typed decision and one terminal or recovery disposition. A denial does not ask the model to repair identity. It returns to a governed authorization flow or stops.

Follow the authorization path

Walk one valid effect from login to verification without collapsing the identities.

The user authenticates to the FieldOps application. The application receives a verified principal reference under its identity policy. This creates an application session, not a blanket grant to inventory.

The user starts task:fieldops-104. Product policy permits a synthetic recommendation workflow. The task contract sets a maximum consequence of one approval-bound reservation. The harness creates run:fieldops-001 and agent instance agent:fieldops-reader-001.

For equipment and manual reads, the trusted credential component obtains or resolves resource-appropriate access. The model sees capability schemas and credential references only. Each adapter verifies audience, scopes, task, run, agent, resource, expiry, revocation, and policy before invoking the service.

The agent gathers evidence and constructs a proposal. The harness canonicalizes it as part part-A17, slot slot-B2, quantity one, with task, run, resource, principal, and evidence references. The hash identifies exactly that representation.

The approval interface displays the canonical effect fields and consequence to a reviewer. The authority service verifies the reviewer against a synthetic inventory-reservation-reviewer policy and issues an approval record. The UI did not create authority; it conveyed a proposal and collected a decision from an identity whose eligibility was checked elsewhere.

The run may wait. At resume, the harness checks that the task and run remain live, that no cancellation occurred, and that the proposal has not changed. At dispatch, the capability adapter resolves a current inventory-audience credential, validates delegation and approval, checks expiry and revocation, and calls the narrow effect.

The service authenticates the calling service, validates the resource token, and applies its own authorization. The local approval check remains necessary because a scope such as reservation:effect:one does not identify which exact proposal was accepted.

After execution, the harness records and verifies the effect. Audit connects principal, service, agent, task, run, token metadata, proposal, approval, policy decision, key, effect, and completion. Each identity retains its own meaning.

This path has several enforcement points. A valid user session can coexist with an invalid resource token. A valid token can coexist with a revoked task delegation. A valid delegation can coexist with an expired approval. A valid approval can coexist with stale inventory. Execution requires all applicable predicates.

Distinguish authentication, authorization, delegation, and consent

Authentication establishes confidence that an actor or workload corresponds to an identity under a mechanism and policy. It does not answer what the identity may do in this task.

Authorization is a decision that a principal may perform an operation on a resource under policy. OAuth access and resource-server policy are part of this layer. Authorization can be necessary without encoding the product’s exact effect contract.

Delegation narrows one principal’s authority into a task, agent, resource, scope, consequence, and duration. It explains why this agent instance may invoke a capability for this run.

Consent or approval interaction records an informed choice about a described proposal. Formal meanings vary by domain and law. FieldOps uses a deliberately narrow synthetic application meaning.

These can fail independently. A principal may authenticate successfully but lack effect scope. A token may be valid for inventory while the task delegation is expired. A reviewer may click approve but lack the authority basis. An eligible reviewer may approve a proposal that later changes. The harness needs reason codes precise enough to identify the failed layer.

Avoid messages that leak security detail to an untrusted caller. The audit can record audience_mismatch while the model receives a bounded DENIED disposition and allowed next step. Security owners determine disclosure policy.

Design revocation as a first-class event

Revocation is not merely token expiry ahead of schedule. Different objects can be revoked:

• user or service identity eligibility;
• task delegation;
• access token or credential reference;
• agent instance admission;
• approval for one proposal;
• resource or capability version;
• the run itself through cancellation.

Each revocation event names object, issuer, authority basis, effective time, reason, affected scope, and audit reference. The harness checks the relevant revocation sources at invocation and immediately before effect.

Caching creates a trade-off. A long cache improves latency and weakens revocation responsiveness. Set maximum staleness according to consequence and infrastructure guarantees. An effect gate may require an online check even when reads accept a short-lived cached decision.

If revocation arrives during an in-flight effect, record the ordering that the local system can establish. Prevent future calls and reconcile the possible outcome. Do not claim revocation can undo a committed reservation.

Approval revocation should invalidate waits and resumes. A later approval for the same effect is a new record with its own time and authority evidence, not removal of the revocation history.

Bind audit to decisions

An authorization audit should answer:

1. Which principal initiated and which principal approved?
2. Which service and agent instance acted?
3. Which task and run governed the call?
4. Which resource and audience received it?
5. Which scopes and resource constraints were evaluated?
6. Which proposal and effect fields were bound?
7. Which policy, delegation, credential metadata, and approval versions applied?
8. Were expiry, revocation, and one-use checks current?
9. What decision and reason resulted?
10. Which effect and verification records followed?

Audit fields need provenance. A model-generated principalId is untrusted input. The trusted boundary supplies or verifies identity references. Event schemas should say which actor asserted each field.

Protect the audit itself. Apply access control, integrity mechanisms, retention, redaction, and deletion policy. A log containing tokens or personal content can become a new breach surface. Credential value is never required to prove that a token reference, issuer, audience, scope, and expiry were checked.

Audit is evidence, not automatic accountability. Owners must review denials, revocations, replay attempts, and anomalous scope. Product and governance teams decide which events require user notice or incident response.

Identity and delegation design review

Create four linked maps.

The identity map lists humans, workloads, agents, tasks, runs, and resources, along with issuer and assurance references. The authority map lists who can request, delegate, approve, execute, revoke, and verify each effect. The credential map lists audience, scopes, storage boundary, resolution point, rotation, expiry, and revocation. The audit map links every decision to evidence and owner.

Review for confused-deputy risk. Can the harness use its service credential on behalf of an unauthorized task? Can one resource trick it into presenting a token to another? Can untrusted content choose an authorization endpoint? Can one tenant or user supply an identifier for another resource? Audience, task binding, resource validation, and trusted configuration address different parts of this problem.

Review for authority laundering. Can a model turn a read scope into an effect through a broad capability? Can one approver’s category confirmation be attached to a changed proposal? Can a handoff or resumed session lose the original principal? Exact contract and proposal binding prevents the authority chain from becoming narrative.

Review for credential leakage. Search model inputs, tool arguments, traces, errors, event payloads, analytics, and support exports. Use synthetic canary values in tests. The correct design exposes credential references only to the model-facing region and resolves secrets in the trusted adapter.

Review for lifecycle gaps. What happens when employment status changes, a task is cancelled, an agent version is withdrawn, a token expires, an approval is revoked, a resource changes issuer, or a run resumes after deployment? Each event needs a revalidation or terminal rule.

Negative-test matrix

Mutation tests should isolate one binding at a time.

Change the principal while preserving the token and proposal: deny. Change the service principal to an unadmitted workload: deny. Change the agent instance: deny unless policy explicitly reissues delegation. Change the task or run: deny. Change the resource or audience: deny. Remove a required scope: deny. Add a broader scope to the request without authority: deny.

Move time to the exact delegation expiry: deny. Revoke the delegation one instant before effect: deny. Keep delegation live but revoke the approval: deny. Mark approval used: deny replay. Change the proposal hash, part, slot, quantity, or scope: deny. Change only a non-effect display field: canonicalization rules determine whether the proposal hash changes; the rule must be stable and reviewed.

Expose a credential to the model: deny and audit. Supply a session with no principal: deny. Present a token from a different issuer or unsupported authentication context: deny under enterprise policy. Attempt to use an inventory token at manuals: deny at the manuals resource too.

For each test, assert the reason, absence of capability dispatch, stable run identity, and one final disposition. A 401 or 403 response alone is not enough if the harness then asks the model to try another token.

Review AR-05 v1.0.0

The dossier now names six identity objects, one task-specific delegation, a no-passthrough credential rule, one exact approval, two revocation checkpoints, eight attack fixtures, and a minimum audit field set.

The controls narrow capability but do not prove formal authority, legal consent, or enterprise assurance. OAuth validity is necessary for the resource interaction and insufficient for the business effect. The NIST source is problem framing only. Provider approval and elicitation mechanisms are examples, not universal protocols for authority.

The trade-off is visible. Narrow audience, scope, and time create more authorization round trips. Revalidation adds latency. Exact approvals can become stale. Those costs purchase a smaller blast radius and a traceable connection between principal and effect. Product and authority owners decide acceptable interaction; the harness prevents convenience from silently broadening permission.

Common identity mistakes and trade-offs

Token equals authority. A valid token represents protocol authorization for its resource and scopes. It does not automatically authorize a particular business effect.

Session equals principal. A session is a state locator and interaction mechanism. Bind it to a verified principal through trusted application controls and revalidate on resume.

User equals service. The harness uses workload credentials to reach infrastructure. Preserve the human delegation instead of attributing every call to the service or forwarding a broad user credential.

Approval by category. “Allow inventory action” cannot authorize an exact reservation. Bind part, slot, quantity, resource, task, run, proposal hash, and time.

Long reusable delegation. Broad scopes and long lifetimes reduce prompts while increasing blast radius. Narrow by task, resource, consequence, and duration, then design an explicit refresh path.

Credential in prompt or tool arguments. The model does not need the secret. Resolve a reference inside a trusted adapter and keep credential values out of context, traces, and errors.

Revocation checked only at login. A run can wait longer than the authority remains valid. Check at invocation, resume, and immediately before effect.

OAuth as a complete consent system. OAuth solves defined authorization delegation problems. Business authority, legal consent, and domain-specific approval need additional policies and owners.

Agent identity as personhood. Agent instance identity supports policy and attribution. It does not make the software an independent legal or moral principal.

Narrow delegation increases authorization traffic and can frustrate users. Reduce unnecessary friction by separating low-consequence reads from effects, caching only within governed staleness, presenting clear exact proposals, and preserving resumable state. Do not reduce friction by making approval vague or tokens broad.

Audience-specific credentials increase token-management complexity. They also limit cross-resource misuse. Platform and identity teams may provide token exchange, workload identity, or brokered resolution; the agentic layer still maintains task and effect bindings.

Exact proposal hashes can become brittle if canonicalization includes irrelevant display fields. Define the canonical effect representation carefully. Include every field that changes consequence or execution; exclude presentation-only data through a versioned reviewed rule. Preserve the evidence view shown to the approver.

Reader authority drill

For each statement, identify what is proven and what remains missing.

“The user is logged in.” Authentication may be current. Effect scope, task delegation, approval, and resource audience remain to be checked.

“The access token contains reservation:effect:one.” The resource scope may be present. Exact proposal authority, task/run binding, expiry, revocation, and effect budget remain.

“The user clicked approve.” An interaction occurred. Verify principal identity, authority basis, displayed proposal, exact binding, time, and one-use state.

“The run was serialized after approval.” State exists. On resume, revalidate every live condition; serialization is not an authority vault.

“The token signature is valid.” Cryptographic verification may pass. Issuer, audience, expiry, scopes, resource policy, and application delegation can still fail.

“The NIST paper recommends agent identity.” The cited document frames current challenges as a concept paper. It is not a finalized standard or assurance claim.

“The same person approved yesterday.” Identity continuity does not preserve approval. This proposal, run, resource, policy, and validity window need a current matching record.

“The service account can reserve stock.” Technical access held by a service is not proof that this task has delegated human or organizational authority.

Phase 7 handoff fields

Chapter 7 will classify workflow truth, model context, scratch state, durable artifacts, and memory. AR-05 supplies the permission metadata every class needs: principal, service, agent, task, run, resource, audience, scope, issue and expiry times, revocation state, proposal and approval references, effect ID, and audit reason.

State objects must not outlive their authority silently. A memory derived under one principal or resource scope cannot be retrieved by another merely because it is relevant. A resumed artifact must retain provenance and permission references. A model-context summary cannot contain credentials or become authority.

Deletion and retention decisions remain with privacy, legal, product, platform, and domain owners. The agentic engineer ensures that state carries enough identity and provenance to enforce those decisions and to explain when evidence is unavailable.

Learning lab

Build an identity map and delegation packet for the five FieldOps capabilities. Keep human, service, agent, task, run, resource, token, proposal, approval, and effect separate. Run changed-part, changed-slot, other-run, expiry, revocation, cross-audience, credential-exposure, and session-only tests.

Score 20 points: identity separation 5, audience/scope 5, approval binding 6, revocation/audit 4. Automatic failure occurs if a token is placed in model context, a session is treated as authority, a changed effect passes, or resume skips revalidation.

Build an identity graph that software can verify

An identity diagram is insufficient unless every edge names its issuer, evidence, validity, and enforcement point. Represent nodes for human principal, application service, agent instance, task, run, resource, proposal, approval, and effect. Represent edges such as authenticated-by, acts-for-task, admitted-to-run, targets-resource, approved-by, and produced-effect.

No edge is inferred from proximity. A human opened a session does not mean every run in that session acts with their current authority. An agent instance belongs to a run because trusted runtime state says so, not because the model emits the run ID. An approval targets a proposal because a canonical hash and authority record bind them, not because both mention the same slot in prose.

For each edge record:

• asserting component and issuer;
• evidence or credential reference;
• subject, audience, resource, and tenant;
• task/run and allowed consequence;
• issue, not-before, expiry, and revocation state;
• policy and schema version;
• verification component and last check;
• audit reason and uncertainty.

Distinguish identity from labels

Names such as agent-1, session-8, or inventory-bot are locators. Identity depends on a trusted registration and lifecycle. If an attacker can select the label in arguments, it is not sufficient attribution.

FieldOps uses synthetic references, but preserves the design distinction. principal:north-reviewer-1 is asserted by the identity fixture. service:fieldops-harness is asserted by workload configuration. agent:run-201-reader is created by the runtime. The model sees only the minimum references needed for its task; it cannot mint or swap them.

Carry provenance through handoffs

If a reader agent hands a proposal to a reviewer agent, the handoff cannot replace the initiating principal or task. It adds a new agent/ownership edge under the same delegation envelope or a narrower derived envelope. The receiving agent verifies issuer, audience, task, scopes, expiry, and parent reference.

A summary that says “user approved” is not authority. The receiving boundary resolves the approval record and proposal hash. Narrative context assists reasoning but never creates an identity edge.

Issue and attenuate a delegation envelope

Delegation begins after authentication and product/task admission. The authority service receives a verified principal reference, requested task, resources, capability classes, consequence ceiling, duration, and policy context. It returns the smallest accepted envelope or a denial. The model does not negotiate scopes.

Use this procedure:

1. Verify the initiating principal and application session under enterprise policy.
2. Admit the task and establish the maximum consequence.
3. Enumerate capabilities/resources actually required by the current stage.
4. Intersect requested scopes with principal, product, tenant, and service policy.
5. Bind task, run, agent class, audience set, effect ceiling, and time window.
6. Store only a delegation record and credential references in run state.
7. Resolve resource-specific credentials at the capability boundary.
8. Revalidate before every invocation and immediately before effect.
9. Record attenuation, expiry, revocation, use, and terminal disposition.

{
  "delegationId": "del-201",
  "issuer": "fieldops-authority-fixture",
  "principal": "principal:north-1",
  "service": "service:fieldops-harness",
  "task": "task:201",
  "run": "run:201",
  "agentClass": "fieldops-reader-proposer",
  "resources": ["manuals:north", "inventory:north"],
  "scopes": ["equipment:read", "manual:read", "inventory:read", "reservation:propose"],
  "maximumEffect": "NONE",
  "issuedAt": "2026-08-16T10:00:00Z",
  "expiresAt": "2026-08-16T10:30:00Z",
  "revocationRef": "revocations:del-201",
  "credentialRefs": ["cred:manuals-read", "cred:inventory-read"]
}

An effect requires a separately admitted envelope or capability gate plus exact approval. Adding reservation:effect:one later creates a new versioned delegation decision; it does not mutate history silently.

Attenuation only

A child delegation can remove resources, scopes, time, consequence, or budget. It cannot add them. If a research worker needs only manual search, derive an envelope for manuals read with shorter expiry. If it returns a proposal, the parent harness verifies the artifact; the child does not inherit reservation effect.

Enforce monotonic attenuation deterministically. Compare issuer, tenant, resources, scopes, consequence order, expiry, task, and audience. A handoff that requests more returns DELEGATION_WIDENING_DENIED and escalates to the authority flow.

Resolve OAuth access at the resource boundary

OAuth controls apply to defined protocol interactions. They do not encode the full FieldOps business decision. Use them precisely.

Discover trusted resource metadata

The client obtains authorization/resource metadata only through trusted configuration and validated discovery rules. Untrusted manual text, tool output, or model arguments cannot choose an authorization server, token endpoint, or resource URI. Pin issuer/resource relationships under platform and IAM review.

Validate TLS and endpoint expectations, issuer consistency, supported methods, resource identity, and metadata freshness according to the selected standards and enterprise policy. Record metadata version/reference without placing secrets in traces.

Request the intended resource

The authorization request identifies the resource/audience required by the capability. A manuals token is not a generic user token. An inventory token is not valid for manuals, even if both systems trust the same issuer. Resource indicators and audience validation reduce cross-service token misuse within their applicable designs. [CLM-011]

Request the minimum scopes for the stage. Read-only runs do not request reservation effect. The fact that a principal could receive a broader token is not a reason to issue it. Scope minimization reduces blast radius but does not replace exact application policy.

Protect the authorization code flow

For applicable public-client authorization-code flows, use current protections such as PKCE and follow the relevant OAuth security guidance. Do not copy authorization codes, verifiers, or tokens into model context. Exact flow and client type remain IAM/platform decisions.

The chapter preserves normative source strength but avoids inventing requirements for flows not in use. FieldOps uses deterministic credential fixtures and cannot claim a deployed OAuth implementation.

Resolve, do not pass through

The model-facing invocation contains credentialRef: inventory-read, not a token. The trusted adapter resolves the reference for the expected resource, verifies metadata/expiry/revocation, and attaches it outside model-visible arguments.

Never accept a user-supplied bearer token and forward it to another resource. Passthrough confuses audience, exposes credentials, and can turn the harness into a deputy. Current MCP security guidance prohibits token passthrough in its context. [CLM-011]

Resource-server enforcement

The inventory fixture validates issuer, audience, expiry, scope, tenant/resource, and calling service. The application separately validates task delegation, run, proposal, approval, effect budget, and cancellation. A resource token can be valid while application effect authority is absent. Both layers must pass.

Bind approval under concurrency

An approval record is an immutable decision about one canonical effect proposal. Canonicalization includes principal/task/run, target resource, effect class, part, slot, quantity, tenant, evidence version, consequence, capability version, and any field whose change affects execution or review.

The evidence view shown to the approver has its own hash and rendering version. This matters because exact backend fields can be hidden or misleading in UI. Accessibility and domain owners review presentation. The harness can prove which view was displayed; it cannot prove the human understood it.

{
  "approvalId": "ap-201",
  "proposalHash": "ph-201",
  "evidenceViewHash": "evh-201",
  "principal": "principal:north-reviewer-1",
  "authorityBasis": "fixture:reservation-reviewer",
  "task": "task:201",
  "run": "run:201",
  "resource": "inventory:north",
  "effectClass": "SYNTHETIC_RESERVATION",
  "issuedAt": "2026-08-16T10:12:00Z",
  "expiresAt": "2026-08-16T10:17:00Z",
  "oneUse": true,
  "status": "UNUSED"
}

Consume with a compare-and-set decision

Two workers can resume the same approval. The effect boundary must atomically establish that approval is live/unused, proposal matches, delegation is live, effect budget remains, and this attempt owns dispatch under the storage guarantees. A framework pause/resume object cannot supply those guarantees by itself.

The local fixture models a revision guard: UNUSED@4 -> CLAIMED@5 -> CONSUMED@6 or RELEASED_UNUSED if proven pre-dispatch cancellation. A timeout after possible dispatch does not make approval unused again. It remains linked to the ambiguous intent until reconciliation.

If approval expires between claim and dispatch, deny before effect. If revocation becomes effective after dispatch, stop future actions and reconcile; do not claim the revocation reversed the effect.

Reject semantic mutation

Change slot, part, quantity, resource, tenant, effect type, task, run, or capability version: the canonical proposal hash changes and approval fails. A substitute that seems equivalent still needs a new proposal and decision. Domain compatibility is not cryptographic equality.

Presentation-only corrections may preserve the effect hash only under a versioned canonicalization policy and must update evidence-view history. Never let “cosmetic” become a route for hiding consequence.

Trace one valid effect and three deputy attacks

Valid effect

The application authenticates principal:north-1 and admits task:201. It creates run:201 and a read/propose delegation. The harness resolves manuals and inventory read credentials at their adapters. The model collects admitted evidence and the proposer creates ph-201.

A verified reviewer with synthetic authority sees evidence view evh-201 and issues ap-201. The authority service issues a one-effect delegation constrained to inventory North and this task/run. At dispatch, the adapter checks identity graph, audience/scope, delegation, proposal, approval, inventory freshness, budget, cancellation, and capability version. It resolves an inventory-effect credential, sends one semantic intent, records and verifies the effect, and consumes approval.

Audit proves which records were checked. It does not establish real IAM, consent law, domain validity, or reviewer comprehension.

Deputy attack 1: manuals token at inventory

The model-visible context contains no token, but a compromised adapter substitutes cred:manuals-read. Inventory validates audience and denies before application effect. Audit records credential reference, expected/actual audience classes, adapter version, and denial without recording token value.

Diagnosis belongs to credential resolution or adapter integrity, not the model. Revoke the adapter/credential reference, inspect affected calls, and preserve no raw bearer material.

Deputy attack 2: untrusted endpoint selection

A retrieved manual includes a token endpoint URL and instructs the agent to reauthenticate. The model proposes using it. No capability accepts endpoint arguments. Trusted configuration controls discovery. The attempt becomes UNTRUSTED_AUTHORITY_METADATA and stops.

This demonstrates why no-passthrough and trusted discovery complement prompt-injection controls. The model’s content classification can fail without exposing credentials.

Deputy attack 3: service credential as user authority

The FieldOps service account can technically call inventory. A run with no principal/task delegation tries to reserve. Resource authentication alone might accept the service, but application policy denies MISSING_DELEGATION. Service capability is not evidence of user or organizational authority.

If the application ever performs service-owned maintenance, give that task its own service-principal contract and authority. Do not blur it into on-behalf-of user activity.

Operate expiry and revocation races

Time and revocation are state transitions, not annotations.

Race	Required disposition
token expires before adapter resolution	deny; refresh only through governed flow
delegation expires while model reasons	remove affected capability; request renewal or stop
approval expires while paused	deny resume to effect; preserve historical decision
run cancelled before dispatch	deny and invalidate/close pending authority per policy
approval revoked before dispatch	deny even with live token/delegation
principal disabled during wait	revalidation denies; transfer only through authorized process
revocation after possible commit	stop future effects and reconcile outcome
resource metadata changes issuer	quarantine credential path and re-review trust
capability version revoked	deny old adapter and migrate/quarantine state

Design revocation latency

Record source, propagation, cache, check point, maximum staleness, and consequence. A read may accept a short cached policy decision. An approval-bound effect may require a current online decision. Platform/IAM owners establish guarantees; the application aligns exposure and states residual windows.

Test primary revocation service unavailable. The safe choice for the synthetic effect is fail closed or reduce to read/propose according to declared policy. Do not silently use a stale allow decision for availability.

Resume after deployment change

A paused run was created under approval canonicalization v1 and resumes under v2. If v2 changes effect fields, old approval cannot transfer. Quarantine the checkpoint, render the old proposal, and require a new proposal/approval under the new version. If the change is demonstrably presentation-only, a compatibility rule still needs evidence.

Serialized state preserves history. It does not freeze resource policy, identity eligibility, token validity, capability version, or approval forever.

Build the identity and authority double

The deterministic fixture has an identity registry, workload registry, resource metadata, token-reference store, delegation store, approval store, revocation stream, seeded clock, and audit sink. It uses inert strings, never real credentials.

Support controlled mutations:

• wrong issuer, audience, resource, tenant, or scope;
• token expired/not-yet-valid/revoked;
• unknown service or agent instance;
• widened child delegation;
• task/run mismatch;
• proposal/evidence-view mutation;
• approver lacks authority basis;
• approval expired/revoked/used;
• concurrent consumption;
• cancellation before and after dispatch;
• credential value placed in model arguments;
• session with no verified principal.

For every denial assert no effect dispatch, no alternate-token search by the model, no authority mutation, one bounded model result, and one protected audit event. Scan prompts, tool arguments, traces, errors, snapshots, and exports for fixture secret markers.

Test audit truth

Mutate a model-provided principal to match the real principal. The boundary must still ignore or reject the untrusted assertion. Remove issuer evidence from an audit event; completeness must fail. Reorder revocation and dispatch events; the conclusion must follow authoritative sequence/version rather than timestamp guess.

Audit can itself be wrong or incomplete. Compare it with approval/authority/effect stores. If evidence cannot establish order, mark unknown and choose the safe operational state.

More identity counterexamples

Valid signature, wrong audience. Cryptographic validity does not make a token usable at every resource.

Right user, wrong task. A principal may hold general access but has no delegation for this run/effect.

Right approval, changed capability. A new adapter changes effect semantics. Old approval does not authorize it.

Long-lived convenience token. It reduces round trips and increases blast radius, stale authority, and leakage consequence. Broker/resource-specific short references instead.

Approval in chat. “Yes, do it” lacks canonical proposal, verified approver, authority basis, evidence view, expiry, and one-use state.

Session takeover detection only. Detecting suspicious session use after effect is useful but not a substitute for reauthentication and binding before effect.

Agent has its own identity. Agent-instance identity supports policy and audit. It does not create independent business, legal, or moral authority.

OAuth means consent. Protocol authorization and legal/domain consent answer different questions. Keep names and owners distinct.

Extended FieldOps attack exercise

Produce four artifacts: identity graph, resource/audience map, delegation envelope, and exact approval record. Then execute these cases:

1. valid read with resource-specific credential resolution;
2. manuals token presented to inventory;
3. scope missing while audience is correct;
4. child delegation attempts wider effect scope;
5. slot changes after approval;
6. quantity changes through canonicalization edge case;
7. approval copied to another run;
8. approval expires at boundary time;
9. approval and delegation revoked independently;
10. two workers claim one approval;
11. run resumes under changed capability version;
12. credential marker appears in tool error;
13. untrusted content supplies authorization endpoint;
14. session ID arrives without principal;
15. revocation arrives after ambiguous dispatch.

For each state authentication, authorization, delegation, approval/consent, dispatch, audit, and next transition separately. A generic DENIED may be correct for model exposure but the protected audit needs the precise failed layer.

Incident packet

Inject a cross-audience token accepted by a buggy resource fixture. Contain by revoking credential reference and adapter version, stopping effects, listing affected runs/effects, and preserving minimal audit. Determine whether application task/approval gates independently blocked any dispatch. Repair resource audience validation and add a negative fixture. Reissue no credential until trusted metadata and configuration are reviewed.

Do not claim no consequence because the application layer also denied in the tested run. Search the scoped fixture for all uses. Security/IAM owners direct real credential/incident response; the Agentic AI Engineer supplies run/effect evidence.

Rubric expansion

The frozen 20 points remain identity separation 5, audience/scope 5, approval 6, revocation/audit 4.

Full identity credit requires distinct human, service, agent, task, run, resource, proposal, approval, effect, and asserting provenance. Audience/scope credit requires trusted metadata, resource-bound least privilege, no passthrough, credential resolution, and resource enforcement. Approval credit requires canonical effect/evidence view, authority basis, expiry/revocation/one-use, concurrency, and mutation denial. Revocation/audit credit requires lifecycle races, fail-closed effect policy, credential scans, reason provenance, and incident response.

Automatic failure: token enters model context, session is authority, mutated effect passes, broader child delegation passes, or resume skips revalidation.

Final AR-05 defense

The reviewer selects one synthetic effect and walks backward from effect to capability, approval, proposal, evidence view, delegation, task/run, agent, service, resource token metadata, and initiating principal. Every link must name a trusted issuer and version.

Then mutate one dimension at a time: principal, service, agent, task, run, tenant, resource, audience, scope, capability version, part, slot, quantity, clock, revocation, and one-use state. Every mutation either denies or enters a separately governed renewal flow. None asks the model to obtain a broader token.

The reviewer pauses after approval, changes deployment, revokes the principal, and advances time. Resume must not carry stale authority. The reviewer races two workers; one effect path at most may claim the approval under the fixture semantics, and ambiguous dispatch remains consumed/pending reconciliation.

Finally state non-claims. The deterministic identity fixture does not implement enterprise IAM, prove cryptographic architecture, establish privacy/legal consent, define regulated authorization, prove human understanding, or certify a real resource. OAuth controls are necessary within their protocol scope and insufficient for the exact business effect. The NIST material remains a concept paper, not a standard.

Operational handoff to state and memory

Chapter 7 will receive identity/permission fields as state metadata, not model prose. Every object records owner principal, tenant/resource, task/run, allowed readers/writers, authority reference, source, issue/expiry, revocation behavior, retention, and deletion.

A workflow-state object can remain authoritative after its access credential expires, but access requires a new live decision. An artifact retains provenance from the principal/task that created it. A context projection is temporary and cannot be replayed as authority. A cross-run memory needs a new admission decision and cannot inherit the broadest historical scope.

On handoff, test that South cannot read North state, a new run cannot reuse old approval, a deleted principal’s memory follows policy, and a resumed checkpoint revalidates every external identity edge. Keep credentials out of all state classes.

This continuity ensures that identity is not solved once at login. It remains attached to every state transition, capability, approval, effect, artifact, and later retrieval.

Multi-resource authorization walkthrough

Use one FieldOps run that touches equipment, manuals, and inventory. The initiating principal is authenticated once to the application, but each resource interaction receives its own decision.

For equipment, the delegation allows equipment:read for one North record. The credential resolver selects an equipment-audience reference. The equipment service validates issuer, audience, scope, service principal, and resource. The application records the observation with task/run provenance.

For manuals, the resolver selects a manuals-audience reference with search scope. The manual service cannot receive the equipment token. Retrieved passages remain untrusted data and carry source policy. The delegation permits evidence collection, not instructions or effects.

For inventory read, the resolver selects inventory audience and inventory:read. The application restricts part and location from task/evidence; the resource checks its own access. When the system creates a proposal, no resource token becomes approval.

For reservation effect, the authority path adds an exact one-use approval and effect delegation. A newly resolved inventory-effect credential is necessary but insufficient. Dispatch requires the entire predicate: principal active, service/agent admitted, task/run live, resource/audience correct, scope present, delegation unexpired/unrevoked, proposal unchanged, approval authorized/live/unused, evidence fresh, budget available, and cancellation absent.

This walkthrough prevents the phrase “on behalf of the user” from hiding four different resource decisions.

Partial failure

Suppose manuals authorization succeeds and inventory read fails audience validation. Preserve admitted manual evidence, record inventory denial, and stop the transition that needs inventory. Do not ask the model to reuse the manuals token. Do not invalidate the user’s whole session unless identity policy requires it.

Suppose inventory read succeeds but effect credential resolution fails. The proposal can remain a versioned artifact until expiry, but no reservation is dispatched. The UI states authorization unavailable, not inventory unavailable.

Suppose effect succeeds and audit delivery fails. Authoritative effect remains real. Enter an evidence/incident state, repair audit delivery, and never repeat the effect to obtain a cleaner trace.

Approval usability without authority dilution

Exact binding can fail socially if reviewers cannot understand the proposal before expiry. Design the review view around decision-relevant fields: action, resource, part, slot, quantity, consequence, evidence freshness, alternatives, uncertainty, expiry, and what approval does not authorize.

Offer approve, reject, request information, and take over as distinct transitions. A request for information does not preserve effect authority indefinitely. Takeover transfers work under a new owner and records what happens to the pending approval. Rejection cannot be treated as a prompt to find another reviewer with the same unchanged proposal.

Measure queue time, expiry, rejection reason, evidence retrieval, takeover, repeat prompts, and post-review mutation. A high approval rate may indicate clear valid proposals or rubber stamping. Sample review quality under product/domain authority. The technical system can enforce exact binding but cannot guarantee attention or comprehension.

Avoid consent dark patterns

Do not make approval the visually dominant path, hide effect detail, bundle unrelated permissions, imply service loss for rejection, or repeatedly reprompt after denial. Legal/privacy/product owners define applicable consent requirements. The Agentic AI Engineer ensures the record accurately represents the effect and that refusal produces a safe state.

Confirmation examples from one browser-agent product family demonstrate bounded patterns, not universal interface authority. [CLM-012] FieldOps must validate its own synthetic flow and preserve formal authority outside the UI.

Authority loss incident drill

The synthetic reviewer approves ph-201. Before dispatch, the principal’s task delegation is revoked, but the resource token cache still reports valid for thirty seconds. A worker attempts reservation.

The effect boundary checks the live delegation source, denies dispatch, marks approval unusable for this run under policy, and records DELEGATION_REVOKED. It does not rely on token cache because OAuth resource validity and application delegation are separate.

Inject a defect that checks delegation only at approval time. The reservation commits during the cache window. Declare an authority incident. Stop the capability version, list effects between revocation and containment, preserve approval/delegation/effect ordering, and transfer consequence decisions to domain/incident authorities. Revocation cannot reverse committed effect.

Repair by moving a revision-guarded delegation check to the final effect boundary, adding a fixture at the exact race, and including effective revocation version in the dispatch evidence. Replay approval, cancellation, timeout, and ownership cases to ensure the new check does not create blind retry.

Unreachable revocation source

If the revocation service is unavailable, the effect policy fails closed or reduces to propose-only as predeclared. Reads may use bounded cached decisions if IAM policy permits. State the residual staleness. Availability is not a reason to interpret unknown authority as allow.

Late revocation event

If event delivery is late, use authoritative effective time/version where available. A received-at timestamp alone may misclassify ordering. If order cannot be established, mark the effect authority uncertain and escalate. Do not edit audit history to manufacture certainty.

Identity design decision table

Observation	What it proves	What remains
application login valid	session is linked to authenticated principal under policy	resource audience, scopes, task delegation, effect approval
resource token valid	resource protocol checks passed for scopes/audience	exact business intent and approval
task delegation live	task/run may use named capabilities within envelope	current resource token, proposal, approval, state
proposal hash matches	effect representation is unchanged	approver eligibility and live authority
approval live and unused	one recorded decision remains available	delegation, token, freshness, cancellation, atomic claim
capability dispatch accepted	enforcement admitted one attempt	external commit and verification
effect verified	named synthetic effect matches authoritative state	broader consequence, safety, legal or production fitness

Use the table in incident reviews. A green row never implies the rows beneath it. This prevents a valid token or approval from becoming a universal success marker.

Extended delegation exercise answer procedure

Start with a valid packet. Draw all principals/resources and mark trusted issuers. Show model-visible versus trusted fields. Produce three resource-specific credential references and prove no value enters context. Issue a read/propose envelope, attenuate it for a manual-search worker, and reject a widened child.

Create a canonical reservation proposal and evidence view. Issue approval from an eligible synthetic reviewer. Pause the run, advance the clock, revoke one object, and resume. The learner must say exactly which predicate fails and whether the artifact remains useful.

Race two workers for approval. Inject timeout after possible commit. Approval cannot reset to unused merely because a response is missing. Reconcile the effect first. Then change capability version and show why approval migration is blocked.

Finally write a denial response safe for model context and a richer protected audit event. Neither contains credential values or unnecessary personal content. Define retention/access owners rather than claiming universal policy.

Reviewer’s final probes

Who asserted the principal? Who authenticated the service? Can the model choose audience? Where is PKCE applicable and who owns the flow? Can a valid manuals token reach inventory? What exact bytes/fields were approved? What happens at the expiry instant? Can two workers consume approval? Which revocation source is authoritative? What if it is down? What state survives denial? Which owner decides legal consent and domain authorization?

Any answer that says “OAuth handles it,” “the user is logged in,” or “human in the loop” without the specific record fails the probe.

AR-05 acceptance checklist

Verify distinct human/service/agent/task/run/resource identities and provenance. Verify trusted metadata, audience-bound least privilege, applicable code-flow protections, no passthrough, credential references, and resource validation. Verify attenuation, exact proposal/evidence binding, authority basis, expiry, revocation, one-use concurrency, resume revalidation, and cancellation.

Verify all fifteen negative fixtures deny without effect. Verify secrets scans across prompts, tool calls, traces, errors, checkpoints, analytics, and exports. Verify audit connects identity, delegation, proposal, approval, capability, effect, and reason while remaining access-controlled. Verify version migration and authority-loss incident drills.

Verify explicit non-claims: no enterprise IAM assurance, real credential, general agent-identity standard, legal consent, regulated authorization, human-comprehension proof, production deployment, or real-world effect. Verify Chapter 7 receives permission metadata rather than credentials.

The packet passes when every effect can answer who acted, for which task, against which resource, with which audience/scope, under which live delegation and exact approval, at what time/version, with what final effect evidence. It fails if any answer comes only from model narrative.

Archive the identity graph, trusted metadata references, delegation and approval schemas, canonicalization version, revocation fixtures, audit mappings, denial reasons, secret-scan evidence, and unresolved external decisions under one hash. Preserve expired and revoked records as history according to the synthetic retention policy; never convert them back to live authority.

The final defensive test supplies a perfectly plausible narrative, a valid session, and a matching proposal while removing the trusted principal edge. Dispatch must fail. Identity is what the verified chain establishes, not what the conversation implies.

Acceptance also requires every identifier, token, principal, approval, resource, and effect in the examples to remain synthetic. No fixture outcome implies an enterprise identity assurance level. If a later implementation introduces real credentials or people, reopen IAM, security, privacy, legal, domain, and operational review before any effect path is enabled.

Chapter checkpoint

FieldOps now has an explicit loop, five typed capabilities, and application-level identity and delegation. AR-05 v1.0.0 hands Chapter 7 principal, agent, task, run, resource, audience, scope, expiry, revocation, proposal, approval, and effect fields. The next chapter can apply ownership, provenance, permissions, retention, and deletion to every state object without collapsing context into authority.