Agent authorization after reboot: permissions that expire

A Mac reboot gives teams a clean technical boundary. Use it. An agent process dies, its memory disappears, and every approval that referred to that particular run should die with it. Trying to make autonomous work resume invisibly after restart usually turns a narrow, inspectable permission into standing access with a vague expiration story.

That does not mean a reboot should erase everything. Teams need the evidence that explains prior actions, the encrypted credentials that support future work, and enough task context to resume deliberately. The discipline is simple: preserve records and protected materials; discard live authority. Then require a person to approve the newly started process before it talks to the outside world.

Agent authorization after reboot must start from an empty runtime state

Agent authorization after reboot should begin with no active process grants, no unlocked vault, no inherited session secret, and no remembered approval that a new process can spend. A restart ends the object that received the approval. Treating the replacement process as equivalent just because it uses the same checkout, command, or agent name is an identity mistake.

People often argue that this creates friction after an operating system update or a power interruption. It does create one intentional pause. That pause forces someone to look at the process that now wants authority, rather than the process they approved hours earlier under different conditions.

A clean restart boundary has four useful properties:

• It clears volatile material such as in-memory access tokens, decrypted key handles, queued confirmations, and process identifiers.
• It stops an agent from carrying an approval through an unattended period when the operator may no longer be present.
• It gives a team a reliable audit marker for reconstructing whether an action occurred before or after restart.
• It exposes hidden dependencies on local caches, background helpers, and connection multiplexers.

Do not confuse a reboot with a user logout. A logout should also end agent authority, but a reboot is easier to test because it terminates nearly every ordinary process. If a grant survives it, someone deliberately stored the grant or created a helper that lives outside the agent lifecycle. Either case deserves inspection.

The rule applies even if the agent binary is code signed and unchanged. Code signing can help an operator identify the publisher of the program. It cannot prove that the running process has the same instructions, environment variables, repository state, tool configuration, or operator intent as the prior run. A signed process can still receive a dangerous prompt after reboot.

The same rule applies to a planned task. Suppose an agent prepared a database migration, asked for approval, and the Mac restarted before it executed. The plan may persist in a work directory. The authority to execute it must not. On restart, the agent should present the intended operation again, and the operator should decide whether the work is still correct.

This is where many designs become careless. They save a durable record that says "approved" and call it a session. That record becomes a transferable permission because a later process can claim it. A session grant needs a live binding to a process instance and a short, definite lifetime. Once that process exits, the authorization record should show that it ended rather than remain eligible for reuse.

Keep evidence and configuration, discard live grants

A team should persist facts that explain work and configuration that can be safely re-used, while deleting or invalidating every object that confers immediate authority. Put these categories in different storage and lifecycle buckets. Combining them produces the familiar problem where an audit record accidentally becomes an authorization token.

The following split works well in practice:

The first column supports continuity. The second prevents continuity from becoming quiet privilege retention.

Keep the status of interrupted work, but make that status descriptive. Good records say that run R-1842 requested an SSH command, received approval, and stopped before execution because the host restarted. Bad records say that run R-1842 may execute its remaining actions after the next launch. The first lets an operator make a decision. The second makes one in advance, without knowing what the later process will be.

Credential storage deserves equally precise language. An API key stored encrypted in a vault can persist across restart. The decrypted form should not remain available merely because the machine restarted quickly. A vault lock creates an explicit point where the person at the Mac re-establishes presence. That is separate from deciding whether an agent process may use a particular credential.

Sallyport follows this separation: its vault gate blocks every action while locked, and its per-session authorization applies to a newly connected agent process rather than to a remembered task label. Those are two different decisions, and collapsing them makes incident review much harder.

Do not persist approval by hiding it inside convenience features. A few examples appear harmless until they compound:

• A launch agent restarts an MCP client and feeds it the old session file.
• An SSH client retains a control socket under /tmp or a user cache directory.
• A script copies a bearer token into an environment file so retries work after reboot.
• A task runner sees an unfinished job and executes it before asking whether the target changed.

Each feature claims to preserve progress. Each can also preserve authority without showing the operator who or what now holds it.

