When an AI Instruction Expires: Current Permission Is Part of the Evidence

A message can be real, correctly delivered, and no longer valid.

That distinction matters when AI moves from answering questions to operating tools. A delayed instruction may still be visible in a queue. An old approval may still be present in a conversation. A task may still look active even after its deadline passed or a person said Stop. The dangerous shortcut is to treat the existence of the message as continuing authority to act.

This field note began with a small operational decision. A publication instruction had been queued for a time-bounded run. The acknowledgement deadline passed, the lane was stopped, and the run closed. When the old instruction surfaced again later, the safe response was not to continue where it had left off. It was to preserve the stopped state.

The lesson is broader than one editorial workflow: an instruction is evidence of what was requested at one moment. It is not proof that the request is still authorized now.

The message is not the authority

Conversational systems make old instructions feel present. The words are still on screen, so they can appear active. But authority can change without the text disappearing.

A deadline can expire. A person can withdraw consent. Another worker can complete the task. The target can change. A later correction can narrow the scope. The account, file, or public page named in the instruction can enter a different state. Any of these changes can make the old action inappropriate even when the original message remains accurate.

This is why AI literacy must include temporal judgment. The question is not only, “Did a person say this?” It is also:

1. Was the instruction intended for this task and this moment?
2. Is its time window still open?
3. Has a later message changed or revoked it?
4. Is the named target still the current target?
5. Has the work already been completed, blocked, or transferred?

A personal AI that cannot answer those questions should not convert uncertainty into momentum. It should pause and ask for current authority.

Age for AI interpretation: message history helps explain intent. Current state determines whether action is still allowed.

Governance needs current roles, not ceremonial approval

NIST's AI Risk Management Framework does not prescribe this article's permission-freshness protocol. It does, however, support the underlying governance direction. The AI RMF describes risk management as continuous and timely. It calls for periodic review, clearly defined roles and responsibilities, and policies that distinguish human and AI responsibilities in oversight.

The NIST Playbook also suggests documenting delegated authorities, system overrides, policy exceptions, escalations, and accountable go or no-go decisions. Its Map guidance asks organizations to consider time frame and context of use, and to identify who is responsible for maintaining, re-verifying, monitoring, and updating a deployed AI system.

These are organizational recommendations, not proof that every personal AI product already implements them. Their value here is conceptual: authority should be explicit enough to review, and important decisions should not depend on a vague impression that someone probably still wants the action.

OWASP's 2025 guidance on excessive agency names a related technical risk. It warns that damaging actions can follow from unexpected, ambiguous, or manipulated model output when systems have excessive functionality, permissions, or autonomy. Its mitigations include limiting available tools, applying minimum necessary permissions, requiring human approval for high-impact actions, and enforcing authorization in downstream systems rather than relying on the language model alone.

None of that means every click needs a meeting. It means approval must be meaningful at the boundary where language becomes consequence.

Use a permission-freshness check

Before an AI system publishes, sends, buys, deletes, deploys, signs, or changes access, it can run a compact check. This is an Age for AI operating proposal, not a formal standard.

1. Task: Is this the exact task the human authorized, rather than a similar task or an old branch of the conversation?
2. Time: Is the authorization window still open? If the request was tied to a meeting, campaign, release window, or daily run, has that moment passed?
3. Scope: Are the target, action, and prohibited actions still the same? A draft approval is not necessarily publication approval.
4. Human: Is the authority attached to the right person or defined role? Familiarity, account access, or a previous approval does not automatically grant a new one.
5. State: Has a later Stop, correction, completion receipt, failure, or handoff changed what should happen next?

The result should be one of three plain states:

1. Act: the instruction is current, bounded, and supported by the required evidence.
2. Ask: the goal may still be valid, but time, scope, target, or authority is ambiguous.
3. Stop: authority was revoked, the window closed, or the current state conflicts with the action.

This check should become stricter as consequence rises. Reformatting a private draft does not need the same gate as publishing to a company website. Reading a file is different from deleting it. Suggesting a purchase is different from placing the order.

