How to design consent expiry rules

Consent expiry rules tell a personal AI agent when old approval no longer applies. They protect the operator from stale browser state, changed evidence, public output risk, and accidental reuse of a narrow yes.

expiry rulesfresh evidencebounded consentsafe resumesexpiry rulesfresh evidence

Expire consent when the original decision would no longer be fair to replay.

The job is not to make every approval disappear quickly. The job is to preserve useful delegation while forcing a fresh review when the facts, scope, or risk profile changes.

The practical model

Start with a narrow consent object: allowed action, evidence hash, account boundary, output target, spending or publishing limit, time window, and revocation path. Then define the conditions that invalidate it. A text-message AI assistant can still ask a compact question, but the agent should store a richer expiry policy behind the reply.

Consent expiry turns approval into a living rule. If the agent resumes and the new state matches the old boundary, it may proceed or ask lightly. If the state changes, it must ask again with a fresh context bundle.

Consent expiry rule matrix

Time expiry

Useful for volatile tasks such as checkout, booking windows, or short-lived browser sessions.

State expiry

Trigger a new ask when page content, file diff, account state, or extracted evidence changes.

Scope expiry

Invalidate consent when the recipient, amount, account, URL, or action class changes.

Implementation checklist

  • Capture the evidence bundle before asking.
  • Write the allowed action in plain language.
  • Store explicit disallowed actions.
  • Choose time, state, scope, or user-revocation expiry.
  • Check expiry before every resume.
  • Show the operator what changed when asking again.

Common failure mode

The agent treats a previous yes as a broad standing permission. That is especially risky when a browser task resumes after the page has changed, or when generated content is published from stale approval.

Use different expiry triggers for different work surfaces.

A good rule system should match the kind of delegation: message-native approval, browser work, or generated output.

Text approvals

Expire when the user’s reply is ambiguous, old, or outside the requested action.

Browser state

Use a computer-use cache to detect changed screens before reuse.

Generated output

For AI agent website-building, expire consent when the page diff or publish target changes.

Risk change

Ask again when a task crosses a new money, privacy, public-output, or account boundary.

A repeatable expiry workflow.

Give the agent a clear decision path before it resumes from old approval.

Load the old approval, compare the current state, then ask again when meaning changed.

Read the consent object

The agent loads the previous prompt, human response, evidence bundle, expiry rules, and resume guidance.

Compare current state

The agent checks whether page state, target URL, recipient, amount, file diff, or generated output still matches the approved context.

Decide the path

If unchanged, proceed or ask lightly. If changed, block action and ask with the exact difference highlighted.

FAQ for consent expiry design.

The most useful expiry rules are simple enough for operators to understand and strict enough for agents to enforce.

Should every approval expire quickly?

No. Stable low-risk preferences can last longer. High-impact, volatile, or public actions should expire on time, state, or scope changes.

What should force a fresh approval?

Changed evidence, changed page state, new recipients, new spend, different account, new public output, and user revocation should all force review.

How should the agent explain expiry?

Show what changed since the original approval. The operator should not need to infer why the old yes is no longer enough.

Where does Super fit?

Super spans messaging, computer use, and generated outputs, making consent expiry rules useful across practical personal agent workflows.

Sources and reference anchors