Use an interruption record instead. Give it a task reference, the old run identifier, a digest of the intended action list, target names, and a status such as stopped_by_reboot. Do not include a usable credential, cookie, approval token, or instruction that a launcher can execute. On the next run, display that record as context for a person. Context helps review; authority should come from a fresh decision.

A reboot is not a credential rotation event

A reboot should expire agent permissions, but it should not automatically rotate API keys or SSH keys. These controls answer different failure modes. Authorization expiry limits who can use an existing credential and for how long. Rotation replaces the credential because you suspect exposure, loss, misuse, or a changed access need.

Teams waste time and break integrations when they treat every restart as an exposure event. They also create a false sense of security if routine rotation masks a leaked credential without identifying where it escaped. Rotating a key does not repair a design that handed the key to an agent, placed it in a transcript, or wrote it into shell history.

NIST Special Publication 800-63B separates session management from authenticator lifecycle. Its guidance treats session termination and reauthentication as explicit controls, while authenticator replacement addresses a different issue. That distinction fits agent systems well. End the live agent run on reboot. Rotate underlying credentials only when evidence or policy calls for it.

Use rotation after reboot when the restart itself followed a credible exposure event. Examples include discovering that a secret reached a prompt log, finding an unknown process with access to the agent environment, losing a laptop, or learning that a former team member retained a copied credential. In those cases, the reboot is incidental. The suspected escape drives rotation.

Long-lived bearer credentials deserve extra scrutiny because they can work anywhere the network permits. If an agent ever receives their plaintext value, the gateway has already lost the clean boundary that makes reboot expiry meaningful. The agent can store or transmit that value before the machine restarts. A later session approval cannot call it back.

SSH has its own traps. A private key may remain securely held in a local vault, yet an existing SSH connection can keep executing remote channels until the connection ends. SSH connection multiplexing can also leave a local control socket that a later client uses. Reboot should clear both in normal circumstances, but do not make assumptions. Test the actual client options and helper behavior your team runs.

The practical policy looks like this: retain encrypted source credentials, lock them at reboot, end all grants and active transports, then require a fresh process authorization before the gateway uses a credential again. Add rotation triggers based on exposure and personnel changes, not on an arbitrary boot event.

That policy also keeps incident response honest. If an operator says, "we rebooted, so access was reset," ask whether the credential ever left its protected store and whether the remote provider maintains independent sessions. A reboot resets local runtime state. It does not invalidate a token at a cloud provider unless the provider receives a revocation or rotation event.

Device unlock, human presence, and process approval are separate facts

A secure resume needs separate answers to three questions: can the Mac access protected credentials, is an accountable person present, and which process is asking to use them? A design that uses one signal to answer all three gives too much meaning to that signal.

Device unlock controls access to the local user environment. It can establish that someone passed the Mac's login protection. On supported hardware, a vault may use Secure Enclave and Touch ID to keep secrets unavailable while locked. That protects material at rest and creates a clear action boundary, but it says nothing specific about the next process an agent framework launches.

Human presence is a moment in time. A biometric confirmation or a click can establish it for a specific decision. Letting a presence check silently bless all future external actions until the next reboot makes that moment far broader than the operator intended. The risk grows when a coding agent can continue for hours, read changing repository files, or accept instructions from pull requests and issue comments.

Process approval answers a narrower question: do I authorize this newly running program to make gateway calls during this run? The approval screen should identify the process using durable evidence, such as code-signing authority, and should avoid asking the operator to interpret a mutable process title. A label such as agent is not identity. Anyone can choose that label.

The order matters. First, the vault must be available. Then the gateway can identify the process. Then the operator can approve that process for the requested run. For credentials marked as unusually sensitive, request a confirmation again on every use. This gives a team three controls with different jobs instead of one oversized "allow agent" button.

Do not use the Mac account name as a substitute for process identity. A shared local account can run multiple terminal sessions, build tools, editors, and agent hosts. If one approval follows the whole account, a malicious shell command or a second agent can spend authority that somebody intended for another process.

The approval decision should also avoid pretending to answer scope questions it cannot answer. A process-level grant says who may call the gateway during a particular run. It should not silently imply permission for every credential or every action forever. Pair it with credential selection and, where warranted, per-call confirmation. That keeps a high-impact credential from inheriting the convenience of a lower-risk API call.

