Does upgrading an API key to Write change old agent jobs?

If changes that normally appear in the Inbox suddenly reach the official record, where should the investigation begin? The schedule, script and agent still use the same key. It is tempting to investigate the workflow first and overlook a recent permission edit in the account.

Changing a key from Change Request to Write reaches beyond the current window. Every old job still holding it gains a new capability ceiling for subsequent requests. A waiting period previously enforced by the credential may disappear on the next run.

Busabase documents that a permission edit preserves the key value and expiry and applies the new level to existing holders immediately. The workspace role and the request’s explicit review setting still determine the outcome. Before changing the level, establish who holds the key and which jobs rely on it to retain their review gate.

The effect follows the credential

A key belongs to an account, rather than one agent or one workspace. The same value may be present in a local environment, CI, a scheduled process, and another agent. Changing its level changes the permission ceiling for their subsequent requests without distributing a replacement secret.

That makes a convenience change broader than it looks. Before enabling faster writes for one job, establish which other callers share that credential and which spaces its account can access. Effective capability remains the intersection of the key level and the account’s role in each space. Write does not bypass workspace roles.

Capability and assignment are separate

Read permits reading within the account’s access. Change Request adds proposals but cannot merge them. Write adds reviewing, merging, and content editing. Manage includes administration and permanent node deletion. A job that only proposes corrections usually needs Change Request, not Write.

These levels describe what the system permits. The current assignment still defines what the agent is allowed to do for the business. A Write key does not turn permission to update one record into permission to change every accessible Base. Conversely, a sentence requesting automatic approval cannot give a proposal-only key merge capability.

A ChangeRequest does not always mean a waiting period

The Change Requests documentation explains that every edit is a ChangeRequest. With write access, it normally merges when created. Proposal-only credentials, an explicit autoMerge: false, and anonymous form submissions retain review.

Read the actual old request before predicting its new behavior. If it relied only on a Change Request credential to prevent immediate merging, upgrading that credential can remove the waiting period. If it explicitly sends autoMerge: false, that request still asks to wait. A previous Inbox entry does not establish how the next run behaves.

Build a caller inventory without copying secrets

In Account → API Keys, identify the key by its name and prefix, and confirm its level and expiry. Do not put the full value in a report or chat. Inspect the configurations you control to list each caller, target space and Base, intended operation, and explicit review setting.

This is a team-maintained inventory, not a promise that Busabase automatically discovers every holder. If the sharing scope is unclear, issue a separate key for the job that actually requires Write rather than upgrading a shared credential. Creation, migration, and revocation require the appropriate operator authority.

Verify a real outcome after the change

Raising the level asks for a second confirmation. Afterward, confirm the effective space through an identity read, then follow one already authorized, controlled piece of work through its normal write. Check the returned CR status, merge timestamp when applicable, and the canonical record value. Do not modify arbitrary business data just to test permissions.

Record which caller was verified and which scheduled processes have not run yet. approved and merged are different states. A successful request is not a substitute for reading the record back. Correct an unintended merge path before allowing that caller to resume.

Lowering access does not reverse past merges

Reducing the same key’s level changes future capability for existing holders. It does not undo business values that were already merged. Inspect the affected records and history, then propose the appropriate correction while retaining the original audit trail.

For a replacement agent, see access and pending-proposal handoff. For destination mistakes, see verifying a multi-workspace write target. An in-place permission change has a narrower question: what will each existing caller be allowed to merge next?

Questions before changing the level

Must old agents receive a new key?

Not for an in-place level edit: the value and expiry remain unchanged, and existing holders gain the new level immediately. Separating jobs with independent keys is a different configuration decision.

Can a Write caller still require human review?

Yes. Explicitly send autoMerge: false for that request. If a job only needs to propose changes, a proposal-only credential gives it a clearer capability boundary. Verify the actual CR state in either case.

Can Write override the account’s workspace role?

No. Effective capability remains restricted by that role, and the request must still target the correct space.