Give the workflow a bounded identity

Tool access should come from the task boundary. Start with the data the workflow must read and the exact actions it may propose or perform. Create an identity for the service rather than reusing a developer or administrator account. Its permissions should be inspectable and removable without affecting unrelated work.

Review read access as carefully as write access. Retrieval can expose material the user could not otherwise see, especially when documents from several teams share one index. Apply permission filtering before content reaches the model where possible. Test with identities that have different access and verify the returned sources, not just the final wording.

For actions, prefer specific capabilities over broad API access. If a task needs to create a draft, it should not automatically receive permission to publish, delete or alter account roles. Restrict resource types, fields and destinations where the external system allows it. Keep high-consequence operations behind explicit human approval during the initial release.

Bind approval to the stored proposal. Record the action, parameters, target, approver and timestamp. If the proposal changes after approval, require another decision. A generic confirmation button followed by a fresh model call can execute something different from what the person reviewed.

Credentials need ordinary production handling. Store them outside prompts and source documents. Limit which runtime component can read them. Rotate them without changing the workflow definition. Remove them from logs and model-visible error messages. Test the behaviour after a credential expires or loses permission, because this will eventually happen.

Include access checks in the release evidence:

• each supported task maps to required read and action permissions;
• the service identity has no unexplained grants;
• user-level source restrictions survive retrieval;
• approval is recorded against fixed action parameters;
• credentials are absent from prompts, outputs and ordinary logs;
• access can be revoked and the workflow fails into a visible state.

Review the effective permissions in the target systems shortly before release. Configuration files can describe the intended grants while the actual account has accumulated more access during development.