There is a temptation to solve this with an elaborate policy language: conditions on time, source path, branch name, hostname, command patterns, and prompts. Such systems can work for dedicated security teams, but they create a different hazard when ordinary developers cannot predict the outcome. A small set of visible decisions is easier to exercise after reboot and easier to explain during review.

Resume a named run rather than a broad team permission

Teams can resume interrupted work safely when they make the work item durable and the authorization ephemeral. The restarted agent should receive enough context to continue, but it should obtain new authority as a new process. A project-wide remembered approval is the wrong shortcut because it lets unrelated work inherit an old operator decision.

Give every substantial run a durable reference that people already understand. A repository path and branch may work for development tasks. A ticket number, change request, environment name, or incident identifier may work better for operational tasks. The reference does not grant permission. It lets a human compare the restarted run with the work they expected.

A useful resume card or terminal prompt contains five pieces of information:

1. The prior run identifier and the reason it ended, such as stopped_by_reboot.
2. The work reference and the repository revision or deployment artifact the old run used.
3. The next external action the new process proposes, including destination and credential label.
4. The identity evidence for the current process, not just the old process.
5. A choice to approve this run, reject it, or inspect the prior action record.

Do not restore an entire action queue without review. The external world may have changed while the Mac was down. A pull request can be force-pushed, a DNS record can point elsewhere, a deployment can finish by another route, or a maintenance window can close. The fact that an agent formed a plan earlier does not make its later side effects appropriate.

Consider an agent that was updating a fleet through an HTTP API. Before restart it successfully changed hosts A through D, then prepared calls for E through H. The Mac reboots. On launch, the agent finds its old queue and attempts to continue. A careless implementation reuses the token and sends E through H. A safer one reads the interruption record, creates a new run, asks for authorization, fetches current state, and presents the remaining intended calls. It may discover that another operator already changed F and G. Fresh authorization gave the person a chance to catch that.

Retry behavior needs a hard edge. If the gateway denies a call because the vault is locked or the process has no approval, the client should stop and report the blocked action. It should not spin in a loop, open repeated prompts, fall back to direct network access, or substitute a credential from an environment variable. A retry after a transient network failure is reasonable only after the call still has valid authorization.

This approach does not require an agent to forget its work. Preserve the plan, command output, repository diff, and plain-language note describing the interruption. Treat those artifacts as evidence for a new decision. The difference sounds small in a design meeting and becomes large during an incident: the saved plan explains intent, while an inherited grant performs an action without a new accountable choice.

For sensitive operations, ask the restarted agent to re-read current state before it proposes the next action. This is especially useful for destructive API calls and SSH commands whose effects depend on present host state. The extra read is not permission. It is a check that the old plan still describes the world.

HTTP and SSH need explicit restart rules

HTTP APIs and SSH both need fresh agent authorization after restart, but their hidden state differs enough that a single vague "session reset" claim will miss failures. Write the reset behavior for each channel, then test the paths agents actually use.

For HTTP, distinguish the credential from an access token or cookie minted by a remote service. A gateway can keep the credential encrypted locally while it injects it into a request only after approval. The agent should receive the response, not the bearer credential. After reboot, discard any local cached access token, request headers stored for retry, browser-style cookie jars used by automation, and open connection state.

A provider may preserve a remote session after restart if a client later presents a still-valid refresh token or cookie. That is why an agent should not possess those artifacts. If it does, it can call the provider directly and bypass your local restart rules. Put credential injection and token refresh on the action side of the boundary, where a fresh authorized process invokes them.

For SSH, terminate client connections and inspect multiplexing. OpenSSH can reuse a master connection through ControlMaster and ControlPath; this helps interactive users but can make it unclear which invocation owns a remote session. An agent gateway should use a stateless execution path or a lifecycle that cleanly terminates any helper when the agent run ends. Never assume a remote command stopped because the local UI closed.

Use this reproducible reboot drill for both channels:

1. Start an agent run and approve a harmless HTTP request or SSH command against a non-production target.
2. Record the run identifier, process identity, intended request, and the time of the last completed action.
3. Restart the Mac before the agent performs a second prearranged action.
4. Start the agent host again without changing its task files, then ask it to make that second action.
5. Confirm that the first attempt is denied until the vault is available and the new process receives approval. Then inspect the record to ensure the second action belongs to a different run identifier.

For a gateway that supports a command-line audit verifier, run the verifier before and after the drill:

sp audit verify

The command should report whether the encrypted audit chain verifies, without requiring the vault to be unlocked. Do not write automation that parses made-up success text from a human-facing command. Check its documented exit status and preserve the command output with the drill record. Sallyport projects both session and individual-call journals from a write-blind, hash-chained encrypted audit log, so the verifier gives operators an offline integrity check after a restart.

The drill should also test the bad path. Try an old environment variable, a cached HTTP client profile, an SSH control socket, and a second local agent process. If any of them reaches the destination without a new authorization, the reboot boundary is decorative. Fix the bypass rather than adding another reminder to operators.

Audit records must explain both the old and new run

An audit trail after reboot should tell an investigator where one run stopped and where a different run began. It must make the separation visible even if the same user, repository, and agent framework continue the same task. If the record collapses those events into one long session, it cannot answer who authorized the post-reboot action.

Store the old run's terminal state explicitly. Useful values include normal exit, denied by vault lock, denied pending approval, host shutdown, network failure, and operator revocation. Do not overwrite this state when the new process starts. A restart record should point back to the prior run, not merge with it.

For the new run, record the process identity evidence presented at authorization, approval time, and the first external call. The first call matters because approval does not always mean use. An operator may approve a run that exits before acting. Distinguishing approval from execution prevents a review from claiming an action occurred when the operator only allowed the possibility.

Individual call records should preserve enough context to reconstruct the action without storing a secret. For HTTP, capture destination, method, credential label, result class, and a redacted representation of the request metadata. For SSH, record destination, account label, command or an approved digest of it, exit status, and result metadata. The exact retention treatment for command output depends on its sensitivity, but do not drop the fact that an action occurred.

Hash chaining makes later tampering easier to detect, not impossible to imagine. It is useful because each record commits to prior records, and offline verification can reveal a broken sequence. It does not prove that an approved action was wise, and it does not stop a person with the authority to issue an action. Teams still need review and disciplined approval boundaries.

Keep the audit verifier outside the normal agent path. An agent that can rewrite or bless its own evidence creates a circular trust claim. Operators should be able to run verification independently, including while the vault remains locked. They should also test what happens if a record is altered in a copy of the audit data, so they know the expected failure behavior before they need it.

Instant revocation also needs a record of scope. If an operator revokes a session after restart, the journal should show which run lost authority and which calls were denied afterward. Avoid a global statement such as "agent access disabled" unless that is literally what happened. Precise records prevent a team from guessing whether a separate process still held an approval.

Choose expiration rules before automation chooses them

A safe reboot policy is short enough that every developer can state it correctly: a restart locks protected material, ends every agent process grant, and preserves evidence plus non-executable task context. A newly launched process gets a newly reviewed authorization. Credentials rotate only when exposure or lifecycle rules require rotation.

Write this policy down in operational terms, then assign an owner for each exception. If a team claims it needs uninterrupted automation through reboots, ask what action would continue, what account would own it, how it would be monitored, and why a human approval boundary is unacceptable. That may describe a service account workload rather than an interactive coding agent. Give it a separate design instead of quietly turning an agent session into a server credential.

Set a predictable response for the first workday after an unexpected reboot. The operator verifies audit integrity, checks the old run's last completed call, unlocks protected material if appropriate, launches a new agent process, reviews the resumed task, and approves only the work that still belongs to the current situation. This is a modest interruption compared with reversing an action performed under an approval nobody realized survived.

Do not promise that restart logic can make autonomous work safe by itself. It can only create a clean decision point. The quality of that decision still depends on clear process identity, narrow credential use, legible action descriptions, and records that a different person can inspect later.

When the next reboot interrupts a real task, resist the urge to add a "continue automatically" switch. Preserve the plan. Preserve the evidence. Make the new process ask again before it spends authority.