Migration Assistant agent vaults need a cold start

A Mac transfer is not a harmless relocation when autonomous agents can reach APIs and SSH hosts. It creates a new machine, a new hardware security boundary, new running processes, and a new moment when somebody must decide what still deserves authority. If agents regain external access because the desktop looks familiar, the migration has skipped the only part that matters.

Migration Assistant can transfer documents, apps, user accounts, and settings from another Mac, PC, or backup. That is useful for getting productive again. It is not a statement that every security property of the source machine should survive. Apple explicitly documents that Secure Enclave keys and keychain items marked ThisDeviceOnly do not migrate to a different device.

The safe operating rule is simple: transfer what helps you investigate and rebuild, then require fresh proof before any agent can use a credential or open a remote session. A vault that refuses to open after a transfer may be doing exactly what you hired it to do.

A transferred Mac is a new endpoint

A new Mac may have the same user name, the same home-directory path, the same applications, and the same project checkout. None of those facts make it the same security endpoint. The processor, Secure Enclave, biometric enrollment, disk encryption context, installed system state, network attachment, and local process history have all changed.

Teams often make the wrong comparison. They ask whether the destination machine has the same files. They should ask whether the destination can prove possession of the same authority without copying authority that was meant to remain local. Those are opposing goals when the vault uses device-bound protection.

Apple's Security documentation draws the line plainly. A Secure Enclave private key is created within the enclave, cannot import a preexisting private key, and can be used only by the enclave that created it. Apple also says that a keychain item using kSecAttrAccessibleWhenUnlockedThisDeviceOnly does not migrate to a new device.

That behavior can feel inconvenient during a rushed laptop replacement. It prevents a copied application container, backup, or migration transfer from becoming a portable bearer token for external access. Do not work around the failure by exporting secrets to a notes file, environment variable, shell history, or a generic password manager entry. You would replace a deliberate hardware boundary with a file that can spread much farther than the old laptop ever could.

Set the cutover expectation before touching Migration Assistant:

• The old Mac remains the authoritative source for existing access until the destination passes tests.
• The new Mac begins with agent execution blocked or disconnected from production credentials.
• A transferred file is evidence to inspect, not permission to act.
• Every approval and every credential binding needs an explicit expected outcome.

This is a controlled re-enrollment, even when most of the app data copies successfully. Calling it a transfer does not change the security work.

Four kinds of state fail in different ways

Application data, approvals, audit records, and credential bindings are often stored near each other. They should not be treated as one thing. Each answers a different question, and a migration can produce a different result for each.

Application data is the ordinary local state: preferences, endpoint definitions, labels, non-secret metadata, and possibly encrypted vault blobs. It may transfer intact. Its presence tells you only that the copy operation found it.

Approvals are time-bound decisions about a particular agent process. They answer: "May this process act during this run?" An approval that remains visible in a local database after transfer should not authorize a process on a new Mac. The process has a new parent chain, new executable location, new environment, and potentially a changed signing state.

Audit records are evidence of what happened. They can and should survive if the transfer preserves the relevant encrypted files. They must retain their ordering and integrity properties, not merely remain readable in a journal view.

Credential bindings answer whether the destination hardware can use the cryptographic protection around a secret. The encrypted blob may copy while its local unwrap capability does not. This is the distinction that trips up otherwise careful engineers: ciphertext availability is not credential availability.

Write these four states into a migration worksheet before the transfer. Do not record a vague result such as "vault migrated." Record one result per state:

The awkward case is a partial success. The app launches, settings appear, the old audit history is present, and the vault cannot unlock. That is not a failed migration. It is a migration that preserved evidence and configuration while refusing to transfer device-bound authority. Accept that result and re-enroll the credentials.

Freeze agent access before copying anything

Do not begin with Migration Assistant. Begin by making sure no agent can issue a request while you are unsure which Mac holds authority.

First, stop active agent runs on the source Mac. If the agent is managed by a terminal multiplexer, editor extension, background task, or CI-like local launcher, stop each entry point. Close the terminal sessions that started them. A quit window is not proof that a child process has exited.

Second, record the source state outside the app. Capture the date and time, the source Mac's serial or internal asset identity, the user account, the agent processes that were active, and the names of the remote systems that the agents could contact. Do not put secrets into this record. You need a timeline that explains later evidence, not a duplicate vault.

Third, disconnect the destination from the networks that matter until its first controlled test. That can mean removing a production VPN profile from the initial setup sequence, denying a firewall rule, or simply keeping the new Mac off the network until the local checks are complete. A laptop that cannot reach an external API cannot accidentally demonstrate that an old authorization was accepted.

