The problem: task authority can expand without a clear decision
A user asks an agent to summarize a private forecast. The agent needs to read a specific document, process its contents, and return a draft. That request leaves several engineering questions: which processor may receive the text, where intermediate copies may live, and whether the information may be reused after the task ends.
I propose representing those limits as a task-specific grant. The grant should identify the actor, resources, permitted operations, destinations, and duration. This article describes a suggested design. The identifiers and time values below are illustrative.
Analyze the failure at the tool boundary
Consider a hypothetical workflow that receives a broad account credential after the user selects one file. The agent can now request other files, send excerpts to another tool, and write intermediate data to a persistent store. Each operation may succeed technically even though the original request did not establish that scope.
- A connector credential may cover more resources than the task needs.
- A tool name may conceal a different external destination or processing route.
- A temporary calculation may create persistent logs, caches, or embeddings.
- A completed task may leave reusable credentials and derived data behind.
OWASP recommends least privilege and authorization checks on every request. For an agent, I would apply those checks at each resource and tool boundary, including intermediate operations. The language model should not be the component that decides whether its own requested access is permitted. [1] (opens in a new tab)
Define a bounded grant
The application should create the grant after authenticating the user and checking what that user may delegate. It should preserve the selected resource and operation scope. A natural-language task description can explain the purpose, but it cannot substitute for those checks.
{
"schema": "example.task-grant.v1",
"grant_id": "grant:report-17",
"principal_id": "user:42",
"agent_id": "report-assistant",
"tenant_id": "org:7",
"task_id": "task:report-17",
"purpose": "prepare_internal_summary",
"resources": [
{
"id": "doc:forecast-q3",
"version": "v3",
"actions": [
"read",
"summarize"
]
}
],
"processor_routes": [
"service:approved-summary-model"
],
"output_destination": "workspace:private-drafts",
"output_audience": [
"user:42"
],
"issued_at": "2026-11-07T09:00:00Z",
"expires_at": "2026-11-07T09:30:00Z",
"retention": {
"working_copies": {
"delete_when_task_ends": true,
"max_age_seconds": 1800
},
"saved_draft": "user_managed",
"audit_metadata_days": 30
},
"secondary_use": {
"training": false,
"profiling": false
}
}This is an example data structure, not an existing protocol. The 30-minute grant, 30-minute maximum working-copy lifetime, and 30-day metadata period are arbitrary choices. A trusted service must protect the grant against modification. The agent should receive a reference to the grant, not authority to rewrite its fields. Task-end cleanup should cover completion, cancellation, and failure. The maximum age supplies a separate cleanup deadline if that event is missed.
The purpose field supports review and policy matching. It does not prove that processing serves that purpose. A system still needs concrete restrictions on resource IDs, fields, operations, destinations, and outputs. Similarly, setting training to false only expresses a requirement. The selected processor must actually support it.
Enforce the grant across the workflow
- Before reading: resolve the canonical resource ID, tenant, and version. Verify the caller and the permitted operation. Do not use a display name as the authorization identity.
- Before processing: resolve the approved route to its actual provider and configuration. If that route cannot satisfy the required handling conditions, choose an eligible route or stop that operation.
- Before sending: check the destination and audience against the grant. A new tool or redirected request must not inherit permission solely because an earlier request was allowed.
- Before saving: classify the output and choose a permitted store. Apply the appropriate retention rule to both raw content and derived artifacts.
- Before every subsequent action: check expiry and revocation again. Recheck queued work when it executes, because an earlier permission decision can become stale.
Instructions found in retrieved documents are task data. They cannot expand the grant. A document that requests an upload to another endpoint does not authorize that transfer.
Separate grant expiry from data deletion
Grant expiry ends future authority under that grant. It does not delete data already stored. Revocation has the same distinction: block new use promptly, then handle existing copies under their retention and deletion rules.
NIST Privacy Framework 1.0 addresses the data lifecycle, processing permissions, disposal, and minimized audit records. That broader view matters here because a document can leave several kinds of residue after one agent task. [2] (opens in a new tab)
| Data surface | Suggested handling | Evidence to inspect |
|---|---|---|
| Retrieved text and working fragments | Remove working copies when the task ends or their maximum age is reached, whichever occurs first. | Store inventory, expiry records, and deletion results. |
| Saved summary | Keep it only at the user-authorized destination, under its stated retention rule. | Output destination, audience, and object metadata. |
| Model or tool requests | Use a processor whose actual handling matches the grant. | Route configuration and provider commitments; document limits on independent verification. |
| Vector indexes and caches | Do not create persistent copies unless the task permits them. | Index writes, cache keys, and cleanup behavior. |
| Audit records | Record IDs, decisions, and reasons; avoid raw prompts or document text by default. | Log schema, access controls, and expiry configuration. |
| Backups | Document retention and prevent restored copies from silently re-entering active use. | Backup schedule, restoration controls, and deletion limitations. |
A deletion claim should name its scope. Removing an object from the application database does not establish removal from provider logs, backups, or previously shared copies. If a surface cannot be inspected or controlled, record that limitation instead of marking the entire task as fully deleted.
Specify observable checks
The following are proposed acceptance checks, not results from a deployed system. Use synthetic documents and destinations so the checks can inspect data movement without exposing private content.
- Change only the resource tenant. The read should fail even when the agent has a working connector credential.
- Replace the approved processor route with another route. The transfer should stop before any content leaves the boundary.
- Revoke the grant after work is queued. The queued action should fail when it reaches its execution check.
- Complete the task. Inspect each declared temporary store and distinguish deleted, retained by policy, and unverified copies.
- Request the intended summary with a valid grant. It should succeed, so blanket refusal cannot masquerade as correct authorization.
Trade-offs and limits
- Narrow grants require resource resolution before execution. Unclear tasks may need clarification or a smaller initial scope.
- Derived summaries can still reveal sensitive information. Permission to read a source does not settle who may receive its output.
- Deletion competes with debugging, recovery, and required recordkeeping. Define those exceptions explicitly rather than silently extending retention.
- An application cannot infer that the user controls every right in every document. Content-use conditions and personal-data processing permissions remain separate inputs.
- A purpose label cannot enforce intent. This proposal reduces the operations available to the agent; it does not prove that every permitted transformation is appropriate.
The implementation target is a traceable decision at every data boundary: this actor, performing this operation, on this resource, for this task, through this route. Stored copies then require their own documented lifecycle.