Task-Scoped Authority for AI Agents

Abstract

An AI agent may know how to perform an action, possess credentials that make the action technically possible, and still lack permission to perform it for the task at hand. Treating those three facts as interchangeable creates ambient authority: a model can turn a mistaken inference, stale instruction or hostile input into a valid external operation. This paper proposes a task-scoped authority model that separates identity, capability, credentials and current permission. A grant names the actor and represented principal, permitted actions and resources, side-effect class, conditions, time window, budgets, approval requirements and revocation version. Effective authority is the intersection of that grant with resource policy and live conditions, evaluated immediately before each consequential action. Revocation and correction invalidate old grants; an open session or cached credential does not revive them. The proposal draws on zero-trust guidance, OAuth standards, agent-security guidance, recent research on privileged tool environments and a limited first-party prototype record. It is an architectural proposal, not a universal security guarantee. The accompanying application protocol supplies a grant schema, lifecycle, decision procedure and positive/negative permission suite.

1. Research question and scope

How can an AI system retain useful tool access while ensuring that each task can exercise only the authority actually granted to it?

The problem appears whenever a model can call APIs, write files, send messages, change records, deploy software or direct another agent. The execution environment may already contain credentials. The model may also receive instructions from users, retrieved documents, memory and tool output. None of those inputs, alone, answers the authorization question.

This paper addresses runtime authority for tool-enabled agents. It does not propose a new authentication protocol, replace established identity and access management, or claim that a policy object can determine human intent perfectly. It also does not argue that every low-risk read needs ceremony. The contribution is a practical layer between broad technical access and a particular action: a grant that is bound to one task, interpreted by a component outside the model's context, and invalidated by expiry, revocation or material correction.

2. Method and evidence boundary

The method is an evidence-informed design synthesis. We compared established access-control concepts with agent-specific failure modes, then derived a grant model and test protocol.

NIST's zero-trust architecture rejects implicit trust based on network location or asset ownership and treats authentication and authorization as discrete functions before access to a resource [1]. RFC 9396 shows how OAuth requests can represent fine-grained actions, locations, data types, identifiers and privileges rather than relying only on a coarse scope string [2]. RFC 8693 distinguishes delegation—where the actor remains identifiable while representing another principal—from impersonation, and describes narrower downstream tokens and expiry [3]. These standards do not prescribe an AI-agent task envelope, but they establish useful primitives.

OWASP's AI Agent Security Cheat Sheet recommends minimum tool sets, per-tool resource and operation scoping, authorization outside the agent context, exact-action approvals for sensitive operations and fail-closed behaviour when approval or policy lookup is missing [4]. A 2026 preprint by Goel analyses tool-enabled agents in privileged environments and identifies capability–intent mismatch and ambient-authority leakage; its empirical component is explicitly small and controlled [5]. A first-party prototype record demonstrates one bounded mission gate with admission, denial, correction and expiry handling [6]. That record is not independent validation and does not establish universal coverage.

The resulting framework should therefore be read as a testable architecture. The sources support its ingredients and threat rationale, not the effectiveness of this exact combination in every deployment.

3. Four things that must not collapse into one

3.1 Identity

Identity answers who or what is acting. For delegated work, a useful record distinguishes the human or service principal being represented from the agent, worker or process performing the action. Collapsing both into one service account weakens attribution and makes it difficult to tell whether authority was delegated, impersonated or assumed.

3.2 Capability

Capability answers what the software can technically attempt. A tool catalogue, network route or executable function creates capability. It does not create permission. Removing unnecessary tools reduces attack surface, but merely hiding a tool from the model is not sufficient if an alternative execution path can still reach it.

3.3 Credential

A credential answers what an external system will accept as proof for access. Credentials may be broad, cached or shared across tasks. Their presence is not evidence that the current task may use every right they unlock. The execution component should avoid placing secrets in model context and, where possible, obtain a narrow or short-lived credential only after the task grant passes.

3.4 Authority

Authority answers whether this actor may perform this exact action, on this resource, now, for this purpose and under these conditions. It is contextual and revocable. A user request is evidence relevant to authority, but untrusted content, historical messages and model-generated plans must not silently amend the grant.

The design principle is simple: capability and credentials set an upper technical bound; a current grant sets the permitted task boundary.

4. A task-scoped grant

A machine-readable grant should contain at least:

• grant identity and version: immutable identifier, policy version and parent grant if delegated;
• principal and actor: who is represented and which agent or process may act;
• task identity: the bounded outcome or work card to which the grant belongs;
• actions: explicit verbs such as read, draft, create, update, send or delete;
• resources: exact accounts, repositories, records, paths, domains or resource classes;
• data boundary: permitted data classes and prohibited categories;
• side-effect class: read-only, reversible local write, external write, financial, administrative or destructive;
• conditions: required source identities, risk thresholds, approvals, recipient or environment constraints;
• budgets: counts, spend, rate, storage, runtime or other bounded consumption;
• validity: activation, expiry and optional one-time-use constraint;
• revocation reference: a monotonically advancing epoch or authoritative status location;
• evidence requirements: what must be logged before and after action;
• fallback: deny, abstain, request approval or use a less powerful route.