Fourth, decide who has authority to accept fresh approvals. This matters more than teams admit. A migration often happens while someone else sets up the new machine, restores backups, or fixes a damaged laptop. The person clicking an approval card should know what agent binary they are approving and why it needs that capability.

Use a short handoff record like this:

Migration ID: MA-2026-07-22-A
Source endpoint: old Mac asset ID
Destination endpoint: new Mac asset ID
External access state: disabled
Source agent runs: stopped
Source sessions revoked: pending destination verification
First permitted test: disposable read-only API action
Decision owner: named operator

The date shown is an example format, not a magic identifier. What matters is that you can later connect the source audit tail, the destination's first approval, and the first successful action to one cutover record.

App files can move without moving trust

Inspect application state in two passes: first for completeness, then for authority. Do not blend them. Completeness tells you what to restore. Authority tells you what must be rejected or rebuilt.

After the transfer, launch the application while the destination remains unable to reach production services. Confirm that its visible configuration is sensible: endpoint names, labels, non-secret routing details, and any expected local journal view. Compare these against the source Mac while the source still exists. If an endpoint is missing, rebuild it deliberately. If an endpoint appears that nobody recognizes, remove it and find out where it came from.

Then look for any state that could cause automatic action. Examples include auto-started agent integrations, shell profile entries that launch a connector, editor tasks, launch agents, saved command templates, and application preferences that reopen prior sessions. A migration can preserve convenience settings that are harmless for a text editor and dangerous for an agent that can call production APIs.

Apple says Migration Assistant transfers apps, accounts, documents, and settings. That broad category is why you need this review rather than assuming only personal files moved.

Do not use directory presence as a pass condition. A security design may deliberately transfer an encrypted vault file but leave its unwrapping material behind. An empty-looking vault can also be correct if the app chooses not to copy local security state. The only useful question is whether the result matches the design you expect.

For Sallyport, the vault is encrypted inside the app and the vault gate is absolute. On Macs with the supported hardware path, the gate uses Secure Enclave and Touch ID, and locked means every action is denied. A copied vault payload is therefore not evidence that the destination can use the source Mac's authority.

Document each observed result with exact language. Write "encrypted state present; destination gate remains locked" rather than "migration failed." Write "agent launcher disabled before first run" rather than "probably stopped." These details prevent a later operator from treating an unfinished test as a successful cutover.

Old approvals must not authorize a new process

Session approval and credential access are separate controls. A new Mac needs to pass both, in the right order. The vault gate determines whether any action is possible. Session authorization determines whether this particular agent run is allowed to make calls. A per-call requirement determines whether a particular credential demands another human decision on every use.

This separation is easy to blur because the user sees a single action succeed or fail. Do not accept that ambiguity during migration. Test it deliberately.

Start a new agent process only after the destination vault is in the intended locked or unlocked state. Ask it to request a harmless action using a credential that cannot modify production systems. The expected session result is a fresh approval request. Inspect the process identity and code-signing authority shown by the approval interface, then approve only the run you actually started.

If an agent process performs an action on the destination without a new authorization event, stop. Do not congratulate yourself that the transfer saved time. Find the path that granted authority. It may be a surviving process, a restored session database, an integration that launches outside the expected shim, or an approval model that does not bind tightly enough to process lifetime.

Sallyport's session authorization is on by default and shows the first call from a new agent process as an approval card that leads with the process's code-signing authority. One approval lasts only for that run, until it exits, so a newly started destination process is the correct place to demand a new decision.

Test per-call credentials separately. Mark one harmless test credential as requiring approval for every use. Make two calls from the same approved agent run. You should see a decision for each use of that credential, while the session decision should not repeat simply because the same process continues running. That tells you whether you tested the session layer or the per-call layer, instead of guessing from one popup.

A sensible test table is small:

Do not test this with a production deploy because a popup is not the only thing you are testing. You are testing whether the new endpoint recognizes process lifetime and credential policy correctly.

Audit history needs verification, not a visual spot check

A journal view that contains yesterday's entries is useful, but it does not prove that the transferred record remains whole. A migration can omit a file, copy an older snapshot, interrupt an update, or leave you looking at a cached index. Audit evidence needs an integrity test.

Preserve the source Mac before you run the first destination action. Capture the final source timestamp and record how many sessions and calls you expect to see around the cutover. Then compare the destination's historical view. You are looking for continuity, not identical screen placement or display order.

Sallyport projects its Sessions and Activity journals from one write-blind encrypted, hash-chained audit log. Its verifier can check the chain offline over ciphertext, without a vault key. That design gives migration testing a concrete pass or fail point instead of asking an operator to eyeball a list of old actions.

