Why?
What user intent authorized the action?
The receipt should preserve the task in user language and the structured capability derived from it. "Publish the approved guide" is meaningfully narrower than "use deployment access."
Deployment receipts are becoming a trust primitive for personal AI agents.
The agent should not stop at saying done. It should prove what was approved, what authority it used, what changed, what was verified, and whether access is closed.
Inspect the receipt modelIntent namedArtifact frozenAuthority scopedExecution observedVerification independentAccess closedIntent named
Research thesis
Agent trust needs evidence at the level of the completed task.
The shift from chat to action
Traditional assistants earn trust primarily through the quality of their answers. Personal agents that operate browsers, publish websites, send messages, purchase services, or change account settings face a harder standard. A fluent completion message does not prove that the requested action matched the approved action, that the right artifact reached the right destination, or that temporary authority ended afterward.
Infrastructure logs contain fragments of that story, but they are usually organized around systems rather than user intent. A hosting provider records a deployment. An identity provider records a token exchange. A browser worker records navigation. A policy engine records an approval. The user needs those fragments joined into one understandable account of the task.
Editorial inference from security guidanceAs personal agents perform more consequential work, a user-readable receipt will become part of the product contract, not merely an internal audit artifact.
NIST zero trust guidance emphasizes dynamic policy, least privilege, continuous evaluation, and just-in-time access. OWASP recommends expiration, revocation, rotation, and careful management of short-lived credentials. Workload identity systems demonstrate that software can exchange a verified identity for temporary authority. A deployment receipt translates those control principles into a consumer-facing outcome.
Why "done" is insufficient
Six questions a trustworthy agent must answer.
Which artifact?
Record an immutable identifier, version, digest, or item set so approval cannot silently drift to changed output.
What authority?
Name the account, scope, destination, runtime, and lifetime of the grant used to execute the task.
What happened?
Connect observed actions, failures, retries, verification, rollback, and final access closure to the approved request.
Receipt anatomy
One record across the entire agent lifecycle.
Intent envelope
The user's task, the agent's structured interpretation, expected consequence, and any constraints. Example: publish:approved-artifact to one named service.
Approval evidence
Who or what approved the action, which preview or artifact was reviewed, the decision timestamp, and whether policy or explicit human confirmation supplied consent.
Authority envelope
The identity of the requesting agent and runtime, credential source, capability scope, allowed destinations, issue time, expiry, and revocation condition.
Execution evidence
The release identifier, relevant tool actions, destination responses, redacted errors, policy interventions, and whether execution diverged from the plan.
Independent verification
The exact public route or resource checked, expected properties, observed status, failed links, artifact comparison, and rollback readiness.
Closure evidence
Credential revocation or expiration, runtime destruction, retained state policy, unresolved failures, and the final user-facing status.
Example
A receipt should be readable before it is machine-queryable.
Website release completed
The approved artifact is live. Six checks passed. Temporary deployment access has been revoked.
RequestPublish the approved browser-agent security guide
Artifactsha256:6f82...a190 · preview approved at 16:42
Authoritydeploy:static-site · production service · 8-minute maximum
Releasedeploy-185 · completed at 16:46
VerificationRoute, title, assets, links, mobile layout, and rollback passed
AccessREVOKED publisher runtime destroyed
A receipt turns an agent's claim into a reviewable chain from intent to authority to verified outcome.
Market signals
Why receipts are moving toward the product surface
AUTONOMY
Agents act without continuous observation
When users are not watching every browser step, post-task evidence becomes the practical way to confirm that action matched intent.
DELEGATION
Authority is becoming temporary
Short-lived and just-in-time grants create a natural record boundary: the system can show when authority started, what it covered, and when it ended.
MULTI-SYSTEM
Evidence spans providers
Agent tasks cross identity, browser, hosting, messaging, and payment systems. A receipt correlates events around the task instead of forcing users to inspect separate logs.
CONVERSATION
Trust can return to the same channel
An agent that requests approval by text can also deliver the completed receipt by text, preserving continuity from decision to outcome.
Quality model
Not every activity log is a trustworthy receipt.
| Weak record | Strong receipt | Why it matters |
|---|---|---|
| "Deployment successful" | Release ID, artifact digest, target, and independent public-route result | A provider success response does not prove the intended page is healthy. |
| "Credential accessed" | Agent identity, runtime, task scope, issue time, expiry, and closure status | Custody logs alone do not explain whether the use was authorized. |
| Raw browser transcript | Relevant redacted actions mapped to the approved intent | Users need concise evidence without secret leakage or noisy internals. |
| One final status | Attempt, failure, rollback, verification, and unresolved issue states | A failed custom domain must not disappear behind a healthy provider route. |
| Mutable description | Immutable artifact and policy identifiers | The record must remain connected to the exact approved work. |
Builder checklist
Minimum requirements for receipt-grade evidence
Human-readable summary
Lead with the outcome, consequence, failures, and access-closure state.
Immutable identifiers
Bind the receipt to exact artifacts, policies, releases, and task versions.
Authority provenance
Record which identity issued the grant and which agent runtime consumed it.
Independent verification
Test the user-visible result rather than trusting the execution tool alone.
Explicit failed checks
Preserve DNS, TLS, link, asset, rollback, and policy failures without euphemism.
Machine-queryable detail
Retain structured fields beneath the concise user-facing summary.
For an agent, trust is not only permission before action. It is evidence after action.
Applied to Super
The approval channel can become the receipt channel.
A conversational trust loop
A text-message AI assistant can ask for a bounded decision and later return a compact receipt: the requested action, live result, failed checks, and whether temporary access is closed. The user does not need to open an identity console, browser-worker dashboard, and hosting provider to reconstruct the task.
For computer-use work, the computer-use cache can preserve safe state while receipt fields distinguish retained navigation context from temporary sensitive authority. This helps prevent a cached session from becoming invisible permanent privilege.
The pattern is especially tangible when an AI agent builds and publishes websites. The receipt can bind preview approval to an artifact digest, publishing grant, provider release, public route, link checks, custom-domain result, and revocation. Super can keep that whole accountability loop in the user's conversation.
FAQ
Questions about agent receipts
Is a receipt the same as an audit log?
No. Audit logs are usually system-specific and optimized for administrators or investigations. A receipt correlates relevant evidence around one user task and presents a concise, understandable outcome while retaining links to structured detail.
Should receipts contain the agent's full reasoning?
No. Internal reasoning is not required to prove the authorized action and may expose sensitive or irrelevant information. Record the task interpretation, policy decision, tool actions, observed outcomes, and verification evidence instead.
How should receipts handle secrets?
They should identify the credential source, scope, and lifecycle without including secret values. Redact tokens, passwords, session cookies, one-time codes, and sensitive request bodies from both user-facing and machine-readable records.
What happens when verification is incomplete?
The receipt should say so directly, identify which checks failed or were skipped, and distinguish the provider-level result from the user-visible result. A healthy Render hostname and broken custom domain are two separate facts.
Can receipts support automated policy later?
Yes. Structured receipts can help identify repeatable low-risk tasks, detect unusual destinations or failure patterns, and inform future approval policy. Human readability should remain the top-level interface.
Primary references
- NIST, Implementing a Zero Trust Architecture. Just-in-time access, least privilege, continuous evaluation, and policy decisions.
- NIST SP 800-207, Zero Trust Architecture. Dynamic access policy and resource-level authorization.
- OWASP Secrets Management Cheat Sheet. Secret expiration, revocation, rotation, audit, and short-lived credentials.
- Google Cloud Workload Identity Federation. Short-lived access through verified identity exchange.