Effective authority is not the union of every available right. Conceptually, it is the intersection of the actor's baseline access, the delegator's grantable rights, the task grant, the resource's own policy and live conditions:

effective authority = baseline ∩ delegable rights ∩ task grant ∩ resource policy ∩ live conditions

This is a design invariant, not an implemented algorithm. Any missing required term should yield denial or abstention, not broader access.

A task description may be rich prose, but the enforceable grant should be explicit about actions and resources. RFC 9396 is relevant here: it demonstrates that authorization can carry structured action, location, datatype and identifier details rather than only a coarse label [2]. The grant proposed here adds task lifecycle, side-effect classes, budgets, correction and evidence fields; those additions are not part of RFC 9396.

5. Decision and enforcement path

The policy decision must occur at the last responsible moment before the side effect, in a component the model cannot rewrite through ordinary content. A minimal path is:

1. Resolve actor and principal. Authenticate the execution process and identify whom it represents.
2. Load the current grant. Bind the request to one task and exact grant version.
3. Normalise the intended action. Resolve tool, verb, target, account, parameters, side-effect class and data categories.
4. Check lifecycle. Reject grants that are inactive, expired, suspended, consumed or superseded.
5. Check intersection. Confirm that every action, resource, datum and budget remains within both grant and resource policy.
6. Check conditions and approval. Bind any approval to the exact actor, operation, target and material parameters; stale or reusable approval is insufficient.
7. Execute through a constrained adapter. Do not hand the model a broader credential than the admitted operation requires where narrower issuance is available.
8. Read back the result. Record the external identifier or exact state needed to establish what occurred.
9. Consume or update state. Advance one-time grants, counters and audit linkage atomically with the operation where feasible.

This path separates the model's proposal from the execution service's authorization decision. It also narrows the meaning of a positive decision: admission establishes that the action matched the evaluated grant at that time. It does not establish that the model's plan was wise, the underlying data was true or the business outcome succeeded.

6. Expiry, correction and revocation

Authority needs a lifecycle because tasks change while sessions and credentials persist.

A grant can be proposed, active, suspended, revoked, expired, consumed or closed. Only active is executable. Consumed applies to one-time grants; closed records normal completion without implying continuing permission.

Three events deserve special treatment:

• Expiry: after the declared time, access is denied even if the conversation, worker or credential remains alive.
• Correction: a material change to target, principal, action or consequence supersedes the old grant. In-flight work bound to the old version must stop before another side effect.
• Revocation: an authoritative revocation epoch or status must be checked close enough to execution that cached approval cannot outlive the decision.

Long-running work cannot safely rely on a one-time check at session start. NIST zero-trust guidance supports per-request, least-privilege decisions and resource-focused protection [1]. For agents, the practical implication is periodic re-evaluation and mandatory re-evaluation before consequential writes. The appropriate freshness interval depends on consequence and infrastructure; this paper does not prescribe one universal number.

Revocation is not deletion of evidence. The system should preserve the old grant, its state transition and any completed action receipts so that investigators can distinguish permitted action before revocation from blocked action afterwards.

7. Positive and negative permission cases

A grant is not credible until both allowed and disallowed cases are exercised.

Positive cases should prove that the agent can complete the intended work without asking for a master key: read an explicitly allowed source; write inside the named workspace; update the named record with permitted fields; or send one approved message to the bound recipient.

Negative cases should include:

• same action against a sibling resource;
• allowed resource but prohibited verb;
• allowed verb and resource under the wrong account or principal;
• expired, suspended, revoked or consumed grant;
• material parameter change after approval;
• target resolved through an alias to an unapproved destination;
• instruction embedded in a webpage, document, email or tool result;
• credential present but no task grant;
• parent agent attempting to lend rights it does not possess;
• worker using a valid grant from another task;
• action requested after a correction superseded the grant;
• policy or revocation service unavailable;
• alternate tool or direct API path that bypasses the normal gate.

A denial should state the narrow proposition: which requested dimension was outside scope or unavailable. It should not expose secrets or invite the model to shop for another credential. Conversely, a correct denial should not make the whole workspace unusable; safe support work can remain available under its own explicit class.

8. Delegation and multi-agent work

Multi-agent systems make authority attenuation essential. A parent should delegate a subset, not clone its full access. Each child grant should identify the upstream principal, immediate actor, task, resources and further-delegation rule. RFC 8693's distinction between delegation and impersonation is useful: retaining both subject and actor improves attribution, whereas impersonation may make the actor indistinguishable inside a defined rights context [3]. The RFC defines token-exchange machinery, not a complete agent-governance model.

A child result should carry an authority receipt alongside provenance and quality evidence. The parent then verifies that:

• the child used the expected grant and source identities;
• no fallback route widened access;
• outputs stayed within the allowed target;
• required denials were actually exercised;
• the parent, not the child, makes any reserved acceptance decision.

Language-model confidence must not increase authority. A more capable model can make a better proposal; it cannot enlarge the grant that governs execution.