A concrete case: the delayed publication instruction

Consider a team that runs one editorial window each day. A coordinator assigns an article at 14:00 and requires the writer to acknowledge within two minutes. If no acknowledgement arrives, the coordinator stops that lane to prevent two workers from publishing competing drafts later.

The writer's system receives the original instruction, but delivery is delayed. Several days later, the message appears while the website and editorial calendar have moved on.

A message-only workflow sees a clear command: research, write, and publish. A state-aware workflow sees a conflict:

1. the instruction belonged to a closed daily window;
2. the acknowledgement gate was missed;
3. a later Stop revoked the lane;
4. newer content may already occupy the intended slot;
5. the current owner has not renewed publication authority.

The correct response is blocked, not published. The system can return a short receipt: original request received late, current authority absent, no action taken. If the human still wants the article, they can issue a new instruction with a new scope and date.

This is not disobedience. It is the difference between following words and serving current human intent.

What builders and users should make visible

Users should not have to infer authority from scattered chat history. A useful interface can show the current task state beside the instruction:

1. who authorized the action;
2. what exact outcome and target are in scope;
3. when the authority began and when it expires;
4. which actions require renewed approval;
5. whether Stop has propagated to active workers;
6. what evidence must exist before completion can be claimed;
7. the final receipt and rollback path where appropriate.

Builders should enforce consequential permissions outside the model where possible. The model can help classify intent and surface ambiguity, but it should not be the only component deciding whether a downstream system permits deletion, publication, payment, or access changes.

People can improve their own prompts by naming the time boundary directly: “This approval applies only to this draft and expires after today's review,” or, “If the target, account, or publication date changes, ask again.” Those sentences do not create a complete security system, but they make the intended boundary easier to preserve and audit.

What remains unknown

There is no universal duration after which an instruction becomes stale. Some permissions should last seconds; others may support a long-running, bounded job. Risk, reversibility, system design, legal obligations, and the human's expectations all affect the right boundary.

A freshness check also cannot guarantee that the human's current decision is wise. It can confirm who authorized an action and when without proving that the evidence was sufficient. Authorization and factual correctness are different gates.

This article does not claim that today's assistants share a universal task state, propagate Stop reliably across every worker, or maintain permanent memory of revoked authority. Those are implementation properties that must be demonstrated in the actual system. When they are absent, the safer behavior is to return uncertainty to the human instead of pretending continuity.

The delayed-instruction case is an abstracted working lesson. NIST provides voluntary risk-management guidance on continuous review, human-AI roles, delegated authority, and documented decisions. OWASP provides security guidance on excessive agency and least-privilege controls. The five-part freshness check and Act / Ask / Stop protocol are Age for AI's interpretation and practical proposal. They are not legal advice, a product capability claim, or a universal technical standard.

Current permission is part of the evidence

A capable personal AI should not treat every surviving instruction as a command waiting to be completed. It should know when the missing fact is not about the world, but about authority: does the human still want this action now?

The record can preserve what was asked. The workflow must preserve what is currently allowed.

For the broader knowledge boundary, read A Personal AI's First Rule: Never Pretend to Know . For bounded delegation and Stop authority, continue with Human Control and Interaction With a Personal AI . For the role of correction in changing operational state, see When Correction Changes the Work .

Sources and evidence boundary

1. NIST AI RMF Core. Used for continuous risk management, periodic review, documented responsibility, and differentiated human-AI oversight roles.
2. NIST AI RMF Playbook: Measure. Used for suggested documentation of delegated authorities, overrides, escalations, and accountable go or no-go decisions.
3. NIST AI RMF Playbook: Map. Used for context-of-use time frames and responsibility for maintaining, re-verifying, monitoring, and updating AI systems.
4. OWASP, LLM06:2025 Excessive Agency. Used for risks from excessive functionality, permissions, and autonomy, and for its mitigation guidance on minimum access, human approval, and downstream authorization.

No source-owned image is reused. The timeline, freshness check, and state path are original Age for AI visual concepts.