Give the workflow its own limited identity

Tool access should follow from the task boundary. Start with the data the workflow has to read and the exact actions it's allowed to propose or perform. Set up an identity for the service instead of borrowing a developer or admin account, so its permissions can be inspected and removed without breaking anything unrelated.

Read access deserves as much attention as write access. Retrieval can surface material the user wouldn't otherwise be able to see, especially when several teams' documents share one index. Where you can, filter by permission before content gets to the model. Then test with identities that have different access and check which sources come back as well as the final wording.

For actions, specific capabilities are better than broad API access. If a task needs to create a draft, it shouldn't automatically get permission to publish, delete or change account roles. Restrict resource types, fields and destinations wherever the external system lets you. For the first release I'd keep high-consequence operations behind explicit human approval.

Approval has to be tied to the stored proposal. Record the action, parameters, target, approver and timestamp, and if the proposal changes after approval, ask for another decision. A generic confirm button followed by a fresh model call can end up executing something different from what the person looked at.

Credentials need ordinary production handling. Keep them out of prompts and source documents, limit which runtime component can read them, and make sure you can rotate them without changing the workflow definition. Strip them from logs and from error messages the model can see. And test what happens when a credential expires or loses permission, because sooner or later one will.

I'd put these access checks in the release evidence:

• Each supported task maps to the read and action permissions it needs.
• The service identity has no grants nobody can explain.
• User-level source restrictions survive retrieval.
• Approval is recorded against fixed action parameters.
• Credentials don't appear in prompts, outputs or ordinary logs.
• Access can be revoked, and when it is, the workflow fails into a visible state.

Shortly before release, check the effective permissions in the target systems themselves, because the account may have picked up extra access during development that the config files don't show.