9. Alternatives and trade-offs

Static roles and service accounts are familiar and operationally efficient. They remain useful as baseline entitlements, but are often broader and longer lived than one task. Task grants can attenuate them; they do not remove the need to manage them.

Prompt-only restrictions are cheap and expressive. They are appropriate for guidance but place authorization inside the same context that may contain hostile or conflicting content. OWASP explicitly advises enforcing tool authorization in the execution component outside agent context [4].

Sandboxing reduces the blast radius of command execution and filesystem access. It complements rather than replaces authorization: a sandbox can still contain sensitive data or valid credentials, and an allowed network path can still perform an unauthorised business operation.

Human approval for every write is conservative but can create fatigue and encourage superficial confirmation. Exact-action approval should be reserved according to consequence, with low-risk bounded actions handled by policy. Approval itself must be parameter-bound and non-replayable.

Capability tokens and fine-grained OAuth can express narrow rights and reduce ambient credentials. They add issuance, revocation and interoperability complexity. A token also cannot decide whether the task description truthfully represents the human's purpose; governance remains necessary.

The principal operational cost is policy design and maintenance. Overly narrow grants can block legitimate work; broad grants recreate the original risk. False denials, approval latency, bypass attempts and operator burden should therefore be measured alongside prevented actions.

10. Practical application

The accompanying protocol provides a grant worksheet, lifecycle, admission record and test suite. A useful pilot begins with one consequential workflow and observes the permissions it genuinely needs. The team then constructs the narrowest grant that supports successful positive cases and blocks sibling-resource, wrong-verb, stale-version and hostile-input cases.

A synthetic example is an agent asked to update the delivery date on one test order. The grant permits read and update_delivery_date on record TEST-1042 in a non-production tenant until 14:30 UTC, prohibits price and payment fields, allows at most one write, and requires readback. Reading the order and changing its delivery date pass. Changing the price, selecting TEST-1043, switching tenants, retrying after the single write or acting after expiry must fail. These are illustrative cases, not executed results.

11. Limitations and evaluation agenda

This paper does not present a production comparison or formal security proof. The recent agent-security preprint uses a small controlled experiment and explicitly does not estimate prevalence at scale [5]. OWASP guidance is practitioner guidance, not independent validation of this grant schema. NIST and IETF sources establish broader principles and protocol mechanisms, not the effectiveness of the proposed lifecycle. The first-party prototype is narrow and non-independent.

Correct policy can still be undermined by a compromised enforcement component, confused resource identifiers, time-of-check/time-of-use races, stale revocation data, bugs in adapters or hidden alternate paths. Human grant issuers can approve the wrong scope. Fine granularity can impair usability and availability. Some external systems cannot issue narrow credentials or support atomic approval consumption.

A comparative evaluation should test broad standing access, prompt-only restriction and task-scoped grants on matched workflows. Measures should include unauthorized-action rate, false denial, task completion, approval latency, bypass rate, revocation latency, policy-authoring effort, operator interventions and unverified outcomes. Tests should include hostile retrieved content, stale grants, concurrent retries, aliases, nested delegation and unavailable policy infrastructure. Until such evaluation exists, the model is a defensible proposal to test—not proof that an agent is secure.

12. Conclusion

Useful agents need capabilities; they do not need every capability available to their environment. Identity, tools and credentials are necessary inputs to authorization, not substitutes for it. A task-scoped grant makes the missing question explicit: may this actor perform this exact action on this exact resource, now, under these conditions?

Binding that answer to a versioned lifecycle, enforcing it outside model context, attenuating it through delegation, and testing both permission and denial can reduce the gap between what an agent can do and what it should do. The strongest claim warranted here is architectural: task-scoped authority creates a testable boundary. Whether a particular implementation holds that boundary must still be demonstrated under adversarial and operational conditions.

References

1. Scott Rose, Oliver Borchert, Stu Mitchell and Sean Connelly. Zero Trust Architecture. NIST Special Publication 800-207, August 2020. https://doi.org/10.6028/NIST.SP.800-207
2. Torsten Lodderstedt, Justin Richer and Brian Campbell. OAuth 2.0 Rich Authorization Requests. RFC 9396, May 2023. https://www.rfc-editor.org/rfc/rfc9396.html
3. Michael B. Jones, Anthony Nadalin, Brian Campbell, John Bradley and Chuck Mortimore. OAuth 2.0 Token Exchange. RFC 8693, January 2020. https://www.rfc-editor.org/rfc/rfc8693.html
4. OWASP Cheat Sheet Series. AI Agent Security Cheat Sheet. Undated. https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
5. Hardik Goel. Security Risks in Tool-Enabled AI Agents: A Systematic Analysis of Privileged Execution Environments. arXiv:2605.09721v1, 10 May 2026; extended author preprint, with a shortened paper accepted at IEEE COMPSAC 2026. https://arxiv.org/abs/2605.09721
6. Nordlith. Task-bound authority-gate operator handoff and acceptance record. Updated 7 October 2026. First-party internal engineering record; private identities and operational details withheld.