Run the verifier on the source before the move if you can, then run it again on the destination before allowing any agent action. Capture standard output and the exit code without assuming a particular message format:

sp audit verify > audit-verify.txt 2>&1
status=$?
printf 'sp audit verify exit=%s\n' "$status"

Store audit-verify.txt with the migration record, not in a chat thread that will disappear. A zero exit code is useful only if you also label which endpoint produced it and when. If the verifier reports an error or returns a nonzero status, stop the migration path. Keep the source intact, copy the diagnostic output, and investigate the transfer rather than starting a fresh journal that conceals the discontinuity.

There is another distinction worth keeping: transferred audit history proves what the old endpoint recorded; destination activity proves what the new endpoint does after cutover. Do not merge these mentally. The first destination call should be easy to locate, tied to the fresh session authorization, and clearly later than the last source call.

Re-enroll credentials instead of extracting them

The popular shortcut is to export an API token or SSH private key from the old Mac, paste it into the new one, and promise to clean it up later. It is popular because it works quickly. It is wrong when the old design intentionally kept the credential away from the agent and tied local use to a protected vault.

Re-enrollment changes the question from "How do I copy this secret?" to "Who should issue new authority to this endpoint?" That is a healthier question. It may require creating a new API token, registering a new SSH public key, or obtaining a new credential from the system owner. It also creates a clean revocation point for the old Mac.

For HTTP access, create a disposable, read-only test credential where the remote service permits it. Give it access to one harmless resource. Have the newly approved agent request that resource. Review the returned result and the local audit entry. Then revoke the test credential or let it expire according to the service's normal process.

For SSH, use a dedicated test account or a restricted test host. The first command should be observational, such as printing the remote account identity and current working directory. Do not make the first proof of success a repository push, a package publish, a database command, or a deployment trigger. Those actions make debugging much harder because they change the very system you are trying to protect.

A credential that requires per-call approval is particularly useful in this phase. It forces a human to observe exactly when external use begins. Once the destination has passed the authorization, audit, and harmless action tests, re-enroll the production credentials through their normal ownership path. Revoke the old credential or remove its old endpoint authorization as soon as the remote system supports that distinction.

Do not confuse an SSH key file with an SSH identity that belongs on the new Mac. A copied private key can authenticate, but that only proves a server accepted the same cryptographic material. It says nothing about whether the transfer preserved your local security model. New endpoint, new identity registration, new audit trail.

The first live action should be intentionally boring

Your first production-adjacent action should tell you whether the whole chain works without creating cleanup work. Pick an operation that is read-only, scoped to an inert test object, and easy to find in both remote logs and the local activity journal.

Good candidates include reading a test API object's metadata, listing a dedicated empty SSH directory, or querying a service's current authenticated identity. Bad candidates include creating cloud resources, rotating shared credentials, publishing artifacts, changing repository settings, and running commands that use shell expansion against real paths.

Run the action once. Confirm the following in the order they happened:

1. The destination vault was in the intended state before the request.
2. The new agent process received a fresh session authorization.
3. A per-call credential asked for approval if its setting required it.
4. The remote system recorded the expected harmless action.
5. The destination activity record matches the action you authorized.

If any observation is missing, do not repeat the action until you understand why. Repeating an opaque test tends to create a pile of nearly identical records and no explanation. One clean success tells you more than five hurried retries.

After that action passes, enable external access one credential at a time. Avoid enabling every saved endpoint in one afternoon because the destination machine has finally become usable. A production token, an infrastructure SSH identity, and a personal service token do not carry the same risk or need the same approver. Stage them in the order that gives the least authority first.

Keep the old Mac until the evidence closes

Do not erase or trade in the source Mac when the destination launches successfully. Keep it available, with agents disabled, until the transfer record is complete and you can explain the evidence on both sides.

The closure record should include the source's last verified audit state, the destination's first verified audit state, the outcome of the fresh approval tests, the credentials that were re-enrolled, the credentials that were revoked, and the person who authorized production access. This is not paperwork for its own sake. It is how you answer a later question about whether an action came from the old machine, the new machine, or an unplanned overlap.

Then revoke active source sessions. Remove the source from remote access allowlists where they exist. Revoke source-specific tokens and SSH registrations once the replacement works. Finally, verify that the old endpoint cannot regain access merely because it comes back online.

The test that matters most is not whether Migration Assistant transferred enough. It is whether the destination had to earn external authority again. If the answer is yes, the new Mac starts with a defensible boundary. If the answer is no, leave agents disconnected until you can explain exactly what crossed the transfer and why.